В настоящее время у меня есть веб-приложение, построенное на Java 8 для Tomcat 9. Это приложение использует Websockets через javax.websockets + ServerEndpoint и связано с клиентом Javascript.
Когда я стресс-тестирую этот сервер, если число открытых веб-сокетов достигнет 2000 - сервер прекратит обработку запросов до тех пор, пока не закроются некоторые подключения веб-сокетов, и не уменьшит счет до 2000. Сервер не обращается к памяти , дескриптор файла или процессор ограничивает и в основном не имеет ничего в своей очереди на момент остановки, поскольку он обрабатывает реальные транзакции довольно быстро. Что касается моего веб-приложения, оно даже не получает запросы, пока соединения установлены на 2000.
Сервер использует собственный APR для своего HTTP-коннектора и более менее по умолчанию. Я попытался настроить maxConnections и maxThreads, но они, кажется, не влияют на это. Сервер является одним экземпляром EC2 в AWS.
В документации Tomcat я не вижу ничего, кроме этих двух аргументов, которые могли бы контролировать максимальные сокеты. Это запись для нашего разъема
<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol"
maxThreads="1000" scheme="https" SSLEnabled="true"
SSLCertificateFile="conf/cert.crt"
SSLCertificateKeyFile="conf/nopasskey.pem"
SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"
/>
Я что-то здесь упускаю? Есть ли другие опции, которые контролируют максимально допустимые веб-сокеты?
Примечание: я просто хочу уточнить, когда этот предел будет достигнут, пользователи все равно смогут подключаться к серверу. Однако их соединение, похоже, помещено в какую-то очередь ожидания для обработки, а не просто передается веб-приложению при 2000 соединениях. Это позволяет пользователям по-прежнему подключаться, но они не получат ответ, пока их подключение не будет передано веб-приложению.