JRun
JRun

Reputation: 3428

Tuning Tomcat memory consumption, sockets: socket.rxBufSize

I have a Tomcat7 app serving tens of thousands of concurrent connections, using 'long-polling'. long-polling (in short) means that I hold on to the request for a long time, before sending back the client a response (either new data, or 304 code).

I'm trying to minimize the amount of memory consumed by these connections. Obvious low hanging fruit were the stack size, and app buffer sizes (see my Catalina connector config below). However, it's not enough.

I saw the 'socket.rxBufSize' and 'txBufSize', and that their default values are fairly big. The documentation for those are:

(int)The socket receive buffer (SO_RCVBUF) size in bytes. Default value is 25188

  1. Socket buffer - I'm guessing OS socket buffer, is that correct?
  2. In the grand scheme of things, where do these buffers stand? what's their significance?
  3. Where do I control the max number of sockets for Tomcat? is it a function of maxThreads? one-to-one?
  4. If I would go and decrease their values, what values would make sense? what would happen with a buffer that's too small?

    connectionTimeout="3000" keepAliveTimeout="13000" acceptorThreadCount="4" enableLookups="false" maxConnections="100000" minSpareThreads="250" acceptCount="10000" compression="on" compressionMinSize="256" maxKeepAliveRequests="-1" socket.appReadBufSize="128" socket.appWriteBufSize="1024" maxThreads="500"

Thank you!

Upvotes: 2

Views: 3379

Answers (1)

Kayaman
Kayaman

Reputation: 73568

  1. Yes, the buffers for the native sockets underneth.
  2. Memorywise not much, since you can only have so many sockets to begin with.
  3. Don't know, check the documentation.
  4. If the receiving buffer is small, then the sending end would send less data to avoid choking the receiver. If the receiver is quick in processing any data it gets, it can have a large buffer, if the receiver is slower, the receive buffer can be smaller since the actual throughput will be lower (the receive window will be adjusted automatically anyways, so the sender won't flood the receiver).

I don't know if you'll get any significant improvements from fiddling with those values, but you could always try.

Upvotes: 1

Related Questions