We are already using high MaxRequestsPerChild. I talked with our administrator. The problem can be solved using less apache processes and using threads, then they will share the persistent connections, but we use eaccelerator in combination with PHP4, which doesn't play well with threads. We will try a migration to PHP5, which should solve this problem and we will try using threaded apache processes. I will write when we have some results.
On 3 Март, 00:00, "Dean Harding" <[email protected]> wrote: > > Well, you could store the pre-calculated results in a shared cache.. oh > > wait.. > > > No, it really shouldn't be a problem to do those calculations once per > > webserver, in a sort of average real-world case you'd end up needing a > > few thousand hashes, and if you have a website with lots of incoming > > requests that each generate a lot of memcache gets, you'll be looking > > at doing hundreds, maybe thousands of hashes per second. It doesn't > > seem right that you should have a problem initializing your memcached > > client with a few thousand hashes once, but have no problems sustaining > > a throughput of maybe a thousand hashes per second? > > > (Assuming this is, of course, what the php memcached client does, I've > > never used it myself. :-) ) > > That what I would have thought, but I'm guessing from what has been said that > in this case, a new php process is being started for each request, which > means you need to initialize the client once for each request. I'm talking > about this quote specifically: > > [Pavel Aleksandrov] > > > if you calculate several hundred or more hashes each > > time a user opens a page, you get the idea... > > Personally, I think the solution would be to set the MaxRequestsPerChild much > higher in order to reuse the same php process for many requests, but maybe > that's not an option? Or maybe I misunderstood that quote... > > Dean.
