Re: pear on heavy loaded sites

On 11/15/2002 10:52 AM, Stain wrote:

approaching to pear, i find it really interesting, but i would know if exists any documentation or previous messages about pear objects working on heavy loaded sites, especially about db objects working with different db servers... this is my experience. i have a db server with mysql-max, recompiled and optimized on our needs and several web servers delivering about 1 million daily page views. say web

Page views or hits? Daily or monthly?

server as "A" and db server as "B". writing my own php classes, providing db connection handling, i find out pretty things when reading lot of data from several scripts of my site. i used some "hand-made" class providing db connection, just like some DB/pear-like functionality such as query(), fetch(), etc. my aim was also to abstracts results set store method. i try to explain... when using such class, database connection works differently if you change results fetch operations, storing results directly into class or not. i tried two different ways: 1. let developer (who writes directly script codes) manage directly fetch() function, deciding when reading one rows and another and so on. this means, if developer do some time-spending operations during a fetch-cicle, db connection wait with result set stored in B (mysql buffer). 2. fetch result set directly into a class object, fetching internally all result set in an array-object. when developer starts fetch cicle, results are stored internally in a class object, so mysql connection doesn't required to be persistent and let buffers free. at least, results are stored internally by php db buffer (?), but i prefer A goin' slow, than B. i find out that the 2nd way is better when you have many db connections, since in the 1st case B waits for new request until another fetch() is done, while in the 2nd case db class fetches all rows one time and store them into A, waiting for script reading and cut off db waiting. further, this is why, with heavy-loaded db server, i prefer not use persistent connections.

I use persistent connections because the overhead of establishing a connection is high. The connections are only established on demand, only before the first query. If there are no queries, no connection is used. This would be more efficient in multithreaded Web servers because the same connection could be reused by different Web server threads that share the same pool of persistent connections. This way you may end up needing less persistent connections to serve more simultaneous requests. I also use file base caches for frequently accessed information. I usually don't cache result sets because the gains are small. I cache the actual HTML (or XML for RSS content) that is generated from database stored data. The gains are higher because it avoids the overhead of PHP while traversing result sets and processing the data taken from them. Now, for really busy Web sites, I recommend static pages generation or a reverse proxy in the front of the real Web server. These issues are less PHP related. -- Regards, Manuel Lemos