<div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">However, memcached semantics don&#39;t quite give you what you want.<br>Depending on whether you can reasonably get a configuration to do what
<br>you want, it might be easier to think of memcached as a bloom filter<br>than as a set in this case. &nbsp;That is, if you negatively cache things<br>that *aren&#39;t* part of your list, then the presence of a key will tell
<br>you for certain that a particular key is not a member, but the absence<br>of a key would mean that you don&#39;t know (or perhaps memcached *did*<br>know, but had since forgotten).</blockquote></div>
<div>&nbsp;</div>
<div>I had thought of doing a bloom filter on it as well.&nbsp; The problem here is, the membership list might change sometimes, and reading info on bloom filters, it&#39;s not really well-suited for dynamically changing lists?
</div>
<div>&nbsp;</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">You could optionally preload objects that are likely to be used if<br>you think the natural population wouldn&#39;t do it effectively (you can
<br>measure this with stats).<br></blockquote>
<div>Suppose I cache 10,000 recently-logged in members.&nbsp; Also, suppose 50% of traffic actually come from these users.&nbsp; Then, this cache would have a high hit ratio when testing for membership.</div>
<div>&nbsp;</div>
<div>However, what about the non-members?&nbsp; For instance let&#39;s say 40% of the traffic come from non-members.&nbsp; This would mean there&#39;d need to be a full listing of members to check?</div>
<div>&nbsp;</div>
<div>Hmmm an interesting thought did just come across my mind.&nbsp; Let me hear your thoughts:</div>
<ul>
<li>Cache 10,000 most recently logged-in members</li>
<li>Bloom filter on the entire list</li></ul>
<div>This way, you can test for negatives (bloom filter), and if there&#39;s a positive, check the 10,000 most recently logged-in users.&nbsp; If that still yields nothing, then do a database query.&nbsp; In effect, only a small minority of checks would require a trip to the DB.
</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><br>&nbsp;</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div></div>
<div class="Wj3C7c"><br>On Nov 4, 2007, at 23:32, J A wrote:<br><br>&gt; I have a fairly large members list that I want to keep in memcache.<br>&gt; What I do with this list is query it against particular user IDs to<br>
&gt; see if they are a member of that list or not. &nbsp;If they are they get<br>&gt; certain priviledges.<br>&gt;<br>&gt; The problem is, this list has gotten to the point of saturating the<br>&gt; PHP&#39;s memory when fetching the MySQL query the first time.
<br>&gt;<br>&gt; Is there a way to do this more effectively, for instance,<br>&gt; partitioning the list into separate smaller lists, grouped by time<br>&gt; of login? &nbsp;I&#39;m thinking of this, as users who have logged in in the
<br>&gt; past 3 months are more likely to be in the list anyway.<br><br><br></div>&nbsp; &nbsp; &nbsp; &nbsp;It&#39;d be easier to not think of it as a list if you&#39;re just testing<br>for membership. &nbsp;All you want to know is if a particular object is an
<br>element of a particular set. &nbsp;You could do this by key convention if<br>you batch populate the records.<br><br>&nbsp; &nbsp; &nbsp; &nbsp;However, memcached semantics don&#39;t quite give you what you want.<br>Depending on whether you can reasonably get a configuration to do what
<br>you want, it might be easier to think of memcached as a bloom filter<br>than as a set in this case. &nbsp;That is, if you negatively cache things<br>that *aren&#39;t* part of your list, then the presence of a key will tell
<br>you for certain that a particular key is not a member, but the absence<br>of a key would mean that you don&#39;t know (or perhaps memcached *did*<br>know, but had since forgotten).<br><br>&nbsp; &nbsp; &nbsp; &nbsp;You could, of course, record the status either way so as to tell the
<br>difference between not knowing and knowing whether it&#39;s a member or<br>not. &nbsp;This is probably best suited to your needs.<br><br>&nbsp; &nbsp; &nbsp; &nbsp;You could optionally preload objects that are likely to be used if<br>you think the natural population wouldn&#39;t do it effectively (you can
<br>measure this with stats).<br><br>--<br><font color="#888888">Dustin Sallings<br><br><br><br></font></blockquote><br>