Thanks for explaining it. I read the source code and confirmed that read operations incur more drop_cache calls than write operations. However, I am not sure whether the additional calls result in significant overhead. Need some tests to verify.
Gerald On Tue, Dec 13, 2011 at 11:32 PM, Michael Barton <mike-launch...@weirdlooking.com> wrote: > I can't explain it off the top of my head. > > I don't have a swift installation to play with at the moment, but it's > conceivable that posix_fadvise is slower than we expect (drop_cache is > called more frequently during reads than writes, iirc). That could be > tested by making drop_cache a no-op in the object server. > > Or running the object server under a profiler during both operations > might shed some light on what is taking so much time. > > --Mike > > > > On Mon, Dec 12, 2011 at 8:44 AM, Zhenhua (Gerald) Guo <jen...@gmail.com> > wrote: >> Hi, folks >> Recently, I have run some read/write tests for large files (400GB) >> in Swift. I found that writes were always faster than reads, which is >> kinda counter-intuitive. What may be the cause? >> Has anyone else seen the same problem? >> >> Gerald >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp