Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

Poorly Tuned Instances

In this second scenario, we will run a JMeter test which execute 5000 requests against both Tomcat instances whereby we will not change the configuration of the AJP connector from the default values and where we have a maximum of 10 database connections in the pool to service database requests. We can view the AJP connector settings, database pool settings and JVM heap settings used below.

1) AJP Connector configuration

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>

 


2) Database Pool Configuration

<Resource name="jdbc/productdb" auth="Container" type="javax.sql.DataSource"
               maxTotal="10" maxIdle="30" maxWaitMillis="10000" logAbandoned="true"
               username="root" password="admin" driverClassName="com.mysql.jdbc.Driver"
               url="jdbc:mysql://localhost:3306/products"/>
</Context>

3) JVM Settings

We have set the minimum and maximum heap size to 1GB respectively as below:

export CATALINA_OPTS="-Xms1024m -Xmx1024m"
 

4) Results

Although JMeter provides us with some useful performance statistics, we will use JConsole to monitor the performance of the test. We can observe below in Figures 2 and 3 that the maximum time to process a request out of 1878 requests processed by one of the Tomcat servers took 4858 milliseconds - whereby it took 373041 milliseconds to process 1878 requests.

In Figure 3, we can find out metrics for each of the AJP threads used to process requests. We have provided an example of just one here whereby it took just 73 milliseconds to process the last request,whilst the maximum time to process any single request on this thread took 4744 milliseconds.


Figure 2: GlobalRequestProcessor Mbean Attribute Values
Figure 3: RequestProcessor Mbean Attribute Values

Optimized Tomcat Instances

In this final test scenario, we will perform some basic tuning on both Tomcat instances to the AJP connector configuration in server.xml, the connection pool configuration described in context.xml and the JVM heap size allocated to each Tomcat instance.

1) AJP Connector configuration

The AJP connector configuration below is configured so that there are two threads allocated to accept new connections. This should be configured to the number of processors on the machine however two should be suffice here. We have also allocated 400 threads to process requests, the default value is 200. The "acceptCount" is set to 100 which denotes the maximum queue length to be used for incoming connections. The default value is 10. Lastly we have set the minimum threads to 20 so that there are always 20 threads running in the pool to service requests:

 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" acceptorThreadCount="2" maxThreads="400" acceptCount="200" minSpareThreads="20"/>

2) Database Pool Configuration

We have modified the maximum number of pooled connections to 200 so that there are ample connections in the pool to service requests.

<Context>
<Resource name="jdbc/productdb" auth="Container" type="javax.sql.DataSource" maxTotal="200" maxIdle="30" maxWaitMillis="10000" logAbandoned="true" username="xxxx" password="xxxx" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/products"/>
</Context>

3) JVM Settings

Since we have increased the maximum number of pooled connections and AJP connector thread thresholds above, we should increase the heap size appropriately. We have set the minimum and maximum heap size to 2GB respectively as below:

export CATALINA_OPTS="-Xms2048m -Xmx2048m"

4) Results

We can observe from the JConsole Mbean metrics below there is a significant improvement in performance. The maximum time it took to process a request is 2048 milliseconds, and the overall processing time to handle 3464 requests is 206741 milliseconds.

If we observe the result sin Figure 5 from an individual AJP thread, we can observe it took 46 milliseconds to process the last request whereby the maximum time it took to process a request on this thread is 1590 miliseconds. This particular thread has processed 141 requests whereby it took a total time of 5843 milliseconds to process these requests.

Figure 4: GlobalRequestProcessor Mbean Attribute Values

Figure 5: RequestProcessor Mbean Attribute Values

For more details on Tomcat 8 connector parameters, please visit this this link at Apache

-- source https://www.c2b2.co.uk/middleware-blog/tomcat-performance-monitoring-and-tuning.php

...

Info

Best practices for a secure Magnolia environment

  • Keep instances up to date.
  • Store public and author databases in separate physical locations. This minimizes the risk of data loss due to hardware failure or breach. The likelihood of a simultaneous event on both instances is less than that of a single instance in a different location. Failing suitable backup data, the surviving instance can be used to restore the instance on which the loss or corruption occurred. This tip is not Magnolia specific, just good common practice.
  • Delegate (move) the JCR repository and all folders referenced from the magnolia.properties files outside the webapp.
  • Run your server with a user account that has only read access to the Magnolia webapp. This ensures that a potential attacker can't use your write access to create a file with a malicious script for example.
  • Change superuser password as soon as possible after installation. The default password is well known. Use the same password across all instances.
  • Train users to create secure passwords. Thomas Baeddal’s article Usability of passwords covers the subject in depth.
  • Ensure that anonymous access to AdminCentral URLs is blocked on author and public instances. This is the default. Edit the anonymous role and create an ACL that denies access to ./magnolia and .magnolia/*.
  • If feasible, block access to the AdminCentral URIs for all users other than those inside the local network.

--source https://documentation.magnolia-cms.com/display/DOCS/Security+best+practices

If you're installing your Apache Tomcat using Debian package (apt) then you won't have to concern about below items, otherwise:

  • remove the Tomcat Manager application or make sure it has been configured with users and strong passwords. 
  • remove other stock Tomcat web apps (demos, examples, etc.)

Enabling SSL for Apache Tomcat

also extracted from Bradley Andersen presentation in Magnolia Developers Unconference 2017 

Image Added

Image Added

Integration with memcached

TBC.

References

https://wiki.apache.org/tomcat/HowTo/FasterStartUp

...