<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Arial"><big>Hi!<br>
Absolutely awesome stuff and its wonderful that you reply. We really
appreciate it. Sorry if I'm a bit drippy here but its good I think to
over acknowledge. <br>
This is really good stuff and we'll put your advice about
serialization in our work que. </big></font></font><font size="-1"><font
face="Arial"><big> However, if you do take the
time to add multiple pools this would be much simpler for us to do
since it would just involve a size test to determine which pool.<br>
</big></font></font><br>
<font size="-1"><font face="Arial"><big> Again, thanks so much. <br>
<br>
<br>
Sincerely,<br>
-Mybrid</big><br>
</font></font><br>
Greg Whalin wrote:
<blockquote cite="mid42556740.8030402@meetup.com" type="cite">I
responded to you directly, but will update to the list. We saw similar
behavior simply due to the objects we were caching. Most of our
objects were fairly small in size, but the occassional object would be
much much larger (10-15 times larger than our average). These objects
would show up to be cached at random points, and generally well after
the memcached server had "settled in". We would get out of memory
errors.
<br>
<br>
We dealt with this problem in two ways. One, we stopped relying on
default java serialization. While the default serialization works
great, it is far from being efficient if you care about size of the
serialized object. Instead, we use java.io.Externalizable and we
implemented our own serialization scheme. Instant 60% savings in size
of objects.
<br>
<br>
Second, we turned on gzip compression in the client. Now, my tests and
benchmarks show that java gzip compression is slow ... horribly slow,
so we really wanted to avoid using it wide scale. We set our
compression threshold so that we only compressed objects > 128K.
This combination of things solved all of our problems. We have yet to
see another out of memory error from memcached in 8 months of heavy
usage.
<br>
<br>
Now, as to multiple pools. Currently, the java memcache client pool is
a singleton, so it is not possible to create multiple pools. I think I
could modify the code to allow for multiple pools pretty easily, but I
would need to go through everything to make sure all code would
continue to work correctly. If I get some time, I will look into this
approach over the weekend.
<br>
<br>
Greg
<br>
<br>
Mybrid Spalding wrote:
<br>
<blockquote type="cite">Hi!
<br>
Happy Thursday! Thanks so much for replying.
<br>
Ok, here is more detail. We are having excellent success with this
very well designed product. One problem we are having is that large
objects only have a cache hit rate of 45% while small objects are 90%
plus. We speculate the root cause is that our web site uses objects of
every size imaginable and that there is not enough slab space for large
sized objects. We'd like to experiment with segmenting by writing
objects larger than X to one cache pool where we tune X.
<br>
Any thoughts on this would be greatly appreciated. JFYI, your cache
has helped us nearly double our bandwidth and we really truly
appreciate this product.
<br>
<br>
Thanks!
<br>
-Mybrid
<br>
<br>
<br>
<br>
Thanks!
<br>
-Mybrid
<br>
<br>
Brad Fitzpatrick wrote:
<br>
<br>
<blockquote type="cite">Why don't you just make one pool that's
twice as big, then?
<br>
<br>
If a node in a pool dies, the memcached client just routes around it
and
<br>
spreads the load to the nodes that are still alive.
<br>
<br>
<br>
On Tue, 5 Apr 2005, Mybrid Spalding wrote:
<br>
<br>
<br>
<br>
<blockquote type="cite">Hi!
<br>
Greetings from a first-time poster. I'm currently using the Java
<br>
client to connect to memcached. For robustness reasons I'm thinking of
<br>
segementing traffic to different caches. That way if one cache pool
goes
<br>
down I can route to another. However, reading the Java docs its not
<br>
obvious to me how to or a good strategy.
<br>
<br>
<br>
Thanks!
<br>
-Mybrid
<br>
<br>
<br>
</blockquote>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Mybrid Spalding
CTO-DataRebels, Inc.
1920 Rock Street #2
Mountain View, CA 94043
Office: (650) 965-4217
Mobile: (650) 450-1636
<a class="moz-txt-link-abbreviated" href="http://www.datarebels.com">www.datarebels.com</a>
</pre>
</body>
</html>