Оптимизируете Jetty для обнаружения сердцебиения тысяч машин?

Я бы сказал, что это не столько проблема масштабирования причала, сколько проблема масштабирования сети, и в этом случае «это зависит» от вашей сетевой инфраструктуры. Только вы действительно знаете, как устроена ваша сеть и какие задержки задействованы, чтобы получить значение X.

С точки зрения накладных расходов постоянные HTTP-соединения, конечно, будут иметь незначительный эффект (ну, я говорю незначительный, но зависит от вашей сети), а HTTPS снова будет иметь большее влияние... но только с точки зрения объема трафика, поскольку вы предполагая, что ЦП не является ограничением.

Таким образом, с точки зрения причала, на самом деле не нужно участвовать в этом вопросе, вы, похоже, в конечном итоге просите помощи в оптимизации байтов трафика в сети, поэтому на самом деле вы ищете лучший протокол на данный момент. Поскольку с HTTP вам приходится возиться с заголовками для каждого запроса, вы можете хорошо обслуживаться, глядя на что-то вроде spdy или websocket, которые дадут вам постоянные соединения, но оптимизированы для низких сетевых накладных расходов в оба конца. Но... они кажутся излишними для удара сердца. :)

Как насчет того, чтобы просто сделать запрос в разное время? Предположим, что первый запрос машины, затем вы выбираете время для ответа на эту машину, как в следующий раз, когда будет сердцебиение этой машины (также сохраните идентификатор/время на сервере причала), второй запрос машины, вы можете выбрать другое время для ответа на вторая машина.

Таким образом, вы можете заставить каждую машину выполнять запрос сердцебиения в разное время, чтобы не возникало одновременных проблем.

Вы также можете использовать случайное время для первого удара сердца, если все машины могут запускаться одновременно.