<div dir="ltr">Thanks a lot for your answer. <div><br></div><div>I guess that is an excellent answer on "why does swift explicitly disable object data caching at the page cache level". But my question is a bit different "Why doesn't swift use memcached to cache object data?" Not that it is a bit different than implementing it yourself at the proxy server. All you need to do is to write a middleware to talk to the memcached cluster, and swift already does that for account info etc. </div><div><br></div><div>Is it because of the potential consistency issue? Or maybe you assume your clients already have caching solution on top of Swift (like vanish, as you mentioned. But that's very specific to http caching...) </div><div><br></div><div>I would really appreciate if you could further explain this. </div><div><br></div><div>Suli</div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 25, 2015 at 4:01 PM, John Dickinson <span dir="ltr"><<a href="mailto:me@not.mn" target="_blank">me@not.mn</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You're right. Caching object data is one way to really speed up reads to content that is stored in Swift and accessed frequently. Often time, deployers use existing tools like squid, varnish, or a CDN to do that.<br>
<br>
But that still leaves the question "why don't we cache the object data in Swift?". The short answer is that we sacrifice potential end-user time-to-first-byte gains in favor of reliability in the overall system.<br>
<br>
The longer answer requires a bit more explanation of how Swift is put together.<br>
<br>
Think of Swift as having 3 layers: the proxy which accepts API requests and coordinates data with the storage servers, the storage servers which persist data, and the actual storage media (ie hard drives). Each hard drive that is plugged in to a storage server is formatted with a local filesystem (eg XFS). Swift lays out the data across the filesystems in the cluster such that one object ends up being one file per replica on a filesystem somewhere (for replication. erasure codes are slightly different).<br>
<br>
As a cluster grows to many hard drives and fills up with more data, each of those individual filesystems on the drives in the cluster get more and more data on them. And since the data is stored in a local filesystem, that means that there is filesystem overhead there too (inodes, dentries, etc). The reality is that it's not too hard to have more inode entries on a moderately full 6TB drive than available memory on the system. This means that the system page cache can be entirely flushed by simply walking the data. And Swift walks the drives to make sure the data is correct and durably stored in the cluster.<br>
<br>
Since the health of the data and recovery from hardware failure is directly dependent on Swift's ability to walk the data, it's important that we prioritize filesystem metadata over object data in the page cache. Therefore we fadvise() the system to drop the object data from the cache as soon as we're done reading object data off the drive. That keeps more space available in the storage nodes' memory for the filesystem metadata, which in turn help keep the cluster happy.<br>
<br>
The other option would be to cache the data on the proxy server. And sure, I guess we could do that, but it would end up meaning that we (the swift devs) would implement some kind of cache system, and at that point, why not use an existing one that's specialized for that purpose and does a great job (eg varnish/squid)?<br>
<br>
So that's why we don't cache object data in Swift. Great question!<br>
<br>
--John<br>
<div><div class="h5"><br>
<br>
<br>
> On Jun 25, 2015, at 1:05 PM, 杨苏立 Yang Su Li <<a href="mailto:yangsuli@gmail.com">yangsuli@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I have noticed that even though account/container information is cached using memcached in Swift, it doesn't cache any actual object data.<br>
><br>
> Could someone enlighten me what's the consideration behind this decision? Because it seems like it might be useful...<br>
><br>
> Thanks a lot<br>
><br>
> Suli<br>
><br>
> --<br>
> Suli Yang<br>
><br>
> Department of Physics<br>
> University of Wisconsin Madison<br>
><br>
> 4257 Chamberlin Hall<br>
> Madison WI 53703<br>
><br>
</div></div>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Suli Yang<br><br>Department of Physics<br>University of Wisconsin Madison<br><br>4257 Chamberlin Hall<br>Madison WI 53703<br><br></div>
</div>