On Monday 04 September 2006 22:28, Jack Faley ( The Tao of Jack ) wrote: > Thank you for your reply. If their was any way to mitigate the small exits > I would do it but I'm modifying an app that was never meant to be > extensible. So, you are correct, Im moving the load to a daemon in the > middle with a persistant connection rather than directly talking to DB2 :-) > . I havent benchmarked it. Im no dba but I have a feeling this will > actually be slower overall.
I don't see it being a DBA question - it's a machine resource question. If you have n apps connecting to DB2, you need n sockets. But if you have n apps connecting to a proxy which itself connects to DB2, you have n+1 sockets. If that proxy is on another machine, then you may save some resource. But if the proxy is on the same machine as the server, there's no way this will be as fast as direct connection, though it may not be noticeably slower, either, depending on the hardware. e.g., a single CPU on a fully loaded system will be much slower, but an 8-way system that is only 90% loaded may not be noticed. > I am holding hope DBD:Proxy connect_cached might do the trick but the docs > seem to indicate its not fully completed. No harm in trying though. Even if > it doesnt, I'll check the dba's quality to see if they can tell if there > are still all those connections after a "middleware" to pool them that > actually doesn't do anything. Each client will need to make a direct, individual, non-cacheable connection to the proxy. The proxy can make a cached connection to the server (as long as the previous connection isn't timed out, this will be pretty much a no-op). Note also that in this scenario, all exits must use the same authentication - if you're trying to get some stuff done as sysadm, and other stuff done as someone unprivileged, you'll need a different proxy for each user. > How would Stored Procedures help? Just for the performance after connected? Stored procedures start as pre-connected from the server. Not that DB2 allows Perl-based stored procedures, so you'd also have to rewrite them. But I'm not even sure that the logic you're doing will fit as a stored procedure - I brought it up more as a poke to make you think about whether this stuff is better as a stored procedure or not.
