Когда система тормозит...

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

Итак, разрабатываемая вами система тормозит. Если об этом говорит ваш заказчик, то, как правило, речь идет не о том, что все тормозит целиком и "работать совсем невозможно" (хотя бывают и такие случаи), а о том, что медленно выполняется какое-то конкретное действие. Например, долго запускается процесс, медленно открывается страница с содержимым папки, медленно открывается форма какого-либо действия и т.д. Вот такая формулировка проблемы и будет нашей отправной точкой. Исходя из этого, мы должны установить конкретную причину снижения производительности и устранить ее. В теории все просто, на практике же несколько сложнее и интереснее.


Во-первых, стоит разобраться, где могут скрываться узкие места бизнес-системы. Прежде всего это конечно же база данных. Очень редко когда приложение реализует сложную бизнес-логику. Обычно львиная доля операций заключается во взаимодействии с базой данных. Здесь есть несколько аспектов:

1. Работа сервера СУБД. Понятно, что если воткнуть Oracle на PIII с 256МБ ОЗУ, то ни о какой нормальной работе и речи быть не может. По-хорошему, необходимо очертить круг поддерживаемых приложением СУБД и иметь четкие системные требования и рекомендации по настройке каждой из них. Впрочем, если заказчик говорит, что у него конкретная проблема, а в целом приложение работает нормально, то данный вариант можно считать экзотическим.

2. Подключение к СУБД. Если приложением активно пользуются и/или оно запускает много фоновых потоков, в которых используется база данных, то необходимо обеспечить пул соединений с СУБД. Само по себе установление соединения - операция довольно затратная, гораздо эффективнее при старте приложения создать несколько таких подключений и выдавать их системе по необходимости.

3. Индексы, индексы, индексы... Наиболее вероятная причина возникновения проблем. Во-первых можно банально забыть при разработке создать индекс по какому-либо полю. Например, сначала по данному полю никаких условий не накладывалось, затем условия появились, а индекс создать забыли. Во-вторых, можно не забыть создать индекс, написать соответствующую миграцию, но по какой-то причине ее не выполнить. В-третьих, при изменении структуры БД не следует полагаться на Hibenate - в режиме update Hibernate не создает индексы! Ну и в конце-концов отсутствие индексов именно на базе данных конкретного заказчика может быть следствием неосторожного поведения его/наших администраторов.

4. Тяжелые либо лишние SQL-запросы. При разработке бизнес-систем довольно часто используют OR/M-фреймворки, в частности - Hibernate. При этом данные фреймворки могут генерировать сложный SQL-код, состоящий из большого количества нетривиальных запросов. Такое поведение может быть вызвано неправильно составленным мэпингом и неверно выбранной стратегией наследования. Типичной ошибкой является отказ от ленивой стратегии загрузки объектов, вызванный неумением решать возникающие с lazy-loading проблемы. Я лично видел, как удаление из мэпинга lazy="false" ускоряло работу системы в 30 раз. Стоит помнить, что по-умолчанию для загрузки из базы данных каждого сложного поля Hibernate будет генерировать отдельный запрос на каждую сущность. Если у вас 1000 сущностей - вы получите 1000 дополнительных запросов. При этом, если используется глубокая иерархия наследования - запросы будут очень тяжелыми, включать в себя много операций соединения (JOIN). Что самое противное - сложный SQL-код может скрываться за довольно безобидным HQL-запросом.

Следующей группой узких мест является взаимодействие с внешними бизнес-системами, в частности осуществляемое посредством веб-сервисов. Здесь могут быть такие варианты:

1. Недоступность внешней системы. Внешняя бизнес-система недоступна и поэтому разрабатываемое приложение периодически пытается к ней достучаться. Самый плохой вариант когда выставлен большой таймаут или такой таймаут вообще не предусмотрен. Тогда вместо того, чтобы после какого-то небольшого времени или фиксированного числа попыток прекратить насиловать труп, мы получим зависание системы.

2. Чехарда с подключениями. Само подключение к внешней системе может быть ресурсоемкой операцией, особенно если внешняя система сильно удалена. Необходимо стремиться к кэшированию подключений или создать пул таких соединений. Проблема обычно заключается в том, что если пул соединений с СУБД может создать, например, Hibernate, то пул соединений с каким-либо веб-сервисом придется реализовывать руками.

3. Низкая производительность внешней системы. Нет-нет, система доступна, но работает очень медленно + канал связи плохой. Если мы никак не можем исправить данную ситуацию и/или внешня система вообще не наша, то необходимо реализовать синхронизацию. Суть синхронизации в следующем: мы создаем локальное хранилище (возможно в терминах именно нашей предметной области) в которое помещаем объекты из внешней системы. При старте приложения, совершении действий или периодически мы синхронизируем состояние нашего хранилища с информацией, полученной от такой системы. Конечно, данный подход не всегда реализуем, но часто позволяет повысить производительность разрабатываемого ПО.

Итак, после ознакомления с проблемой нужно разобраться какое из вышеописанных узких мест присутствует на сервере заказчика. Если нет каких-либо индексов, или имеющаяся у заказчика СУБД ограничивает количество единовременных подключеий или с сервера заказчика не пингуется внешняя система, то здесь становиться все ясно и необходимо устранять обнаруженную проблему. Помимо технических аспектов есть и организационные: в идеале любое обращение заказчика за техподдержкой должно закончиться тем, что ни этот ни другие заказчики с той же самой проблемой обращаться больше не будут. Нужно написать или подкорректировать имеющиеся инструкции по воссозданию пропавших индексов; проверке связи с внешней системой и что делать в случае, если связи нет; настройке СУБД и т.д.

Гораздо хуже, когда неполадка в самой системе, т.е. исследование внешних факторов проблем не выявило. Первое, что необходимо сделать - воспроизвести тормоза у себя. Для этого может понадобиться получить дамп базы данных заказчика, если есть такая возможность. В случае, когда дамп недоступен - нужно иметь возможность создать у себя количество нужных бизнес-объектов, соизмеримое с количеством этих объектов у заказчика. Naumen DMS, например, позволяет через специальную консоль запускать скрипты, использующие ее код, что позволяет быстро заполнить тестовую базу данных.

После того, как удалось воспроизвести проблему, нужно запускать профайлер. Для Java существуют такие профайлеры, как Eclipse TPTP и YourKit Java Profiler. Нужно настроить фильтрацию таким образом, чтобы показывались вызовы методов именно вашего приложения и искать тот метод, который выполняется дольше всех. Я думаю, что в львиной доле случаев медленными будут методы, в которых выполняется обращение к базе данных (DAO, HibernateHandler'ы и т.д.).

Если используется Hibernate, то в томозящем методе может выполняться вполне себе безобидный запрос. Следует посмотреть какой именно SQL-код генерируется. Для этого в настройках Hibernate-сессии следует выставить параметр hibernate.show_sql в true, а чтобы удобнее было читать - параметр hibernate.format_sql тоже в true.

Некоторые рекомендации по исправлению ошибок, приводящих к потере производительности системы, я привел выше при описании узких мест. Еще хочу отметить, что возможна следующая ситуация: вы поставили клиенту систему, было все нормально, но после какого-то момента возникла проблема. Очень может помочь в ее решении знание этого момента и причин его возникновения. Клиент мог заполнить данными какой-то справочник, поменять какие-то настройки или систему могли просто обновить. Бывает так, что в новой версии системы есть ошибка, которая и приводит к потере производительности. Здесь следует смотреть дифы в вашей системе контроля версий. Понятно, что смотреть дифы по коду всего приложения, особенно если оно большое - занятие не для слабонервных, но после обнаружения причины появляется некоторое ограниченное множество файлов, проверить изменения в которых вполне реально. Особенно весело, когда причина кроется в действиях разработчиков из другого отдела :)

Пожалуй это - все, что я имею сказать по поводу проблем с производительностью. Вообще на эту тему можно книжки писать, но надеюсь что и такая краткая статья будет полезна. В комментариях можно невозбранно поделиться своим опытом в борьбе с тормозящими системами и задать вопросы.

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter