Spring Boot 1.2.7, Tomcat, CSS и Thymeleaf = Очень Очень медленный сервис

У меня есть веб-приложение Spring Boot 1.2.7.RELEASE (со встроенным Tomcat), которое должно обрабатывать очень высокий скачок нагрузки, ~ 10 тыс. Соединений за 4-5 минут на одном сервере (на самом деле это кластер серверов, но это загрузить один узел увидим).

Это действительно очень медленно. Если я ударил его с помощью JMeter с 1000 потоков за 10 секунд, а просто с помощью простого запроса GET для страницы входа в Thymeleaf - ничего больше - средний ответ вскоре превысит 13 секунд. Страница - это просто форма входа в систему, использующая Thymeleaf.

Он работает на ВМ с RHEL7, 32 ГБ ОЗУ (с кучей JVM, настроенной на использование 28 ГБ) и 4 ядрами ЦП. Здесь много лошадиных сил, но я изо всех сил пытаюсь заставить его реагировать под нагрузкой.

В качестве теста, чтобы уменьшить количество сокетов и потоков, я закомментировал две ссылки на странице на css:

<HEAD>

    <!-- Other meta stuff omitted -->


    <!-- I commented out these next two lines -->
    <link rel="stylesheet" href="css/index.css"/>
    <link href="css/gridset.css" rel="stylesheet"/>
</HEAD>

Когда я сделал это точно такой же нагрузочный тест, он дал средний ответ 277 мс! Если я положу обратно, медлительность возвращается.

Таким образом, без преувеличения, ответ на тот же тест изменился с 13 до менее 0,3 секунды.

Я попытался включить css, но Spring выдает всевозможные ошибки, пытаясь разобрать его. W3C Validator показывает, что оба файла содержат много ошибок.

Кто-то работает над исправлением ошибок в css, но мне интересно, в чем причина медлительности. Это тот факт, что css сломан или это тот факт, что Tomcat обслуживает его из статической области? У меня не будет действительного CSS для повторного тестирования в течение нескольких дней, и я нахожусь под прицелом, чтобы сделать эту работу.

Я ударил его Firebug, и одна страница входа загружается в 437ms. Первый файл index.css загружается за 158 мс, а файл gridset.css - за 53 мс. Затем есть 3 изображения, которые занимают в общей сложности 205 мс. Общий размер изображений составляет 19 КБ.

Я выложу дамп темы ниже. Это было сгенерировано New Relic.

Я нашел некоторую информацию о том, что Tomcat медленно обслуживает статический контент, но я не могу себе представить, что он такой медленный, и другие люди говорят, что последняя версия Tomcat работает так же, как httpd.

Я в первую очередь разработчик, поэтому любая помощь в исправлении этого очень ценится, спасибо!

75% java.lang.Thread.run() :745 70% org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run() :61
 70% java.util.concurrent.ThreadPoolExecutor$Worker.run() :617
 70% java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor.Worker) :1127,1142
 69% java.util.concurrent.ThreadPoolExecutor.getTask() :1066
 69% org.apache.tomcat.util.threads.TaskQueue.poll(long, java.util.concurrent.TimeUnit) :31
 69% org.apache.tomcat.util.threads.TaskQueue.poll(long, java.util.concurrent.TimeUnit) :85
 69% java.util.concurrent.LinkedBlockingQueue.poll(long, java.util.concurrent.TimeUnit) :462,474,467
 69% java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long) :2069,2083,2078
 69% java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) :215
 69% sun.misc.Unsafe.park(boolean, long) :native

0 ответов

Другие вопросы по тегам