Right. So get your web server to talk to another web server, because you didn't make your application modular enough to run outside the web server?
Classic.
| [reply] |
Keeping an interpreter resident in memory is necessary for real speed with mod_perl, just as it is with PHP or Java servers. If you have enough traffic that you need to decouple the network I/O, using a front-end server works fine, or you could use more experimental options like lingerd. The front-end web server passing requests to a dynamic back-end server is an approach used by many tools, from FastCGI to high-end commercial application servers. The two servers happen to communicate over HTTP in this case, but the concept is nearly universal.
| [reply] |
Does it really make a tremendous difference whether your external process is a webserver or a dedicated application server like you recommend?
If you understand how it all works, the correct answer is, "Not really." They are both the same idea. Same problem. Similar kinds of overhead (though the application server can be a little more stripped down).
Given that, is there really a call for rudeness on your part?
| [reply] |
Does it really make a tremendous difference whether your external process is a webserver or a dedicated application server like you recommend?
Yes, it does. If it's an application server I only have to set one piece of software up and maintain it as changes to the site happen; if it's another apache instance, then I have to maintain two.
Apologies if I sound rude; but I've heard far too many people preaching the wonders of mod_perl, when it's really quite a silly idea.
| [reply] |