10 Useful TIPS for a Faster J2EE Application !

Why is your app slow ?

Ever felt your application should be more faster and responsive ?

So here are 10 things that can help you make your application faster !

                                                   

  1. Know your Queries !
     The most resource intensive section of any application is the DATABASE ! its the slowest of all – remember DB is always FILE IO (Okay, Unless you deal with in-memory database or SAP HANA or MapR). So this is a great opportunity to tweakeg: if you wanted to access the last X records

                                           SELECT id FROM Order WHERE … (Fetch the last X Records)
And then I’d execute one query for each record:
SELECT * FROM Order WHERE id in (Results from your first Query) ?

            this is roughly 20-30% less IO , Processing Cost on your DB Server Head.

      2. Not using DB Connection Pool
           Remember ! every time you do a class.forname( com.mysql.jdbc.driver )   Your JVM has done a reflection and loaded the class on memory and trying to get you a connection !! this takes roughly a second, So better use the connection pool and set the initial capacity = 10 and roughly have 1 connection for every 5 concurrent user or 1 per 25 to 50 users (active during that hour). So roughly a 100 user app will need around 10 connections in the pool to keep your business running on a summer day.

 

     3.   Calling the GARBAGE Collection Explicitly
             This is an another costly stuff ! every single time when the full GC (Garbage Collection) runs it stopped processing all the threads until its done… which means – if that runs for 3 seconds… all the users on the application or server are FROZEN for those 3 seconds…  that poses a terrible user experience.

So in order to avoid this reduce the scope of all the variables to local / function level variables – this will eliminate so many variables remaining the memory even after they are used.

Another TIP is : After you have used a variable and you don’t need it anymore – then de-reference it by making it point to null.

In a modest 2-3 gigabyte  heap this might be 3-5 seconds, but if you are running a 30-gigabyte head this   could be more on the order of 30 seconds

    4. Concurrency Issue :
           Its always a developer nightmare – when 2 threads are pointing to a same shared resource and they result in deadlock.

Few Developer Nightmares :

• Thread deadlocks
• Thread gridlocks
• Thread pool sizing issues

Code deadlocks occur when two or more threads each possess the lock for a resource the  other thread needs to complete its task and neither thread is willing to give up the lock that it
has already obtained.

At Database level, Deadlocks happen when a thread is trying to update a record and an another thread is trying to read it ! or 2 threads are trying to update a record and both fails at a point.

Synchronised blocks  is normal culprit and has to be dealt properly. – this can use unexplained stuck threads and resulting in performance delay and data inconsistency etc.

           Tip: Way to get over ! you mostly see stuck threads in production (since its v.hard to reproduce).. enable thread dumps and evaluate them in detail and understand bottle necks in the code and de-congest them to avoid the deadlocks.

 

5. Overuse of HTTP Session
          Since HTTP Session is the easiest way to carry objects from 1 module to another…Developers over-use this function…  and it always becomes and pain at the end of development or in production.

So there has to be utilities written to understand what objects lies hidden in your JAVA Session and clear them explicitly  once the user left a module to another module or when its no longer required.  Since the HTTP Session gets bloated when there is large number of concurrent users – it can bring down the entire application “java OutOfMemory Exception ”  does that sound familiar name to you ? Oh yea – In several developer’s case… Including mine in the past.

         Tip: Use In-house Utilities to dump the HTTP Session variables and determine which has to removed at the exit of what modules.

    6. String Concatenation
                    Not a serious offence ! remember all those places where queries are concatenated by + symbol…. if there are more than 10 lines – String is 2X costlier than string buffer
and you have 100-500 users… all those 2X difference is going to make a serious impact.

So as a standard practise : Use String Buffer for all queries / concatenation needs instead of string.

   7.  Not using JSON for webservices
                   Now it has become a standard for folks to user JSON instead of SOAP XMLs ! thanks to all Angular JS / Metorite / NodeJS etc.   JSON is upto 10 times lighter than SOAP Webservices (period).

e.g: a employee web service which carries 50 fields and its values in XML world its around 50-65 Kb of data transfer and in JSON case its 5-9 KB of data

Tip  : If you have options – move to JSON for performance and use a proper parser on the front end.

 

     8 .  Compression of those JS
         Remember those JS from Angular and jQuery the min versions…. they have been stripped of their empty spaces … they have been done for a reason .. a 200 KB JS file when compressed and minified – its only around 30-40KB

Tip : Wherever possible : minify the JS file for Production and have a normal version for development and debugging ! – Bingo serves both purposes.

    9 .  Optimising the UX-Views
            A simplified UX is always quicker , swifter and has better navigation experience. So introduce JS based sorting on the screen instead of DB hits / Use of Stored Procedures or Views instead of Queries for VIEW only / Data Fetch areas – Remember they are pre-compiled – hence more faster.

   10 . DB Optimisation

Simple difference of an hitting a table with index which has more than 100,000 records (on MySQL DB) is upto 60 to 90 % faster.

1) does your tables have indexes on most columns that you use for searching like employee_id, employee_name, age, city, status (of employee table).

2) do you have triggers enabled on large tables which are been modified very faster ?

3) If an your query takes more than 6 seconds – rule 1: it should move to stored procedure or a view and validate all indexes. remember MySQL can read 100,000 in 1 second.

4) Java Controllers are FASTER than JSP (since they are already compiled) so have your logic written on either in the query or controllers instead of JSP

 

Thank you ! Stay Tuned for More…..

-Techuva Solutions Pvt Ltd.