Hi,
I am trying to do fragment caching using :mem_cache_store. However, when I
compare it to fragment caching using :file_store, it seems to be a lot
slower.
Here are the results:
uncache
Completed in 2.20246 (0 reqs/sec) | Rendering: 2.19891 (99%) | DB:
0.00017(0%) | 200 OK [
http://127.0.0.1/]
using file_store
Completed in 0.00952 (105 reqs/sec) | Rendering: 0.00702 (73%) | DB:
0.00000(0%) | 200 OK [
http://127.0.0.1/]
using memcache
Completed in 0.03558 (28 reqs/sec) | Rendering: 0.02561 (71%) | DB:
0.00000(0%) | 200 OK [
http://127.0.0.1/]
Other Notes:
- I''ve tried using both Ruby-MemCached0.4 and memcache-client libraries
and
the results are about the same.
- I am sure there is no paging.
Memcached execution parameters:
memcached -m 256 -l 127.0.0.1 -p 11211 -vv
ldd /usr/local/bin/memcached results:
linux-gate.so.1 => (0x0036a000)
libc.so.6 => /lib/libc.so.6 (0x0088e000)
/lib/ld-linux.so.2 (0x00870000)
My environment: uname -a
Linux 2.6.14-1.1656_FC4 #1 Thu Jan 5 22:13:22 EST 2006 i686 athlon i386
GNU/Linux
I''m stumped. Isn''t it memcache store should be faster than
file store since
there is no disk access? Would somebody be able to explain?
Thanks,
Mac
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060121/b7479e63/attachment.html
On 1/21/06, big mac <bigmac928@gmail.com> wrote:> I''m stumped. Isn''t it memcache store should be faster than file store > since there is no disk access? Would somebody be able to explain?I''m just starting to work with memcache too, but this is what I think is going on... Your file_cache number is running out of RAM the same as memcache. That''s because the OS has cached the file. memcache is running out of RAM but it is using a communication protocol with a lot more overhead. That''s why it''s slower. But, memcache is only a win when multiple machines are involved. memcache let''s you share a single cache between all of the machines where each object is only stored once in the cache. So if you have 50 machines each running a 1GB memcache you have a 50GB cache. But this cache is slower since you need to use the network to access the remote caches. With file_store each cache in independent. Each OS has 1GB cache so the same object is getting cached over and over in the various machines. You have 50 1GB caches, each of which is faster than memcache, but they are only 1GB caches. If you are running a model where each request can end up at a randeom server you needs to transfer the session data to the current server. This is where memcache is a big win, there is one cache for all the servers. Just look your session up, it will be there. With file_cache you would have to put the session data in the database and share it that way. -- Jon Smirl jonsmirl@gmail.com
big mac wrote:> Hi, > > I am trying to do fragment caching using :mem_cache_store. However, when I > compare it to fragment caching using :file_store, it seems to be a lot > slower. > > Here are the results: > > uncache > Completed in 2.20246 (0 reqs/sec) | Rendering: 2.19891 (99%) | DB: > 0.00017(0%) | 200 OK [ > http://127.0.0.1/] > > using file_store > Completed in 0.00952 (105 reqs/sec) | Rendering: 0.00702 (73%) | DB: > 0.00000(0%) | 200 OK [ > http://127.0.0.1/] > > using memcache > Completed in 0.03558 (28 reqs/sec) | Rendering: 0.02561 (71%) | DB: > 0.00000(0%) | 200 OK [ > http://127.0.0.1/] > > Other Notes: > - I''ve tried using both Ruby-MemCached0.4 and memcache-client libraries and > the results are about the same. >You must make sure that only one version of the file memcache.rb is in your load path. Otherwise you might be using Ruby-MemCached0.4. I wished Eric had named his file and class differently (FastMemCache e.g.). I have measured the speed of memcache against using DB session storage and was disappointed as it was 2 times slower. But after I cleared out the above problem it was faster than DB storage. I''ll blog exact figures later. -- stefan -- For rails performance tuning, see: http://railsexpress.de/blog Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml
big mac wrote:> Hi, > > I am trying to do fragment caching using :mem_cache_store. However, > when I > compare it to fragment caching using :file_store, it seems to be a lot > slower. > > Here are the results: > > uncache > Completed in 2.20246 (0 reqs/sec) | Rendering: 2.19891 (99%) | DB: > 0.00017(0%) | 200 OK [ > http://127.0.0.1/] > > using file_store > Completed in 0.00952 (105 reqs/sec) | Rendering: 0.00702 (73%) | DB: > 0.00000(0%) | 200 OK [ > http://127.0.0.1/] > > using memcache > Completed in 0.03558 (28 reqs/sec) | Rendering: 0.02561 (71%) | DB: > 0.00000(0%) | 200 OK [ > http://127.0.0.1/] > > Other Notes: > - I''ve tried using both Ruby-MemCached0.4 and memcache-client libraries > and > the results are about the same. > - I am sure there is no paging. > > Memcached execution parameters: > memcached -m 256 -l 127.0.0.1 -p 11211 -vv > > ldd /usr/local/bin/memcached results: > linux-gate.so.1 => (0x0036a000) > libc.so.6 => /lib/libc.so.6 (0x0088e000) > /lib/ld-linux.so.2 (0x00870000) > > My environment: uname -a > Linux 2.6.14-1.1656_FC4 #1 Thu Jan 5 22:13:22 EST 2006 i686 athlon i386 > GNU/Linux > > I''m stumped. Isn''t it memcache store should be faster than file store > since > there is no disk access? Would somebody be able to explain? > > Thanks, > MacHi, That s a bit old post, but today I got the same. I have plenty of RAM, use memcached gem and whatever I do, I can''t go over 185 r/s with mem_cache_store and go to 205 r/s with file_store. Every thing is on a single freebsd machine, and I dont understand how file storage can be faster than memory. Some other tests show memory_store is 10x faster on rendering. Anyone could help me to find the light ? thanks, -- Stephane -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---