> 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.
