As more companies make their foray into the mobile space, they are now realizing that their infrastructure, which is tuned for desktop applications, might not be a good fit anymore. With mobile applications, different factors come into play, like:
Different device capabilities (for example, touchscreen)
Changes in network connectivity
Variable mobile network speeds
Short session times
To get the most out of your infrastructure and support the mobile experience, you must take these kinds of issues into account and re-tune for mobile. Using IBM Worklight as an example, here are some guidelines to set you on the right path.
Tune underlying and enterprise systems
Each component in the request flow is only as fast as the slowest link in the chain. If requests are getting hung up at the database on the back end, it does not really matter how fast your application performs on the front end. Make sure that your hardware, operating system, database and any other related systems are tuned for peak performance and can handle the expected workload. For best results, install the IBM Worklight Server on a 64-bit server.
Tune the application server
The Worklight Server is not actually an application server itself but an application that runs on a Java application server—either IBM WebSphere Application Server or Apache Tomcat. One thing that I learned from my experience working with WebSphere Application Server is that default settings are not your friend. There are several tuning parameters that you should look at and adjust accordingly. This tuning parameter hot list for WebSphere Application Server outlines a typical approach, starting with hardware requirements and then working up to reviewing your application design.
Tune the Worklight ServerAfter getting all of your underlying systems to sing in perfect harmony, there are a few more parameters that you need to adjust for optimal Worklight Server performance. The Worklight Server provides a run time container for the server-side application components and settings.
Typically, it is installed in a local area network (LAN) connecting to various enterprise systems. It can be clustered for scalability and high availability. It uses a database, and most organizations install it behind a web authentication infrastructure (web single sign-on) acting as a reverse proxy and providing Secure Sockets Layer.
1. Java virtual machine (JVM) memory allocation
The optimal memory allocation depends on your application needs and other factors. For information about how to calculate memory size, see the following documents:
2. HTTP connections
Each incoming HTTP request requires a thread for the duration of the request. If more simultaneous requests are received than can be handled by the currently available threads, more threads are created up to the configured maximum. For example, if you set the maximum number of threads to 50 and the longest call takes 500 milliseconds, then your system can handle about 100 requests per second.
How you configure this setting depends on what type of application server you have. Details are given here in the Worklight Information Center. What you do here also has an impact on the next tuning point, which is ...
3. Enterprise connections
The Worklight application components that connect to enterprise systems are called adapters, and they run on the Worklight Server. If the enterprise system does not impose a limit on the number of incoming connections, then you can set the number of connection threads per adapter to the number of HTTP threads in the application server.
If the enterprise system does limit the number of incoming connection threads, then you do not want to exceed the maximum number of enterprise connections allowed. In the case of a Worklight Server node cluster, divide this figure by the number of nodes in the cluster, and that is the value that you want to use.
You set the maxConcurrentConnectionsPerNode parameter in the connectivity element of the adapter.xml file.
4. Session timeout
The next tuning point has to do with sessions. Each time a device connects to the Worklight Server, a session object is created and stored in memory. This object also contains authentication information. The serverSessionTimeout property controls how long to wait before timing out a session due to inactivity. The default value is 10 minutes. That means that if 100 users start a session with the server every minute, and each session lasts about three minutes, the sessions still remain active for 10 minutes, thus leaving 10 x 100 = 1,000 active sessions on the server.
The average mobile phone session is one to four minutes long. An average tablet session lasts around eight minutes. Imagine how much fat you can trim just by reducing the value of this parameter!
Another thing to keep in mind is that on the client side, while an app is in the foreground, the mobile client “heartbeat” property pings the server. This feature prevents the server session from timing out. When the app runs in the background, it does not send a heartbeat ping to the server, and the session times out according to the serverSessionTimeout property setting.
5. Background tasks
There are a few tasks that the Worklight Server does in the background that can affect performance. These tasks involve the database or file system and can be controlled by setting some parameters in the worklight.properties file.
cluster.data.synchronization.taskFrequencyInSeconds: controls how often the file system is synchronized with database content. Application and adapter files are read from the file system and are stored in the database that enables the synchronization of the deployment data between all cluster nodes. Each Worklight Server checks its database for new applications and adapters, and then deploys them to the local file system. The default is two seconds. If you are not deploying new applications and adapters that frequently, you might want to increase this interval.
deployables.cleanup.taskFrequencyInSeconds: deletes unused deployable components from the file system. The default frequency is 24 hours
sso.cleanup.taskFrequencyInSeconds: controls the cleanup interval for the single sign-on (SSO) mechanism to check for inactive accounts in the SSO table. Accounts are considered inactive if they remain idle for longer than serverSessionTimeout. Inactive accounts are deleted. The default frequency is five seconds. This value is worth tweaking, especially if you adjusted the serverSessionTimeout value.
And, finally ...
Tune your application
All the tuning in the world is not going to save a poorly designed application. You must reduce complexity, streamline workflows and refine the content for the mobile experience. If you do not meet user expectations, your application is likely to get deleted.
Please feel free to continue the discussion. Tell me about your experiences with tuning for the mobile experience in the comments.Megan Irvine is a WebSphere Education Course Developer/Instructor and an IBM Redbooks Thought Leader. Follow Megan Irvine on Twitter at @mirv_pgh.