At the moment, we have a few background processes that continually poll the registries to deal with anything that needs (near) real-time processing. There are also customer facing tools (APIs, web pages) that use the same modules and these would mainly benefit from the speed increase. The daemons would just benefit from a slightly more abstracted design. Since it takes 4 or 5 seconds to set up a connection, and only 0.5s to make a query, it would be ideal to keep the handles alive and share them when needed. And they're blocking right now... It would be a pretty big timesink to move all the existing modules onto non-blocking IO. The box is running a 2.4.22 kernel, Perl 5.8.1.
in reply to Re: Resource pools and concurrency
in thread Resource pools and concurrency