Re^2: Connection pooling for a Net::Server application

Hi tilly, thanks for your detailed comment!

This is a classic example of creating new problems because you are not willing to fix an existing bad decision.

I am willing to fix this, but not right now, I just don't have the time for restructuring the complete project at the moment.

The 4th alternative looks like a clever solution, but I don't think it solves my problem - the users are typically on a fast LAN, so buffering for modem users is not an issue. As for the architecture, the mod_perl part is also not the problem, the architecture currently already has one additional tier - nearly no computations and no database lookups take place on the mod_perl interface, but they are all behind the connection the backend OpenXPKI server over a Unix domain socket.

As for inserting another tier, you've got a point. I still believe if that tier was lightweight enough, it might improve the performance ...

I'll have a look at FastCGI, but it will probably "only" solve the same problem as the reverse proxy, which seems like it might be attacking the wrong side of the problem. I guess we already have a rather unusual architecture to start with ...

Cheers,
Alex

Comment on Re^2: Connection pooling for a Net::Server application

Replies are listed 'Best First'.
Re^3: Connection pooling for a Net::Server application by perrin (Chancellor) on Aug 30, 2008 at 05:21 UTC
Even if your users are on fast LAN, if you're serving images from mod_perl, you're running a lot more mod_perl processes than you need to be. You might be able to cut the number of connections to your server from mod_perl in half or more just by reducing the number of mod_perl processes running with a reverse proxy.	[reply]
Re^3: Connection pooling for a Net::Server application by tilly (Archbishop) on Aug 29, 2008 at 23:56 UTC
FastCGI will also solve the problem of having to create an expensive database connection per web request. It does that by reusing processes from one request to the next. That problem will also be removed if you move the rest of the database interactions out of mod_perl. Heck, if you're right that virtually no database lookups happen then you could play the silly trick of replacing your database handle with a proxy object that will only connect if used. This will mean that any requests that don't touch the database don't connect to it.	[reply]