Step 6 Identify and Assess any Server Side Problem Areas

Step 6. Identify and Assess any Server Side Problem Areas 

The numbers shown here are the elapsed time from when the request was sent to the server until a response was received back. If a number is higher than you think it should be and you want to reduce it there are several things you need to look at:

This should show up when you do step ‘Step 4 – Assessing the Average CPU per server interaction’. We have all done this with 5250 programs, batch programs, etc. The programs are just too complex for the computer to process when a lot of people start to use them at the same time. Web programs are no different. The solutions to this type of problem are the same as for 5250 programs or batch programs.

Note – Using a ‘Hello World’ baseline You may be able to classify this type of problem by using a simple ‘Hello World’ program in your VLF application test harness. If the ‘Hello World’ program runs well and your other program runs poorly, then the most likely cause of the problem is that the other program is overly complex. 

If you have a reasonable average CPU time in your L4Web interactions, it may be that the time taken to get the HTTP request to your server (or back again) is too long and needs to be improved.

Assessing this is an area that requires specialized tools and resources. However, if you are working in an environment where everybody knows that from 9:00am until 11:30am printing something on the local printer goes very slowly, and that copying a small file to the network sever takes 30 seconds, then you almost certainly have an issue in this area that will impact your L4Web jobs.          

You Apache web server schedules the execution of your HTTP requests. It may be overloaded or performing poorly for many reasons. For example, it may not be configured properly and not able to use enough execution threads to handle the number of requests being sent to it. Equally, threads may be being blocked or lost to failing requests.

• Make sure you all the very latest Apache PTFs applied.    
• Review the IBM supplied Redbooks related to Apache tuning
• Consult an expert in Apache performance tuning.
• Note – Using a ‘Hello World’ baseline - You may be able to classify this type of problem by using a simple ‘Hello World’ program in your VLF application test harness. If the ‘Hello World’ program and your other program both run poorly, then you may have HTTP server or communication issues.  

If you have a reasonable average CPU time in your L4Web interactions, it may that your L4Web job is taking too long to processes the request. For example, it might require 0.3 CPU seconds to complete, but be taking 40 elapsed seconds to get access to the 0.4 seconds of CPU time. This is exactly the same type of problem that can impact 5250 programs or batch programs. The slow response time happens because the program can’t get access to CPU cycles.

Investigating this is vanilla System i tuning stuff … subsystems, machine pool storage activity levels, time-slices, priorities, machine pool sizes, etc. Broadly speaking, you would be looking for the same sort of signs of trouble as in a 5250 application, most typically exhibited in very high paging rates in the pools in which the L4Web jobs execute.

This sort of assessment may culminate in a hardware upgrade because it turns out to be cheaper than the man-hours spent trying to force too much work into too small a computer.       

You may be having this trouble in this area for these reasons:

• When you plan to introduce 50 new 5250 users to you System i you would naturally consider the impact this would have on its daily workload, possibly having to resize the machine as a result. Did you do this for your L4Web users?
• If you did, did you account for the fact that a web user typically uses more resources than a 5250 user? For example, a web user in an AJAX-style application like the VLF will typically have very short ‘think times’ and be hitting the System i CPU for cycles much more often that a 5250 user with their much longer ‘think times’.    

Same things to try here are:

• Make your programs simpler so that they match the capabilities of the server. 
• Restructure your application to reduce the frequency of ‘hits’ on your server.
• Performance tune your System i server, especially if very high pool paging rates are observed.
• Put more memory onto your System i server to reduce pool paging rates.
• Upgrade your System i Server