Changing your tune from desktop to mobile
Christian Karasiewicz 270005XS4E Visits (3703)
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:
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 maxC
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 serv
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 serv
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 work
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 Deve