Производительность Tomcat тюнинг

я настраиваю производительность Tomcat 7, сервер оснащен 24 ядрами и 32 ГБ памяти, мой интерфейс тестирования-это RESTful сервис без какого-либо процесса(ответ сразу) и конфигурации сервера.XML имеет следующие...

<Connector port="8088" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           enableLookups="false"
           compression="off"
           maxConnections="8192"
           maxThreads="1000"
           tcpNoDelay="true"/>

и конфигурация JVM...

-Xms8192M -Xmx16384M.

хозяин JMeter другой компьютер имеет такую же спецификацию с вышеуказанным сервером. И конфигурация кучи JMeter -Xms12218m -Xmx24426m.

мой план испытаний JMeter 240 запросов отправляются в интерфейс RESTful одновременно один раз, но я заметил, что среднее время ответа для первых 100 составляет не более 50 мс, но оно увеличивается до 1 сек в следующем 100 и до 3 сек для остальных.

мне любопытно такое явление, есть ли какие-либо ошибки в конфигурациях или какие-либо предложения?

спасибо заранее.

7
jmeter performance tomcat

2 ответов

Вы можете конфиг:

acceptCount="2048"

и

maxConnections="1024"

maxConnections имеет отношение к maxThreads, и вы должны настроить maxThreads соответствуют вашему бизнесу и номеру ядра процессора, например 8X или 16X. acceptCount-это номер ожидающего соединения.

обратите внимание, что maxConnections и maxThreads не больше, тем лучше, с производительностью вашего серверного оборудования.

7

тем больше запросов на ваш сервер обслуживать, тем больше времени требуется для обслуживания каждого запроса. Это нормальное поведение.

Как вы начинаете свои потоки одновременно? Время рампы = 0 или 1?

при запуске загрузки потоков клиенту требуется больше времени для выполнения запросов,а серверу-для ответа.

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

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

0