Increase the sizes of the circular buffers used by SSLClientSocketNSS.

net/socket/ssl_client_socket_nss.cc

Index: net/socket/ssl_client_socket_nss.cc
===================================================================
--- net/socket/ssl_client_socket_nss.cc	(revision 155503)
+++ net/socket/ssl_client_socket_nss.cc	(working copy)
@@ -118,7 +118,12 @@
 #include <dlfcn.h>
 #endif
 
-static const int kRecvBufferSize = 4096;
+// Common Read output buffer sizes are 4KB and 8KB. Use a receive input buffer

[wtc, 2012/09/07 23:18:54]

I saw the 4KB and 8KB Read() input buffer sizes while debugging,
but could not track them down.

[Ryan Sleevi, 2012/09/08 01:14:57]

Considering this represents a network buffer, it seems more useful to ensure
that this is enough to handle a complete SSL packet.

Even if the client is only reading 4K at a time, if a server sent a full packet,
we'll need to read the full packet in before we can answer that 4K request.

NSS internally has a buffer sufficiently sized for the packet, but it means that
at 8KB, we're looking at two network reads to satisfy a 4KB client read.

Come to think of it, this would be a great place to add metrics. Filed
http://crbug.com/147401

+// size large enough to hold 8KB + SSL overhead.
+static const int kRecvBufferSize = 9 * 1024;
+// The largest Write input buffer size is 16KB. Use a send output buffer size
+// largest enough to hold 16KB + SSL overhead (often 25 bytes).

[wtc, 2012/09/10 22:51:37]

Your comment caused me to realize that NSS sends one record at
a time in general:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3...

That's a more important reason for kSendBufferSize to be
17KB, independent of the amount of data that the Chrome
network stack writes to NSS at a time. So I removed this
comment.

[wtc, 2012/09/10 22:56:25]

To expand on my previous comment: if the network stack writes
more than 16KB to NSS, it doesn't seem necessary to make
kSendBufferSize larger than 17KB. On the other hand, if the
network stack writes less than 16KB at a time to NSS, then we
can reduce kSendBufferSize.

But I would not be surprised if I still missed something :-)

[Ryan Sleevi, 2012/09/10 23:20:31]

Right, I followed what you meant.

NSS's strategy is much like OpenSSL, in that it follows a growth strategy
(specifically, sslBuffer_Grow), so that buffers only grow up to the size
necessary to send or receive the current message, up to the maximum size.

This implementation is pessimistic, in that it immediately allocates the
(expected) maximum size. However, absent hard data about the right sizes, I
think this is correct for performance, and we can tune it down/later to adjust
for memory usage.

+static const int kSendBufferSize = 17 * 1024;
 
 #if defined(OS_WIN)
 // CERT_OCSP_RESPONSE_PROP_ID is only implemented on Vista+, but it can be
@@ -3067,8 +3072,7 @@
 
 int SSLClientSocketNSS::InitializeSSLOptions() {
   // Transport connected, now hook it up to nss
-  // TODO(port): specify rx and tx buffer sizes separately
-  nss_fd_ = memio_CreateIOLayer(kRecvBufferSize);
+  nss_fd_ = memio_CreateIOLayer(kRecvBufferSize, kSendBufferSize);
   if (nss_fd_ == NULL) {
     return ERR_OUT_OF_MEMORY;  // TODO(port): map NSPR error code.
   }