All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
To: Jim Rees <rees@umich.edu>
Cc: Vivek Trivedi <vtrivedi018@gmail.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Namjae Jeon <linkinjeon@gmail.com>,
	"amit.sahrawat83@gmail.com" <amit.sahrawat83@gmail.com>
Subject: Re: NFS: low read/stat performance on small files
Date: Fri, 23 Mar 2012 12:16:40 +0000	[thread overview]
Message-ID: <1332505002.20500.14.camel@lade.trondhjem.org> (raw)
In-Reply-To: <20120323114913.GB24489@umich.edu>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1792 bytes --]

On Fri, 2012-03-23 at 07:49 -0400, Jim Rees wrote:
> Vivek Trivedi wrote:
> 
>   204800 bytes (200.0KB) copied, 0.027074 seconds, 7.2MB/s
>   Read speed for 200KB file is 7.2 MB
> 
>   104857600 bytes (100.0MB) copied, 9.351221 seconds, 10.7MB/s
>   Read speed for 100MB file is 10.7 MB
>   
>   As you see read speed for 200KB file is only 7.2MB/sec while it is
>   10.7 MB/sec when we read 100MB file.
>   Why there is so much difference in read performance ?
>   Is there any way to achieve high read speed for small files ?
> 
> That seems excellent to me.  204800 bytes at 11213252 per sec would be 18.2
> msec, so your per-file overhead is around 9 msec.  The disk latency alone
> would normally be more than that.

...and the reason why the performance is worse for the 200K file
compared to the 100M one is easily explained.

When opening the file for reading, the client has a number of
synchronous RPC calls to make: it needs to look up the file, check
access permissions and possibly revalidate its cache. All these tasks
have to be done in series (you cannot do them in parallel), and so the
latency of each task is limited by the round-trip time to the server.

On the other hand, once you get to doing READs, the client can send a
bunch of readahead requests in parallel, thus ensuring that the server
can use all the bandwidth available to the TCP connection.

So your result is basically showing that for small files, the proportion
of (readahead) tasks that can be done in parallel is smaller. This is as
expected.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

WARNING: multiple messages have this Message-ID (diff)
From: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
To: Jim Rees <rees@umich.edu>
Cc: Vivek Trivedi <vtrivedi018@gmail.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Namjae Jeon <linkinjeon@gmail.com>,
	"amit.sahrawat83@gmail.com" <amit.sahrawat83@gmail.com>
Subject: Re: NFS: low read/stat performance on small files
Date: Fri, 23 Mar 2012 12:16:40 +0000	[thread overview]
Message-ID: <1332505002.20500.14.camel@lade.trondhjem.org> (raw)
In-Reply-To: <20120323114913.GB24489@umich.edu>

T24gRnJpLCAyMDEyLTAzLTIzIGF0IDA3OjQ5IC0wNDAwLCBKaW0gUmVlcyB3cm90ZToNCj4gVml2
ZWsgVHJpdmVkaSB3cm90ZToNCj4gDQo+ICAgMjA0ODAwIGJ5dGVzICgyMDAuMEtCKSBjb3BpZWQs
IDAuMDI3MDc0IHNlY29uZHMsIDcuMk1CL3MNCj4gICBSZWFkIHNwZWVkIGZvciAyMDBLQiBmaWxl
IGlzIDcuMiBNQg0KPiANCj4gICAxMDQ4NTc2MDAgYnl0ZXMgKDEwMC4wTUIpIGNvcGllZCwgOS4z
NTEyMjEgc2Vjb25kcywgMTAuN01CL3MNCj4gICBSZWFkIHNwZWVkIGZvciAxMDBNQiBmaWxlIGlz
IDEwLjcgTUINCj4gICANCj4gICBBcyB5b3Ugc2VlIHJlYWQgc3BlZWQgZm9yIDIwMEtCIGZpbGUg
aXMgb25seSA3LjJNQi9zZWMgd2hpbGUgaXQgaXMNCj4gICAxMC43IE1CL3NlYyB3aGVuIHdlIHJl
YWQgMTAwTUIgZmlsZS4NCj4gICBXaHkgdGhlcmUgaXMgc28gbXVjaCBkaWZmZXJlbmNlIGluIHJl
YWQgcGVyZm9ybWFuY2UgPw0KPiAgIElzIHRoZXJlIGFueSB3YXkgdG8gYWNoaWV2ZSBoaWdoIHJl
YWQgc3BlZWQgZm9yIHNtYWxsIGZpbGVzID8NCj4gDQo+IFRoYXQgc2VlbXMgZXhjZWxsZW50IHRv
IG1lLiAgMjA0ODAwIGJ5dGVzIGF0IDExMjEzMjUyIHBlciBzZWMgd291bGQgYmUgMTguMg0KPiBt
c2VjLCBzbyB5b3VyIHBlci1maWxlIG92ZXJoZWFkIGlzIGFyb3VuZCA5IG1zZWMuICBUaGUgZGlz
ayBsYXRlbmN5IGFsb25lDQo+IHdvdWxkIG5vcm1hbGx5IGJlIG1vcmUgdGhhbiB0aGF0Lg0KDQou
Li5hbmQgdGhlIHJlYXNvbiB3aHkgdGhlIHBlcmZvcm1hbmNlIGlzIHdvcnNlIGZvciB0aGUgMjAw
SyBmaWxlDQpjb21wYXJlZCB0byB0aGUgMTAwTSBvbmUgaXMgZWFzaWx5IGV4cGxhaW5lZC4NCg0K
V2hlbiBvcGVuaW5nIHRoZSBmaWxlIGZvciByZWFkaW5nLCB0aGUgY2xpZW50IGhhcyBhIG51bWJl
ciBvZg0Kc3luY2hyb25vdXMgUlBDIGNhbGxzIHRvIG1ha2U6IGl0IG5lZWRzIHRvIGxvb2sgdXAg
dGhlIGZpbGUsIGNoZWNrDQphY2Nlc3MgcGVybWlzc2lvbnMgYW5kIHBvc3NpYmx5IHJldmFsaWRh
dGUgaXRzIGNhY2hlLiBBbGwgdGhlc2UgdGFza3MNCmhhdmUgdG8gYmUgZG9uZSBpbiBzZXJpZXMg
KHlvdSBjYW5ub3QgZG8gdGhlbSBpbiBwYXJhbGxlbCksIGFuZCBzbyB0aGUNCmxhdGVuY3kgb2Yg
ZWFjaCB0YXNrIGlzIGxpbWl0ZWQgYnkgdGhlIHJvdW5kLXRyaXAgdGltZSB0byB0aGUgc2VydmVy
Lg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgb25jZSB5b3UgZ2V0IHRvIGRvaW5nIFJFQURzLCB0aGUg
Y2xpZW50IGNhbiBzZW5kIGENCmJ1bmNoIG9mIHJlYWRhaGVhZCByZXF1ZXN0cyBpbiBwYXJhbGxl
bCwgdGh1cyBlbnN1cmluZyB0aGF0IHRoZSBzZXJ2ZXINCmNhbiB1c2UgYWxsIHRoZSBiYW5kd2lk
dGggYXZhaWxhYmxlIHRvIHRoZSBUQ1AgY29ubmVjdGlvbi4NCg0KU28geW91ciByZXN1bHQgaXMg
YmFzaWNhbGx5IHNob3dpbmcgdGhhdCBmb3Igc21hbGwgZmlsZXMsIHRoZSBwcm9wb3J0aW9uDQpv
ZiAocmVhZGFoZWFkKSB0YXNrcyB0aGF0IGNhbiBiZSBkb25lIGluIHBhcmFsbGVsIGlzIHNtYWxs
ZXIuIFRoaXMgaXMgYXMNCmV4cGVjdGVkLg0KDQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXgg
TkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFwcA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5j
b20NCnd3dy5uZXRhcHAuY29tDQoNCg==

  reply	other threads:[~2012-03-23 12:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-23 11:17 NFS: low read/stat performance on small files Vivek Trivedi
2012-03-23 11:49 ` Jim Rees
2012-03-23 12:16   ` Myklebust, Trond [this message]
2012-03-23 12:16     ` Myklebust, Trond
2012-03-24  7:02     ` Namjae Jeon
2012-03-29 15:52     ` Kevin Graham
2012-03-29 16:16       ` Myklebust, Trond

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1332505002.20500.14.camel@lade.trondhjem.org \
    --to=trond.myklebust@netapp.com \
    --cc=amit.sahrawat83@gmail.com \
    --cc=linkinjeon@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rees@umich.edu \
    --cc=vtrivedi018@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.