Performance : A few tips that worth to implement.

 
These tips will help you have faster applications, and most of that are to be implemented with Java.
1 - Client (UI) should (must) be thin client :
Don’t create client that do too many things, specially DAO to load reference tables each time that you need load the page. Thin client should do basic validation just to have data integrity, like date formats and range, numbers ranges, if that field can accept null or not, business rules as the name say should be performed in business. If you have one screen with multiple tabs, try create it as separate, JSP/XHTML pages, for page to each one tab, with independent validations happening just before you jump to the next tab, and go passing the object populated till you get into the submit page. Doing this, you will load few objects each time in memory and smaller pages too. Try keep at minimum those submits, most of instance variables that aren’t being used should be set to null, with this the GC will collect them faster.  There are a lot to talk about thin client, actually exist books talking about it, though if you follow this, will help you a lot with performance. UI should never make call to DAO, everything should come ready from Business layer, if you need keep those drop down lists updated all the time, use cache and dependency injection (old IOC) in business layer to keep those caches updated.

     
2 – JPA/Hibernate mappings, should be consistent, with database design
I know that today we have ORM, though a lot of people see it as a recipe to ignore all good practices about relationship. What I can tell here is respect the  entity-relationship, and use lazy, or if you do need just one data, and this data is strictly necessary, perform one single and simple read using native query in that table. The database design, I mean internally is made to work using entity-relationship, and if you create it in creation time, you should use it to have the best performance with it. I’m not saying that ORM will be bad to performance, but it bad when everybody that has to implement one new feature, create one new ORM relationship that doesn’t follow what the database was designed for, and with it after some time start being really hard fix it, due a lot of mapping and code has to be changed. Try keep it simple and functional without implement to many mapping-relationship with no need. If you need for many things and you have good reasons to use it further so implement it, now if it’s just for one or two things, don’t do it.

3 - JSF 1.2 and Facelets are good
Actually are awesome, they are so good that JSF 2, is 1.2 with improvements and Facelets,  the biggest problem is the way those systems were designed, a lot of people doesn’t really know JSF and Facelets properly and they instead read more about it and look for good implementations, they use the easiest one got from internet, or try use it as the old Struts work, that’s as action based framework, and in the end they have one very hard to maintain system, bloated with more layers than needed and with bad performance.


4 – Objects in memory, control them, use just the necessary
There a lot system that load a lot objects in memory without use, they keep in there up to they are needed, or worst the load several times the same object in memory with different instance names. Think this way, it’s better one big object in memory than several smaller ones using the same amount of memory, just because you consume less resources from you processor, doing the GC work less checking all the time what is needed to be collected. One rule of thumb is if you will need update just a few fields from one object, don’t load another in memory and then in the end merge them. Use local objects, that will be destroyed as soon the task is completed, try use primitive types in memory and then “persist” then into the object. Think that if your system is part of one enterprise one, not all resources will be available all the time like in your personal environment. There your system such probably will work together with several others systems all them consuming resources from server or servers, all them using the same memory, IO and everything else. Try use static to all those methods that make part of validations, this can cause some sort of bottleneck though will avoid memory leaks, and several instances that doesn’t being used in memory. Try keep the design clean, something like having one object for the screen, that will be converted after submit to BO and that the persistence layer in the end will split it and them persist into database.


5 – Avoid to use Strings
Instead use StringBuffer or StringBuilder, and preferably instantiate quite few and reusing it always as needed. Try use static ones, and “don’t use this” in comparations, print’s, since that it will never change. Use java standards to create names.


6 – Database connection, is the most expense resource that you will have
Even today I see a lot of system using DAO the wrong way, and most of them never have heard about use caches. The just let the AS take care of everything (as if should work). One good idea make the DAO layer one little bigger than just only CRUD operations. Try read about JPO (Java Persistence Objects), roughly speaking DAO should give to Business layer the BO ready and not in parts, entities alone for that Business has to convert it and discover soon after that will need again one other read (or several others) to complete the request. Loading or doing all necessary reads and populating once the BO object it’s good also because will open the connection just once, do everything needed and then close, maybe you don’t know about it though if you are using one data source your AS is doing it for you.


7 – Use of Web Services
They make a lot of sense if you have several technologies that should consume your system, if using just Java, try use serialized objects that is quite faster. Worth take a look into the granularity of those WS’s to check if some parts of it can be used for others services. But is essential that you migrate to WS those “services” that will doesn’t change very often and in rare cases create WS (WSDL) that will carry on huge objects as request and response.

8 – Have the most close environment as production in one machine
This’s really important thing, that will can test several settings to memory, data sources, and to check as your system is consuming the machine resources, and it’s good too to perform stress tests. Just making one good tunning in your AS will grant you at least 40% improvement in performance.Tweaking your AS will make a big difference.

9 – Don’t leave instance variables that aren’t being used to be collected to GC.
If you set as null every time that you will not use it anymore, will save a lot of resources from your machine.

The basic thing that you must have in mind is that in production very often all machine resources are shared among other systems, OS, AS, and that you can’t just go consuming it without think in consequences, and that there is not like in your machine, that when need perform one IO or use more memory is just do it, most of the cases the database is not in the same machine that your system, think always in economy of machine resources. That will make your system perform with performance.
There are a lot more rules that should be followed to have a good performance, though those are the main ones.
If you that are reading it have anything  to add please feel free to put comments.