Rails core - Aug 2005 - fragment caching performace / implementation questions

Hi everyone,

I have done some experiments on the relative performance of the various 
fragment caching implementations. In the course of these experiments I 
reviewed the code, which raised some suspicion regarding the reliability 
and robustness of the inspected code when multiple instances of the 
rails app run in parallel.

If running inside mod_ruby or webrick, access by parallel threads to the 
memory store is protected via a Mutex instance, which should avoid cache 
corruption. However, if running multiple app instances, the in memory 
store can''t be used any more, as cache expiry doesn''t function
across
process boundaries.

Among the remaining alternatives, FileStore is fastest. But FileStore 
uses IO.read and IO.write to read and store cached content. If this 
isn''t an atomic operation on the file system, the disk store can easily
suffer corruption. I have looked at the C source of these functions and 
they don''t appear atomic to me. So, shouldn''t some file
locking be added
to FileStore?

DrbStore is about 35% slower, but I''m not sure about the reliability.

I also tested Danga''s memcached. Theoretically, this should be the most
scalable solution. But performance was reduced from 600 req/sec down to 
15 req/sec. This is slower than using no cache at all. So unless I made 
a terrible mistake, this caching method is practically useless. I 
suspect the slowness is caused by the pure ruby implementation of the 
client code. Has someone else tried memcached with Rails before?

Regards,

Stefan Kaes

PS: For FCGI setups, the mutexes in the current implementation are not 
necessary.

> I also tested Danga''s memcached. Theoretically, this should be the
most
> scalable solution. But performance was reduced from 600 req/sec down to
> 15 req/sec. This is slower than using no cache at all. So unless I made
> a terrible mistake, this caching method is practically useless. I
> suspect the slowness is caused by the pure ruby implementation of the
> client code. Has someone else tried memcached with Rails before?
This has been my observation as well. The pure ruby implementation of
the memcached library is worse then useless, i would actually prefer
if it wasn''t there at all.

There is c implementation of the memcached[1] library written by
seanc. Unfortunately there hasn''t been any visible progress since the
initial release but in my tests it was useable.

There is also zed shaw''s libevent wrapper which should make it easy to
write proper memcached c library if seanc''s work wouldn''t be a
acceptable basis to work from.

I''m no fan of either filestore or drb store. In my experience such
solutions always give diminishing returns in production use for
outside reasons like poor FS implementations, fragmentation or
constant garbage collection.

Memcached was designed from the ground up for this task and should be
the endorsed way to cache. Memcached also offers timed expiry which is
great for storing sessions or softening the blow of slashdottings.



[1]: http://rubyforge.org/projects/memcache/

-- 
Tobi
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog

Tobias Luetke wrote:
>>I also tested Danga''s memcached. Theoretically, this should be
the most
>>scalable solution. But performance was reduced from 600 req/sec down to
>>15 req/sec. This is slower than using no cache at all. So unless I made
>>a terrible mistake, this caching method is practically useless. I
>>suspect the slowness is caused by the pure ruby implementation of the
>>client code. Has someone else tried memcached with Rails before?
>>    
>>
>
>This has been my observation as well. The pure ruby implementation of
>the memcached library is worse then useless, i would actually prefer
>if it wasn''t there at all.
>  
>
Yeah. Would have saved me a lot of time :-(
>There is c implementation of the memcached[1] library written by
>seanc. Unfortunately there hasn''t been any visible progress since
the
>initial release but in my tests it was useable.
>  
>
Do you have a FragmentStore class ready for this library?
>There is also zed shaw''s libevent wrapper which should make it easy
to
>write proper memcached c library if seanc''s work wouldn''t
be a
>acceptable basis to work from.
>  
>
I think libevent is used internally by the memcached C API.
>I''m no fan of either filestore or drb store. In my experience such
>solutions always give diminishing returns in production use for
>outside reasons like poor FS implementations, fragmentation or
>constant garbage collection.
>  
>
I think for a setup with one machine running RAILS, FS could be used 
(with proper locking code). But it doesn''t scale beyond that. Drb 
garbage collection time can be reduced with the same techniques that I 
have applied to Rails.
>Memcached was designed from the ground up for this task and should be
>the endorsed way to cache.
>
I agree. The problem with memcached is you can''t use the 
delete_matched(regexp) method (which is not correctly implemented for 
Drb at the moment either, but this can be fixed).
>Memcached also offers timed expiry which is
>great for storing sessions or softening the blow of slashdottings.
>  
>
I never planned for that one, thanks for pointing it out ;-)


-- stefan

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails-core/attachments/20050815/bc123a62/attachment.html