http.conf settings and performance

[kevinh]

As some of our clients have ramped up the number of users signing on we have had some complaints of response time issues. Knowing this can be due to a number of issues, including hardware limitations, I just wanted to know if any of the Apache server configuration settings should be examined that are set in the http.conf file? Once such concern is the ThreadsPerChild set to 40 by default. We have clients that have twice to five times that many concurrent users signed and just wanted to know if this number would be a concern for that many users? Any other settings to be concerned about as user count increases?

[Scott Klement]

This is a tricky one, because setting ThreadsPerChild too high will actually hurt performance. The throughput is actually higher/faster when an HTTP request has to 'wait in line' to be handled. But, of course, the latency can be very high if it has to wait too long. So it's a "Balancing" act... you don't want to have too many ThreadsPerChild, it'll kill throughput. But you don't want to have too few, because it'll hurt latency.

I would start by using a network request debugger on the PCs that are slow. If the latency is high, then I would try increasing the ThreadsPerChild. I would be conservative about it, though. Maybe double it to 80, and see if that makes things better or worse. If it improves things, then I would try 120, and see if that makes things better or worse... change it little by little until you figure out where the "sweet spot" is.

Keep in mind that HTTP connections do not stay active all the time like 5250 sessions do. So if you have 2000 users signed on to Profound UI at once, probably only about 100-200 are actually doing anything at any given time. The only time there's an active connection is when the user is waiting for the screen to load. As I'm sure you know, most of the time in an interactive application, the computer is waiting for the user. In the case of 5250, when it's waiting for the user, it isn't using one of the child threads at all.

A more important factor than ThreadsPerChild is the amount of memory available to the HTTP server subsystem. Make sure you have enough memory and that it's allocated to the memory pools for QHTTPSVR. (If running Genie, you'll need adequate memory in both QHTTPSVR and your interactive subsystem as well.)

One of the most common performance mistakes is that people don't allocate enough memory to the HTTP server subsystem. folks in the IBM i community are used to giving the lion's share of their memory to the interactive subsystem, and when they switch to using Profound UI, it doesn't always occur to them that they now need just as much memory for HTTP as they do for interactive jobs.

Good Luck!