Affinity

Deployment Scripts

If you plan to keep an environment for any period of time, you will most likely want to automate how you get code into that environment. Having a repeatable process will better assure your chances of success when it comes time to deploy code; not automating the environment will cause inconsistent results. Review deployment scripts, and make sure you have redundancy in the process. You also will need to account for errors and, if possible, back up the code and any other artifacts, prior to deploying the new code and or scripts. Deployments happen at all hours of the day and night—doing a deployment in the middle of the night has its own challenges, but add a full day of work the day before to your being tired, and you can make all sorts of mistakes. When you determine your best practices approach for dealing with the clusters, keep in mind the growth and the possibility—you may need to add additional servers to support the growth of the company and/or applications.

Session Replication

Data may not be as predictable in production as you saw it in development, which may translate into the size of your session objects. The session objects are objects that contain data you use to store state (save the user session) on the server. You will most likely keep the username and password, some preferences, and, depending on the requirement, a whole range of other data sets. Session replication is when you take the session or state of a user on Server A and make a copy of that session for failover purpose. The idea is that if a user is logged on to a machine and it goes down, he can resume work on Server B without having to re-authenticate or lose the non-transient data before it is persisted to disk or database. When you move the application from a development environment, which has a small set of test data, into production, where the data may be ten times the size of the test, you may run into problems. The way the application is used may be different when you use it in production. Production may have sessions that are several megabytes in size. The challenge to understand is how your code is handling these large sets of data coming back from database, or downstream system. Let’s say you do a search and bring back a list of six hundred records. If persistence is on, this object is stored in session, and then the application server will replicate the data to another node in case of failure. Now, six hundred records may sound like a lot, but the process of serializing and sending them across to another node in the cluster does take some time and resources. You need to be aware of the data that is transient and can be thrown away, as well as what you need to persist (save) in the near and long term.

Deployment Descriptors

Given that the container or application servers has its own set of configuration files, called deployment descriptors, you need to be extremely cognizant of what they are and how they can impact the performance of your application. An application that runs perfectly fine in development and in test environments may not work in production. The deployment descriptors are a way to tell the container how to behave. When you change a deployment descriptor you tell the container how to behave differently. Be careful when making modifications to the deployment descriptors. If you make changes without knowing the consequences, you may introduce a performance issue, just by making the change.

Remote Calls

When making a remote call, keep in mind that the remote call will consume resources of the system. In a Java application server, you use a thread to wait for that resource and a socket on the operating system, which translates into an additional connection through the firewall. Remote calls can also cause additional network traffic if they are not designed properly. Remote calls have the disadvantage of overhead, of getting the remote connection. Be very cautious with any code that calls external resources. It is not just a matter of whether to release the resource but whether you also have a timeout in place to release the resource, in the event that the remote resource doesn’t respond. You also should be concerned with how often you are going to call a remote call and how much data you will get back. Be very aware of how fine grained your remote calls are. If you keep them too fine grained, you can bog down the network or servers with the amount of times you need to go to the back-end system for more data.