Wednesday, September 4, 2013

Monitoring and Managing Amazon RDS Databases using MySQL Workbench

In order to connect to Amazon RDS instance to fire some queries the procedure we followed were
  • Connect to EC2 instance via SSH
  • Connect to RDS from there.
We can fire queries from the SQL prompt but the issue with it is that the view gets distorted when the data on one column is very large. Also there is no support for exporting that result.

On my local I was using MySQL workbench which had solution to above problem so I thought of using that tool to connect to RDS.

On doing some research on same I found the following link which was very helpful in configuring same.
http://thoughtsandideas.wordpress.com/2012/05/17/monitoring-and-managing-amazon-rds-databases-using-mysql-workbench/

However the link provided is for MySQL workbench 5.5 and I had version 6 locally. Posting the corresponding  screenshot for version 6 here.



Rest of the configurations remains same.

Monday, September 2, 2013

Tomcat performance tuning

A tomcat with default configuration can handle max 300req/sec
I was unaware of that until I had to tweak the tomcat to improve the performance of my webapp.
In this blog I am going to list few of the tomcat connector parameters which helped us in improving the tomcat performance.



acceptCountThe maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.
acceptorThreadCountThe number of threads to be used to accept connections. Increase this value on a multi CPU machine, although you would never really need more than 2. Also, with a lot of non keep alive connections, you might want to increase this value as well. Default value is 1.
maxConnectionsThe maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will not accept any more connections until the number of connections falls below this value. The operating system may still accept connections based on the acceptCount setting. Default value is the value of maxThreads
maxThreadsThe maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool.
minSpareThreadsThe minimum number of threads always kept running. If not specified, the default of 10 is used.
processorCacheThe protocol handler caches Processor objects to speed up performance. This setting dictates how many of these objects get cached. -1 means unlimited, default is 200. If not using Servlet3.0 asynchronous processing, a good default is to use the same as the maxThreads setting. If using Servlet 3.0 asynchronous processing, a good default is to use the larger of maxThreads and the maximum number of expected concurrent requests (synchronous and asynchronous).
Out of these parameters maxThreads plays a very important role. The optimal value of it varies with the response time for single request. For our project it was around 75.

Few hit and trial can easily give you a value which performs better than the default one.

After tweaking the parameters the tomcat should be tested for different load ranges to ensure that it is working as expected.

Comparing it with tomcat having default configuration gives you a very good metric to calculate the performance gain.

Sample Config in server.xml
<Connector port="8090" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxConnections="500" maxThreads="75" acceptorThreadCount="2"/>

Reference :

Note : The parameters mentioned are valid for tomcat version 5, 6 and 7. Future versions can modify/remove the mentioned parameters.

Basic and Simple SpringMVC application download

Download link : https://github.com/cdeepakait/sourcecode/tree/master/SpringMVCExample

At the bottom right of the page you will see download zip option.

The code is very simple. It exposes one REST API : /hello
e.g. http://localhost:9090/mvctutorial/hello


Migration from legacy logging API like JCL or log4j to logback(slf4j)

While working with a large source code it often happens that you come across some components which rely on some legacy logging API's rather than slf4j or logback. It's very difficult if not nightmare to keep track of such components and assign appropriate logging level for those components through various configuration files.
The question now arises that is there a way to bridge those legacy logging API to logback ?
Answer is YES.

Logback provides certain jars to do so : http://www.slf4j.org/legacy.html

All the corresponding jars can be downloaded from : http://mvnrepository.com/

IMP : The version of corresponding jars and the logback jars present in the project should be same.