While that kind of query structure can be a huge issue the biggest problem, and performance penalty, occurs if the programmer is opening and closing actual real connections. A good structure would use a singleton connection that is opened only the first time it is called and the rest of the time returns the connection object already opened. Or, use pooling or similar types of things. You will get orders of magnitude increase in speed by not reopening the database multiple times per page especially if you are seeing 15,20 or especially hundreds of connections. Sometimes though you have no real choice but to build a system that has to generate multiple queries, so don't judge the page simply on the number of queries but on the completity of the reporting and the number of database connections opened(you will occasionally need more than one if you arn't pulling all the results at once, using cursors or partial retrievals instead and have to have multiple result sets open at any given time). James Kilbride > -----Original Message----- > From: Ryan A [mailto:genphp@xxxxxxxxx] > Sent: Monday, July 24, 2006 2:34 PM > To: Robert Cummings > Cc: php php > Subject: Re: database connections > > Hey Rob, > Thanks for replying. > > > > It's usually a sign of poor programming and/or purist OOP > programming. > > > > When I say purist OOP programming... > > I saw > > one really retarded > > implementation of this kind of system where an excess of > 20000 queries > > were issued to the database -- on a homepage nonetheless :/ > > > That IS retarded, I wonder why someone would want to do that. > > > > I think it > > was a testament to MySQLs speed that it performed within a > reasonable > > timeframe (under 3 seconds). > > MySql is a workhorse... def one of my top 3 DBs (I came into > LAMP from Java/Oracle) > > I see you have seen some of the apps I was talking about, > even though I have not mentioned any names to offend anyone. > > I was curious about this because I am working on a project > (with other team players) and we have a way of building > something with either lots more (complicated) code and fewer > database calls or less code and multiple tables. > > If we take the second option (multiple tables) I am talking > about maybe 15 database calls per page, and the site will get > around (i guess) 300-750 requests for a page a minute at is peak. > > The good thing is it will be running on a dedicated server, > sharing with around 5 of our other sites... no exceptionally > great traffic other than mentioned above on the other sites > either, plus most of the other sites are plain html sites. > > > > > Or am I blowing smoke and MySql can handle that without a > sweat on a > > > shared hosting environment? > > (with > > > say....100 page requests per minute?) > > > > MySQL can probably handle it. But try not to do programming > like that > > yourself. Stuff like that > gives PHP a bad name. > > > I wouldnt be going to those extremes, was thinking of around > 5-15 queries per page. > > > > Think we'll have a problem? > > Thanks! > Ryan > > ------ > - The faulty interface lies between the chair and the keyboard. > - Creativity is great, but plagiarism is faster! > - Smile, everyone loves a moron. :-) > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection > around http://mail.yahoo.com > > -- > PHP General Mailing List (http://www.php.net/) To > unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
