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. :-) ) /Henrik On Sun, Mar 1, 2009 at 12:48, Pavel Aleksandrov <[email protected]> wrote: > > Well, how do you exactly overcome doing the pre-calculation for each > apache/php instance (in my case)? That's where all the load comes > from, there are many implementations, but if you calculate several > hundred or more hashes each time a user opens a page, you get the > idea... > > Otherwise - very interesting talk guys, I hope something comes up, > that can be useful not only for me, but for other people having the > same problem! > > On 1 Март, 02:32, Henrik Schröder <[email protected]> wrote: > > > And the speed of consistent server selection really shouldn't be > noticeably > > slower than naive server selection, in the former you do a binary search > > into a small array, and in the latter you do a modulo operation, and > that's > > the only difference between them, but you still only hash your key once? > > > > The idea of pre-calculating your server continuum is that you only do it > > once on each webserver or client application, if you have to do it once > per > > lookup or once per webpage, you're screwed since the consistent server > > selection would be several thousand times slower, and that's probably > very > > noticeable. > >
