Re: Large PHP/Database driven site & scalability

ultimately I am going to probably do the #2 setup i've talked about - and have from this processes of thinking about it decided it would meet the needs of scalability more - where I need the php connection pool is the front end web servers - each will need a connection pool for a) the userInfo server (that they a lone are connected to) b) a content server (or a content server pool - based upon a simple db replication and round robin dnsing) c) "multi-user" server pool - which may include a unique pool of different servers depending on the multi-user specific task - type of setup which would have data that would be more immediately read/wrote to by any user for every user type of thing so the need for the connection pool is obviously when one apache child is grabbing from the content server there is another that can use the multiuser setup - I do have the mysql modified for >500 current connections and etc - I do still require a connection pool to do as much as I can to limit the connections to the "multi-user" database servers...and those user-independant servers - so that each webserver we have running on say 10 apache servers - each with 255 processes don't make it so the db has 2550 idle connections on it - just the select() by the mysqlserver on all those file descriptors or by the OS or whatever is a lot of extra cpu cycles that aren't needed Thanks again, Eric On Wed, 19 Jul 2000, Michael Kimsal wrote: > Hello again Eric, > > This is something we go back and forth on here. I'm not sure > why you want connection pooling. As I wrote before, it is > something we've looked in to, but as we discuss it, one thing > keeps coming up: any pooling mechanism is going to > reduce efficiency. The only benefit I see to it is handling errors > if/when there are more PHP connections than MySQL available > connections. Have you modified MySQL to be able to handle > >500 concurrent connections? > > The Perl stuff we looked at was initially for Perl code, and we > were trying to get it to deal with PHP, but we don't know > enough about the PHP internals to interface properly. Again, > I suspect this would take some custom module writing, a bit > beyond our capabilities at this point in time. > > Can you let me know what benefits you are looking for with > pooling? There may be something I've overlooked. The other > benefit is keeping yourself in line with licensing, of course > (limit pool to max of 50 connections if your DB is licensed for > max of 50, but MySQL doesn't have that licensing limitation, does it?) > > > -- > ========================== > Michael Kimsal > http://www.tapinternet.com > 734-480-9961 > > >