| Previous · Next | |
| User | Message |
|
JT
|
Date: 9/24/2009 6:51 pm · Subject: wg8 memcached q&a · Rating: 0
I've created a basic implementation of the new memcached caching system for WebGUI 8, not as a final piece of production quality code, but rather as a point to start the discussion of what this API should look like and do. From my point of view it has two main goals: - Do roughly what our old one did. - And do that faster. For the purpose of this conversation I'm ignoring WebGUI::Cache::FileCache. It's ridiculously fast when there's very little in the cache, but quickly becomes dog slow and prone to corruption if your site has more than a few hundred assets in it. When I say "old" I mean WebGUI::Cache::Database, and when I say "new" I mean WebGUI::Cache based upon Memcached::libmemcached. I also tried Cache::Memcached, which is the primary memcached module, but that was about 250% slower than Memcached::libmemcached. I also played around with a bunch of the other modules on CPAN, but none were as fast as Memcached::libmemcached, and some of them I couldn't get to install at all. You can see my rough implementation here: http://github.com/plainblack/webgui/blob/WebGUI8/lib/WebGUI/Cache.pm Note that there are no tests for it yet, and I haven't added any exception handling. That's why I'm calling it rough. I'm also not saying it's the final implementation. I think the new API is quite a bit nicer than the old one, and we can do pretty much everything we can do in the old one. The new one can get multiple keys at once (and that's faster than doing it one at a time), which the old couldn't do. And the old one could do a cascading delete, but the new one can't do that. The cascading delete was quite nice, but there are better ways to achieve the same thing. I built a little performance test to make sure the second goal was met. I ran two tests, one with 562 cache objects, and one with 26440 cache objects. The small cache had these results for reading (smaller is better): old: 0.164521 new: 0.043474 And for writing: old: 0.184233 new: 0.059643 The large cache is more dramatic for reading: old: 8.99298 new: 1.984525 And writing: old: 8.780973 new: 2.825412 Both of these tests are connecting to mysql and memcached using a unix socket. Over TCP each result is slightly slower, but the same magnitude comes across. In addition, for these tests memcached was configured to use 64 megabytes of RAM. You can see the speed difference is fairly staggering, but there are huge benefits beyond just these performance numbers. For one, by moving the cache to another system (memcached) we're taking some additional stress off the database, which means that the database will perform faster overall. For another, on large sites this allows you to move the caching off to another server, or another series of servers, which increases your scalability tremendously. So given these numbers, and the new API (http://github.com/plainblack/webgui/blob/WebGUI8/lib/WebGUI/Cache.pm ), what comments do you have for me? Are there any features missing that I should take into account before writing tests, adding exceptions, and then integrating it into the core? |
| Back to Top |
Rate [ | ]
|
|
patspam
|
Date: 9/24/2009 7:46 pm · Subject: Re: wg8 memcached q&a · Rating: 0
The only problem I see is now that you've implemented the most awesome feature for 8.x, nothing else for the next 18 months is going to seem nearly as amazing.Patrick On Fri, Sep 25, 2009 at 9:51 AM, <jt@plainblack.com> wrote: JT wrote: |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 9/24/2009 7:56 pm · Subject: Re: wg8 memcached q&a · Rating: 0
> The only problem I see is now that you've implemented the most > awesome feature for 8.x, nothing else for the next 18 months is > going to seem nearly as amazing. Ha! Hardly! I think everything we're doing in WebGUI 8 is super exciting. |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 9/24/2009 10:32 pm · Subject: Re: wg8 memcached q&a · Rating: 0
Oops. Wrong URL for the new module:
http://github.com/plainblack/webgui/blob/memcached/lib/WebGUI/Cache.pm |
| Back to Top |
Rate [ | ]
|
|
nils-magne
|
Date: 9/25/2009 2:25 am · Subject: Re: wg8 memcached q&a · Rating: 0
Just to make sure you know about this too The Varnish prosject It is known to be very fast, but I don't know if it is of any use for WebGUINils-Magne
|
| Back to Top |
Rate [ | ]
|
|
martink
|
Date: 9/25/2009 3:00 am · Subject: Re: wg8 memcached q&a · Rating: 0
Hi JT,Looks good to me! I was wondering, though, if you had look into the *_by_key methods of Memcahed::libmemcached. See http://search.cpan.org/~dmaki/Memcached-libmemcached-0.3102/libmemcached.pm#Grouping_Keys_On_Servers. According to the docs, these methods can force related data to be cached on the same server. I think this could make sense for cache retrieval in the mget method especially. As far as I understand, this applies only to multi-memcached server setups, so in many cases it would probably not make a difference. However, with WG8 will be all about scalability I thought I'd mention it. Martin jt@plainblack.com wrote: > JT wrote: > > I've created a basic implementation of the new memcached caching > system for WebGUI 8, not as a final piece of production quality code, > but rather as a point to start the discussion of what this API should > look like and do. > > From my point of view it has two main goals: > > - Do roughly what our old one did. > - And do that faster. > > For the purpose of this conversation I'm ignoring > WebGUI::Cache::FileCache. It's ridiculously fast when there's very > little in the cache, but quickly becomes dog slow and prone to > corruption if your site has more than a few hundred assets in it. > > When I say "old" I mean WebGUI::Cache::Database, and when I say "new" > I mean WebGUI::Cache based upon Memcached::libmemcached. I also tried > Cache::Memcached, which is the primary memcached module, but that was > about 250% slower than Memcached::libmemcached. I also played around > with a bunch of the other modules on CPAN, but none were as fast as > Memcached::libmemcached, and some of them I couldn't get to install at > all. > > You can see my rough implementation here: > http://github.com/plainblack/webgui/blob/WebGUI8/lib/WebGUI/Cache.pm > > Note that there are no tests for it yet, and I haven't added any > exception handling. That's why I'm calling it rough. I'm also not > saying it's the final implementation. > > I think the new API is quite a bit nicer than the old one, and we can > do pretty much everything we can do in the old one. The new one can > get multiple keys at once (and that's faster than doing it one at a > time), which the old couldn't do. And the old one could do a cascading > delete, but the new one can't do that. The cascading delete was quite > nice, but there are better ways to achieve the same thing. > > I built a little performance test to make sure the second goal was > met. I ran two tests, one with 562 cache objects, and one with 26440 > cache objects. > > The small cache had these results for reading (smaller is better): > > old: 0.164521 > new: 0.043474 > > And for writing: > > old: 0.184233 > new: 0.059643 > > The large cache is more dramatic for reading: > > old: 8.99298 > new: 1.984525 > > And writing: > > old: 8.780973 > new: 2.825412 > > Both of these tests are connecting to mysql and memcached using a unix > socket. Over TCP each result is slightly slower, but the same > magnitude comes across. In addition, for these tests memcached was > configured to use 64 megabytes of RAM. > > You can see the speed difference is fairly staggering, but there are > huge benefits beyond just these performance numbers. For one, by > moving the cache to another system (memcached) we're taking some > additional stress off the database, which means that the database will > perform faster overall. For another, on large sites this allows you to > move the caching off to another server, or another series of servers, > which increases your scalability tremendously. > > So given these numbers, and the new API > (http://github.com/plainblack/webgui/blob/WebGUI8/lib/WebGUI/Cache.pm > ), what comments do you have for me? Are there any features missing > that I should take into account before writing tests, adding > exceptions, and then integrating it into the core? > > > > http://www.webgui.org/develop/forum/wg8-memcached-qa > ------------------------------------------------------------------------ > > > > |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 9/25/2009 9:00 am · Subject: Re: wg8 memcached q&a · Rating: 0
> Looks good to me! I was wondering, though, if you had look into the> *_by_key methods of Memcahed::libmemcached. See > http://search.cpan.org/~dmaki/Memcached-libmemcached-0.3102/libmemcached.pm#Grouping_Keys_On_Servers > . > According to the docs, these methods can force related data to be > cached > on the same server. I think this could make sense for cache > retrieval in > the mget method especially. I did look at it, but the namespace / master key that we are working with is the site name. So while it would make sense on small servers serving many sites, on very large sites it would mean that the system would only ever use 1 memcached server, which is exactly the opposite of what we want. And on small servers serving many sites you'll likely only have 1 memcached server anyway, so you won't get any real gain there. > As far as I understand, this applies only to multi-memcached server > setups, so in many cases it would probably not make a difference. > However, with WG8 will be all about scalability I thought I'd > mention it. Thank you. If I hadn't seen it I'd definitely want to take a look at it. Unfortunately it just doesn't look useful for us. |
| Back to Top |
Rate [ | ]
|
|
cap10morgan
|
Date: 9/25/2009 12:10 pm · Subject: Re: wg8 memcached q&a · Rating: 0
On Fri, Sep 25, 2009 at 8:00 AM, wrote:> JT wrote: > >> Looks good to me! I was wondering, though, if you had look into the >> *_by_key methods of Memcahed::libmemcached. See >> >> http://search.cpan.org/~dmaki/Memcached-libmemcached-0.3102/libmemcached.pm#Grouping_Keys_On_Servers >> . >> According to the docs, these methods can force related data to be >> cached >> on the same server. I think this could make sense for cache >> retrieval in >> the mget method especially. > > I did look at it, but the namespace / master key that we are working > with is the site name. So while it would make sense on small servers > serving many sites, on very large sites it would mean that the system > would only ever use 1 memcached server, which is exactly the opposite > of what we want. And on small servers serving many sites you'll likely > only have 1 memcached server anyway, so you won't get any real gain > there. What about large, multi-server setups serving 90+ sites? We would probably run several memcached servers under WebGUI 8. It seems like this could benefit us with the site data locality (if I'm understanding it correctly). If you agree, I may add it to the list of things for us to consider sponsoring. > > >> As far as I understand, this applies only to multi-memcached server >> setups, so in many cases it would probably not make a difference. >> However, with WG8 will be all about scalability I thought I'd >> mention it. > > > > Thank you. If I hadn't seen it I'd definitely want to take a look at > it. Unfortunately it just doesn't look useful for us. > > > http://www.webgui.org/develop/forum/wg8-memcached-qa/7 > > > -- > > WebGUI > http://www.webgui.org > > -- "Small acts of humanity amid the chaos of inhumanity provide hope. But small acts are insufficient." - Paul Rusesabagina, Rwandan and former hotel manager whose actions inspired the movie Hotel Rwanda |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 9/25/2009 12:30 pm · Subject: Re: wg8 memcached q&a · Rating: 0
> What about large, multi-server setups serving 90+ sites? We would> probably run several memcached servers under WebGUI 8. It seems like > this could benefit us with the site data locality (if I'm > understanding it correctly). If you agree, I may add it to the list of > things for us to consider sponsoring. It would only really help you on mgets. Almost nothing in WebGUI will use mgets (at least as of now). So unless you're writing a bunch of code that uses mgets I'd say this isn't a big win for you. There would be some benefit on other connections as well, but the big benefit comes from mgets. I'll give it some thought, but as of now I don't know how we can make this easily support both needs without screwing it up for someone. Your situation is the one that this would hurt least as of now. Maybe we can make this configurable in some way without killing performance. |
| Back to Top |
Rate [ | ]
|
|
cap10morgan
|
Date: 9/25/2009 2:05 pm · Subject: Re: wg8 memcached q&a · Rating: 0
On Fri, Sep 25, 2009 at 11:30 AM, wrote:> JT wrote: > >> What about large, multi-server setups serving 90+ sites? We would >> probably run several memcached servers under WebGUI 8. It seems like >> this could benefit us with the site data locality (if I'm >> understanding it correctly). If you agree, I may add it to the list of >> things for us to consider sponsoring. > > > It would only really help you on mgets. Almost nothing in WebGUI will > use mgets (at least as of now). So unless you're writing a bunch of > code that uses mgets I'd say this isn't a big win for you. There would > be some benefit on other connections as well, but the big benefit > comes from mgets. > > I'll give it some thought, but as of now I don't know how we can make > this easily support both needs without screwing it up for someone. > Your situation is the one that this would hurt least as of now. > > Maybe we can make this configurable in some way without killing > performance. OK, thanks for the explanation. In that case I agree that we don't need it. But yes, if we do discover it's a big win for us but would hurt more common setups, then it should absolutely be a configuration option (with us on the non-default setting). > > > http://www.webgui.org/develop/forum/wg8-memcached-qa/9 > > > -- > > WebGUI > http://www.webgui.org > > -- "Small acts of humanity amid the chaos of inhumanity provide hope. But small acts are insufficient." - Paul Rusesabagina, Rwandan and former hotel manager whose actions inspired the movie Hotel Rwanda |
| Back to Top |
Rate [ | ]
|
