Re: Re: pear on heavy loaded sites

Il 14:38, venerdì 15 novembre 2002, Manuel Lemos ha scritto: > 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? daily page views. about 30million montly. of course, not all pages are dynamically generated :-) i estimate about 25-30% of static pages. > 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. although i agree with you, we don't use multithreaded web server, since we use apache 1.3.x on linux. i read about apache 2.0 thread features: we're trying it in a developement server, but i'm waiting a stable release. > 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. where possible, we do the same. about this, i'm looking at pear cache system... > 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. easy... :-) we've choose to not use reverse proxies because of the costs/availability, while we use static page generation when it's possible. now i'm looking around DB.php class, finding the best way to expand that class on my need. pear team did a great work! :-) i will report my suggestions. bye, stain. -- "If there is any, error is human"