Всем привет!
Столкнулся с такой проблемой: тестировали приложение на выделенной машине (ос windows xp) — всё хорошо, работает быстро. Установили на сервер заказчика — работает значительно медленнее (в 2-3 раза). Веб-контейнер — Tomcat 5.5, jdk 1.6 update 10 (под windows jdk более старой версии, но врятли из-за этого может быть такая разница в производительности). Приложение БД не использует. Логгирование показывает что тормозит абсолютно все операции (т.е. каждая операция выполняется в 2-3 раза медленее, а не на каких-то отдельных).
Даже не знаю в какую сторону двигаться, очень нужна помощь.

Здравствуйте, Аноним, Вы писали:

А>Всем привет!
А>Столкнулся с такой проблемой: тестировали приложение на выделенной машине (ос windows xp) — всё хорошо, работает быстро. Установили на сервер заказчика — работает значительно медленнее (в 2-3 раза). Веб-контейнер — Tomcat 5.5, jdk 1.6 update 10 (под windows jdk более старой версии, но врятли из-за этого может быть такая разница в производительности). Приложение БД не использует. Логгирование показывает что тормозит абсолютно все операции (т.е. каждая операция выполняется в 2-3 раза медленее, а не на каких-то отдельных).
А>Даже не знаю в какую сторону двигаться, очень нужна помощь.

Конфигурации сопоставимые? Может там сервер слабый?

Здравствуйте, Аноним, Вы писали:

А>Столкнулся с такой проблемой: тестировали приложение на выделенной машине (ос windows xp) — всё хорошо, работает быстро. Установили на сервер заказчика — работает значительно медленнее (в 2-3 раза). Веб-контейнер — Tomcat 5.5, jdk 1.6 update 10 (под windows jdk более старой версии, но врятли из-за этого может быть такая разница в производительности). Приложение БД не использует. Логгирование показывает что тормозит абсолютно все операции (т.е. каждая операция выполняется в 2-3 раза медленее, а не на каких-то отдельных).

Ещё раз что за конфигурация у заказчика. Поствте на винду update 10 тоже. Кстати он разве уже не бетта?

Здравствуйте, Blazkowicz, Вы писали:

B>Ещё раз что за конфигурация у заказчика. Поствте на винду update 10 тоже. Кстати он разве уже не бетта?
Он уже RC

Здравствуйте, KRA, Вы писали:

KRA>Здравствуйте, Аноним, Вы писали:

KRA>Конфигурации сопоставимые? Может там сервер слабый?

На винде Core 2 Duo 1.8 GHz 1 Gb RAM, у заказчика Xeon 1.6 GHz 2 процессора по 2 ядра 4 Gb RAM. Конфигурации сопоставимые для обработки единичных запросов, сейчас речь как раз о таком сценарии тестирования идет.

Здравствуйте, Аноним, Вы писали:

А>На винде Core 2 Duo 1.8 GHz 1 Gb RAM, у заказчика Xeon 1.6 GHz 2 процессора по 2 ядра 4 Gb RAM. Конфигурации сопоставимые для обработки единичных запросов, сейчас речь как раз о таком сценарии тестирования идет.
Как на счет конфигурации деплоймента? Памяти нормально выделено для JVM?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>На винде Core 2 Duo 1.8 GHz 1 Gb RAM, у заказчика Xeon 1.6 GHz 2 процессора по 2 ядра 4 Gb RAM. Конфигурации сопоставимые для обработки единичных запросов, сейчас речь как раз о таком сценарии тестирования идет.
B>Как на счет конфигурации деплоймента? Памяти нормально выделено для JVM?
Речь про опции Xmx? На винде 512 Мб, под линуксом 1024. Xms одинаковое.

Здравствуйте, Аноним, Вы писали:

А>Речь про опции Xmx? На винде 512 Мб, под линуксом 1024. Xms одинаковое.

А если логирование вырубить? Может там файловый IO медленный?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>Речь про опции Xmx? На винде 512 Мб, под линуксом 1024. Xms одинаковое.

B>А если логирование вырубить? Может там файловый IO медленный?

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

Здравствуйте, Аноним, Вы писали:

А>Всем привет!
А>Столкнулся с такой проблемой: тестировали приложение на выделенной машине (ос windows xp) — всё хорошо, работает быстро. Установили на сервер заказчика — работает значительно медленнее (в 2-3 раза). Веб-контейнер — Tomcat 5.5, jdk 1.6 update 10 (под windows jdk более старой версии, но врятли из-за этого может быть такая разница в производительности). Приложение БД не использует. Логгирование показывает что тормозит абсолютно все операции (т.е. каждая операция выполняется в 2-3 раза медленее, а не на каких-то отдельных).
А>Даже не знаю в какую сторону двигаться, очень нужна помощь.

Я бы советовал профайлить и тестировать.
Важный вопрос — проблемы с производительностью на уровне вашего приложения? Или JVM? Или операционной системы? Выясните, после этого станет понятнее что делать. Профайлер и собственные мини-тесты в этом помогут.

Например, осли проблемы окажутся на уровне ОС, то во многих ситуация решение ложится на заказчика. "У вас проблема с сервером, и вот почему мы так считаем:...". Или вы брали на себя обязательство настраивать и поддерживать его серверы? Кстати, в такой ситуации можете это предложить за отдельные средства. Если вам это нужно.

Если на уровне приложения (выглядит маловероятным) — чините.

Если JVM (также выглядит маловероятным) — действуйте по обстановке, т.е. исходя из природы тормозящих операций. Вариантов немного, в основном конфигурация параметров JVM.
При этом важно помнить, вы не отвечаете за проблемы java под определённой ОС. Вы можете поиграться конечно с разными версиями jdk, но если это не помогает — советуйте заказчику обратиться в службу поддержки Sun. Предоставьте входную информацию для этого.

Здравствуйте, pagrus, Вы писали:

P>Здравствуйте, Аноним, Вы писали:

P>Я бы советовал профайлить и тестировать.
P>Важный вопрос — проблемы с производительностью на уровне вашего приложения? Или JVM? Или операционной системы? Выясните, после этого станет понятнее что делать. Профайлер и собственные мини-тесты в этом помогут.

P>Например, осли проблемы окажутся на уровне ОС, то во многих ситуация решение ложится на заказчика. "У вас проблема с сервером, и вот почему мы так считаем:...". Или вы брали на себя обязательство настраивать и поддерживать его серверы? Кстати, в такой ситуации можете это предложить за отдельные средства. Если вам это нужно.

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

Здравствуйте, <Аноним>, Вы писали:

А>Даже не знаю в какую сторону двигаться, очень нужна помощь.

Что понимается под словом "операции"? Обработка каждого http запроса? Первое что приходит в голову — криво настроеный DNS на сервере (и, как результат, тормоза из-за back resolver-а).

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, pagrus, Вы писали:

P>>Здравствуйте, Аноним, Вы писали:

P>>Я бы советовал профайлить и тестировать.
P>>Важный вопрос — проблемы с производительностью на уровне вашего приложения? Или JVM? Или операционной системы? Выясните, после этого станет понятнее что делать. Профайлер и собственные мини-тесты в этом помогут.

P>>Например, осли проблемы окажутся на уровне ОС, то во многих ситуация решение ложится на заказчика. "У вас проблема с сервером, и вот почему мы так считаем:...". Или вы брали на себя обязательство настраивать и поддерживать его серверы? Кстати, в такой ситуации можете это предложить за отдельные средства. Если вам это нужно.

А>Спасибо большое, но подскажите, пожалуйста, как это можно обосновать? Я пока даже не представляю как профайлинг или тесты могут показать, что проблема именно в сервере.

Ну например.

Используя профайлер вы находите, какие именно вызовы съёдают большую часть времени. Т.е. найдите сервлетный service() метод, посмотрите дерево вызовов под ним, что сколько времени заняло. Спускайтесь по дереву вызовов до классов JDK. Сравните это с результатом профайлинга на WinXP. Очень вероятно что тут же найдёте узкое место и поймёте, в приложении ли оно.
Если проблема не видна — посмотрите выше service(), возможно проблема в самом tomcat.

Также пишите мини-тесты на java. Ваше приложение делает много ввода-вывода? Напишите тест на копирование файлов. Убедитесь, что разницу в производительности он отражает, иначе приближаете содержимое теста к реальному приложению.
Таким же образом можно проверять вычислительную часть, взаимодействие по сети, обработку тестовых jsp и т.д. Просто разрабатываете маленькую программу, примитивно симулирующую тот или иной аспект приложения, смотрите насколько отличается производительность. Опять же, профайлер укажет правильное направление для этого.

На выходе вы имеете тест(ы), наглядно показывающий разницу в производительности у вас и у них. Это и есть тот самый аргумент.


Кстати посоветуйте клиенту убедиться, что сервер имеет достаточно свободной физической памяти и не свопится.
Ещё можно включить трассировку GC, проверить на предмет аномалий. Я таким не занимался, но в гугле можно найти.
Также они могут попробовать включить/выключить APR для tomcat и последить за результатами.

Ну и снова нетехнический аспект — если проблема на их стороне, а вы тратите много времени, можете говорить о дополнительной его оплате.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, <Аноним>, Вы писали:

А>>Даже не знаю в какую сторону двигаться, очень нужна помощь.

ANS>Что понимается под словом "операции"? Обработка каждого http запроса? Первое что приходит в голову — криво настроеный DNS на сервере (и, как результат, тормоза из-за back resolver-а).

Нет, под этим понимается вызов единицы логики (например, запрос данных из кеша, разбор строки, и т.п., или просто вызов какого-то сомнительного метода).

Время обработки запроса считаю так — сохраняю время в начале метода service сервлета (через System.nanoTime()) и в конце, и вывожу в браузер разницу. Вот это время и отличается в разы между разными ОС. Время выполнения операций считаю так же — и вывожу в лог время и название операции (например, вызов метода xxx с параметрами yyy занято zzz микросекунд).

Здравствуйте, <Аноним>, Вы писали:

кстати, с 6-й java в поставке уже идёт visualvm. Возьми и посмотри, что он показывает. По крайней мере посмотришь на потребление памяти, работу сборщика мусора.

Здравствуйте, Аноним, Вы писали:

А>Всем привет!
А>Столкнулся с такой проблемой: тестировали приложение на выделенной машине (ос windows xp) — всё хорошо, работает быстро. Установили на сервер заказчика — работает значительно медленнее (в 2-3 раза). Веб-контейнер — Tomcat 5.5, jdk 1.6 update 10 (под windows jdk более старой версии, но врятли из-за этого может быть такая разница в производительности). Приложение БД не использует. Логгирование показывает что тормозит абсолютно все операции (т.е. каждая операция выполняется в 2-3 раза медленее, а не на каких-то отдельных).
А>Даже не знаю в какую сторону двигаться, очень нужна помощь.

Мож update 10 сырой еще? Поставьте 1.6.0_07 или 1.6.0_05, сравните

Здравствуйте, pagrus, Вы писали:

P>Ну например.

P>Используя профайлер вы находите, какие именно вызовы съёдают большую часть времени. Т.е. найдите сервлетный service() метод, посмотрите дерево вызовов под ним, что сколько времени заняло. Спускайтесь по дереву вызовов до классов JDK. Сравните это с результатом профайлинга на WinXP. Очень вероятно что тут же найдёте узкое место и поймёте, в приложении ли оно.
P>Если проблема не видна — посмотрите выше service(), возможно проблема в самом tomcat.
Профайлером конечно не смотрел, но логгирование показывает что замедление на разных вызовах пропорциональное, как будто тактовая частота процессора меньше в 3 раза.

P>Кстати посоветуйте клиенту убедиться, что сервер имеет достаточно свободной физической памяти и не свопится.
Физической памяти полно свободной. Вот что показывает top для процесса томката:

CPU0 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
CPU1 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
CPU2 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
CPU3 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 2578660K total, 1693768K used, 884892K free, 205176K buffers
Swap: 5156824K total, 0K used, 5156824K free, 1210516K cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20982 user 25 0 1227M 156M 7536 S 0.0 6.2 0:12.43 java

P>Также они могут попробовать включить/выключить APR для tomcat и последить за результатами.
Включал. Существенной разницы не заметил.

Здравствуйте, Аноним, Вы писали:

А>Профайлером конечно не смотрел, но логгирование показывает что замедление на разных вызовах пропорциональное, как будто тактовая частота процессора меньше в 3 раза.

Не может ли причиной быть частое переключение контекстов для процессоров. Попробуйте назначит Java только на один процессор или даже ядро.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, pagrus, Вы писали:

P>>Ну например.

А>Профайлером конечно не смотрел, но логгирование показывает что замедление на разных вызовах пропорциональное, как будто тактовая частота процессора меньше в 3 раза.
А вызовы к БД тоже в 3 раза медленней? Работа с файловой системой напрямую (если есть) так же тормозит?

Для проверки проца напишите простое приложение на С.
Для БД простенькое приложение на С, которое будет делать один запрос в БД и сравните производительность. От этого можно оттолкнуться.

P>>Кстати посоветуйте клиенту убедиться, что сервер имеет достаточно свободной физической памяти и не свопится.
А>Физической памяти полно свободной. Вот что показывает top для процесса томката:
А>

CPU0 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
А>CPU1 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
А>CPU2 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
А>CPU3 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
А>Mem: 2578660K total, 1693768K used, 884892K free, 205176K buffers
А>Swap: 5156824K total, 0K used, 5156824K free, 1210516K cached

А> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
А>20982 user 25 0 1227M 156M 7536 S 0.0 6.2 0:12.43 java

может у пользователя под которым запускаете квота стоит?

P>>Также они могут попробовать включить/выключить APR для tomcat и последить за результатами.
А>Включал. Существенной разницы не заметил.

Здравствуйте, KRA, Вы писали:

KRA>А вызовы к БД тоже в 3 раза медленней? Работа с файловой системой напрямую (если есть) так же тормозит?
Работы с БД, ФС отсутствует.

KRA>Для проверки проца напишите простое приложение на С.
KRA>Для БД простенькое приложение на С, которое будет делать один запрос в БД и сравните производительность. От этого можно оттолкнуться.

KRA>может у пользователя под которым запускаете квота стоит?
Попробывал под рутом — всё тоже самое.