Interesting reading. Thanks!

GilmarSantosJr - 30 Sep 2008:

Yeah, interesting reading!

However, the article misses some important information, like which topics were requested. It can change the results a lot. Suppose a topic like TWikiFeatureProposals: the bottleneck there are the many embedded searches (and high number of topics within Codev). From the results with 25 users and the got improvement, I guess the topic used was Main.WebHome, that is simple and small (my empiric measures showed me that about half of processing time of this topic is the fork-and-compile phase, so no surprise there was a 2x gain ).

The given description of mod_perl states that it can fork a configurable number of perl processes. I really want to know how to do that. The only way I know is to limit the MaxClients configuration, that applies to the whole web server, not only to perl applications, since mod_perl embeds the aplication into the web server (no forked perl processes).

I have studied TWiki performance and performance metrics to make my under-graduation conclusion job (in Portuguese), that resulted on TWikiStandAlone, and one of the lessons I learned was that load is not so good to measure CPU usage: it measures how many processes are waiting for a processor, so we get an obvious result: using TWiki as a CGI (one forked process for each request) will lead to high loads. OTOH if you use a fixed/controlled number of persistent back-end processes, then the load simply can't be so high! (And it almost can be managed to the value you want, by controlling the number of persistent back-ends) How this magic is performed? Requests waits for an available back-end (instead of waiting for a processor). And that queue is not measured by the load (and reflects on latency observed by users. However, the higher latency is compensated by the fact that each request is processed faster).

In the beginning of the article SpeedyCGI and mod_perl are cited and they have similar approach to improve performance: eliminate fork-and-compile phase. Then, IMHO, there is another important information missing: how does Glassfish/LRWPinJava compares to those? And to FastCGI? I also could make a wrapper to use TWiki "unmodified" with FastCGI.

So, a (IMHO, more) interesting test would be to compare Glassfish/LRWPinJava, FastCGI, SpeedyCGI and mod_perl (with prefork and worker MPMs), using simple and complex topics.

But absolutely Glassfish/LRWPinJava is another interesting execution mechanism and TWikiStandAlone architecture makes it fairly easy to add direct support to Glassfish (or any other web/application server that implements the LRWP protocol) with a LRWPEngineContrib.