On 9/5/06, Darin McBride <[EMAIL PROTECTED]> wrote:
On Tuesday 05 September 2006 10:14, you wrote: > On 9/5/06, Darin McBride <[EMAIL PROTECTED]> wrote: > > On Monday 04 September 2006 22:28, Jack Faley ( The Tao of Jack ) wrote: > > 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. > > The dba's are PURELY interested in the number of open connections done as > they generate DB2 overhead. Im no dba but they tell me all sorts of DB2 > files and things go on evrytime DB2 opens a new connection. I don't see it > as being a problem at all honestly since these will occur periodically but > I must defer to the dba's.. About the only thing I can think of that you're really saving is the authentication phase - and that sounds really dangerous to me. It's like opening a security hole.
Yes, as I indicated before, Im going to find out just how much overhead is involved in many short open connection / disconnects versus funneling through the proxy. Ive been browsing modules because the proxy module documentation makes me slightly concerned some portions of cached_connection aren't full implemented ( not DBI ). I ran across Pixie and Tangram. Are you familiar or have an opinion on these?
> 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. > > All the connections will use the same user so this will not be a problem. Unless someone hacks a way to get in to the proxy - you'll need authentication from the proxy as well. And will it be encrypted? > > 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. > > Thanks on this. The stored procedures won't really be a benefit at this > point to me and again the dba's just don't want a lot of "open connection > overhead". Im going to look into this after I get finished just to see how > much REALLY is being saved. > > Your statement above seems defnitive about the proxy making a cacheable > connection which brightened my morning. Yes - because the proxy can sit there as a concentrator - it lives in its own process space, and stays running even when nothing is using it. (Technically, you could design it to die after 5 minutes or something of non-use, and then have the interface module auto-start it when it's needed, to reduce resource requirements when not active, but I would personally try to avoid that if possible - way too much work for way too little return.) Because it's a single long-lived process, it can use a cached connection. As you've no doubt learned, connections cannot be passed from process to process - so this is only of use when you're still in the same process. In fact, it seems that DBD::Proxy explicitly gives this as a potential use for itself in CGI environment (lots of short-lived processes for CGI, not so much for mod_perl).
Ugh, the proxy authentication prior to DB2 authentication presents another thing to pursue. There's a lot to be said for embedded databases...... Thanks for all your information! (Sorry I just realized a few messages were to you not the list!)
