Optimizing Jetty for heartbeat detection of thousands of machines?

Question

I have a large number of machines (thousands and more) that every X seconds would perform an HTTP request to a Jetty server to notify they are alive. For what value of X should I use persistent HTTP connections (which limits number of monitored machines to number of concurrent connections), and for what value of X the client should re-establish a TCP connection (which in theory would allow to monitor more machines with the same Jetty server).

How would the answer change for HTTPS connections? (Assuming CPU is not a constraint)

This question ignores scaling-out with multiple Jetty web servers on purpose.

Update: Basically the question can be reduced to the smallest recommended value of lowResourcesMaxIdleTime.

jesse mcconnell jesse mcconnell · Accepted Answer · 2012-12-21T10:52:32

I would say that this is less of a jetty scaling issue and more of a network scaling issue, in which case 'it depends' on your network infrastructure. Only you really know how your network is laid out and what sort of latencies are involved in order to come up with a value of X.

From an overhead perspective the persistent HTTP connections will of course have some minor effect (well I say minor but depends on your network) and the HTTPS will again have a larger impact....but only from a volume of traffic perspective since you are assuming CPU is not a constraint.

So from a jetty perspective, it really doesn't need to be involved in the question, you seem to ultimately be asking for help optimizing bytes of traffic on the wire so really you are looking for the best protocol at this point. Since with HTTP you are having to mess with headers for each request you may be well served looking at something like spdy or websocket which will give you persistent connections but are optimized for low round trip network overhead. But...they seem sort of overkill for a heartbeat. :)

Optimizing Jetty for heartbeat detection of thousands of machines?

2 Answers