06 February, 2010

Список для проверки при оптимизации Grails приложений

Выкладываю ниже список задач, которые нужно/можно выполнить для оптимизации приложения, написанного на Grails, может кому пригодится.

Тестирование проведённых оптимизаций

Первым делом необходимо разработать критерии проверки, которые позволят оценить эффективность проведённых оптимизаций.
  1. Установить Java Melody плагин для Grails для проведения анализа.
  2. Разработать скрипты для проведения нагрузочного тестирования.
  3. Прогнать скрипты.
  4. Проанализировать результаты Java Melody, выявить узкие места, произвести нужные оптимизации.

Общие оптимизации

Очень часто обновление до последней версии используемых библиотек попутно улучшает производительность.
  1. Обновить Java до последней версии
  2. Обновить Groovy до последней версии.
  3. Обновить Grails до последней версии.
  4. Обновить jQuery до последней версии.
  5. Оптимизировать настройки виртуальной машины Java (например, -server -Xmx270m -Xms270m -XX:MaxPermSize=80m -Xverify:none -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+UseAdaptiveSizePolicy -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31 -XX:+AggressiveOpts)
    a. http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
    Вообще, по оптимизации JVM написаны целые книги, так что не буду здесь останавливаться.

Оптимизация клиентской части

  1. Настроить кэширование статических ресурсов в Томкате.
  2. Настроить сжатие статических ресурсов в Томкате.
  3. (поставить прокси на nginx для кэширования статических ресурсов ?)
  4. Установить плагины для Firebug, которые оценят производительность клиентской части.
  5. Проанализировать страницы веб-сайта с их помощью
  6. Провести предлагаемые оптимизации.

Оптимизация клиентской части приложений, написанных на Grails

  1. Установить плагин UI Performance
  2. Провести оптимизацию с использованием плагина UI Performance

Оптимизация базы данных

  1. Оптимизировать производительность сервера базы данных (SQL Server)
    a. http://www.sql-server-performance.com/tips/all_main.aspx
    a. http://msdn.microsoft.com/en-us/library/ms998577.aspx
  2. Проверить наличие индексов в базе данных, добавить необходимые
  3. Найти неоптимальные запросы в БД, оптимизировать

Оптимизация работы с базой данных

  1. Обновить версию JDBC-драйвера
  2. Настроить кэширование в Hibernate.
    Ресурсов в сети предостаточно, навскидку вот парочка.

Оптимизация серверной части приложения

  1. Произвести профилирование приложения (использовать Visual VM, YJP Profiler), найти узкие места и оптимизировать их.

Оптимизация серверной части приложения (опционально)

  1. Установить плагин Perf4J для грэйлза
  2. Добавить необходимые счётчики в код
  3. Прогнать нагрузочные тесты, найти узкие места, оптимизировать.

Заключение

В целом, в данном списке нет ничего нового, это всего лишь компиляция публично доступных материалов. Тем не менее, решил это опубликовать, чтобы сэкономить время другим.

6 comments:

  1. А на сколько, по Вашему, медленнее Grails, чем допустим, spring MVC, (если знакомы Roo). И на чём конкретно падает производительность?

    ReplyDelete
  2. @serger Вообще сравнения производительности показывают, что groovy, на котором написан grails в десятки раз медленнее явы [1], [2]. Но зато добавляются бенефиты динамического языка. Вообще я за Roo, но его ещё рано пускать в production.

    [1] http://www.codecommit.com/blog/java/groovys-performance-is-not-subjective
    [2] http://groovy.dzone.com/news/groovy-vs-java-performance-jav

    ReplyDelete
  3. Да, тяжко, но подвижки есть...
    http://stronglytypedblog.blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html
    http://stronglytypedblog.blogspot.com/2010/02/groovy-performance-now-were-talkin.html

    ReplyDelete
  4. @serger Да, про груви++ я знаю. Но ведь это костыль. :)

    ReplyDelete
  5. и ещё:
    http://blog.gramant.ru/2009/10/15/%D0%B0%D0%B1%D1%81%D0%BE%D0%BB%D1%8E%D1%82%D0%BD%D0%BE-%D0%B1%D0%B5%D1%81%D0%BF%D0%BE%D0%BB%D0%B5%D0%B7%D0%BD%D1%8B%D0%B9-%D1%82%D0%B5%D1%81%D1%82-%E2%84%961-php-vs-groovy/

    ReplyDelete
  6. @serger По вашей ссылке достаточно странное сравнение.
    Остались такие вопросы:
    1. Какие были настройки JVM?
    2. Почему не учитывается, что при работе на сервере поведение может изменяться (ограничения по количеству потоков, например)
    3. Не сказано, сколько раз прогонялся каждый тест.
    4. Сколько было памяти выделено тестам.

    У меня для groovy вот такой результат получился:
    Using 100000 iterations.
    7.531 sec. - +/- 0.1 секунды, прогонял 10 раз.

    Тесты гонял на домашней машинке (AMD64 4200, 4GB RAM, Java 1.6.0.16, Groovy 1.6.3. OS: Ubuntu 9.10).

    ReplyDelete