Solr monitoring in NewRelic

      Сегодня закончил работу над плагином для мониторинга поискового движка Solr в NewRelic. Так как в моем текущем проекте мы используем именно Solr - то этот плагин стал логичным продолжением моей предыдущей работы -  плагина для мониторинга Sphinx в NewRelic.  Плагин для Solr получился гораздо более объемным - хотя бы потому что Solr предоставляет намного больше информации чем Sphinx. В настоящее время он собирает около 70 различных метрик, как по solr в целом, так и по каждой его подсистеме в отдельности.

      На первом я расположил самые важные характеристики - данные о потреблении памяти самой JVM и о количестве этой самой памяти в системе:

Далее идут данные по количеству запросов в секунду и по среднему времени ответа на каждый из запросов, с разбивкой по типам запросов:

Затем идут данные по обновлению индексов - сколько приходит запросов на обновления и каких они типов:

Также плагин собирает детальную информацию по кэшам, которые использует solr - hitrate для каждого типа кэша и размер этого кэша:

Также имеется детальная разбивка по каждому кэшу - сколько было запросов, сколько промахов, сколько вытеснений и тд:

  Ну и в завершении всего - статистика по ошибкам и таймаутам:

Сам плагин находится вот тут - https://github.com/yvasiyarov/newrelic_solr 

Мониторинг Sphinx в NewRelic

      Сегодня я закончил работу над еще одним небольшим open source проектом - агентом для мониторинга  Sphinx-а в NewRelic. Вообще Sphinx очень часто используется в PHP приложениях для поиска и не только, а NewRelic в последние два года стал одной из самых популярных платформ для мониторинга этих самых приложений. Поэтому иметь статистику по по Sphinx в одном интерфейсе с остальными компонентами приложения было бы весьма не плохо.  В общем получился небольшой такой плагин:

 Он занял всего около 5 мегабайт памяти на сервере и вот уже сутки как работает без замечаний. Погоняю его месяцок у себя и если все будет норм - соберу deb пакетик для народа. Чтобы не приходилось всем Go компилятор устанавливать чтобы его поставить.

    Он собирает следующие метрики: 

      1. Количество запросов в секунду

      2. Количество команд в секунду с разбиением по командам разных типов

      3.  Количество подключений в секунду 

      4. Количество отброшенных подключений

      5. Количество времени затрачиваемое на один запрос в миллисекундах(avg_query_wall): 

Сам плагин можно взять у меня на гитхабе - NewRelic Sphinx

Sphinx - threads VS prefork

   Сегодня завершил перенос Sphinx на отдельный сервер. Сравнивал производительность при использовании разных типов распаралеливания: threads VS prefork. Если коротко - prefork сосет и очень сильно. Возможно у меня руки не от туда растут - но при равных конфигах в режиме threads sphinx работает намного быстрее - я бы сказал на порядок. 

    Из минусов - threads воркеры постоянно падают - но так как watchlog включен по умолчанию - пока вы не заглянете в лог вы об этом можете и не узнать вообще - пока не заглянете в лог. Мне пришлось туда заглянуть после того как sphinx неожиданно упал. Как потом оказалось - один из крашей воркеров привел к перезапуску сфинкса, во время которого он не смог прочитать все причитающиеся бинлоги и счел за лучшее - тупо умереть.  При чем если прочитать логи то sphinx успешно читал потерянный бинлог файл  за 15 минут до этого. Такое впечатление что sphinx умер во время слияния бинлог файлов, так что файл бинлога был удален с диска - но в мета информация так и не была обновлена, в результате при перезапуске сфинкс пытался прочитать удаленный файл бинлога и умирал.

    В качестве временного решения отрубил запись бинлогов вообще - благо объем записи в RT индекс у меня не большой, и rt_flush_period + полная переиндексация раз в сутки меня пока вполне устраивает.

Бага в PHP PDO Mysql

      Наткнулся  на замечательную багу в PHP PDO Mysql - после обновления PHP c 5.3.1 до 5.3.2  последний rowset в пакетном SQL запросе просто перестал возвращатся. В общем случае возможность выполнять несколько SQL запросов за одно соединение не часто используется - в основном в силу сложности аггрегирования несвязных запросов в один пакет. Но в моем случае mysql соединение использовалось для выполнения запросов к Sphinx. А в sphinxQL к примеру для того чтобы получить общее количество документов удовлетворяющих критерию - без учета выражения LIMIT необходимо отправлять сразу два запроса в одном пакете - непосредственно запрос по выборке документов и "SHOW META". Также если вы отправляете несколько схожих запросов одним пакетом - то сфинкс может их оптимизировать, кэшируя общие поддеревья. В общем пока придется дописывать в каждый пакет дополнительный запрос "SHOW META" чтобы как-то обходить это ограничение - другого решения этой проблемы я пока не знаю.

Go(golang) vs PHP по взрослому

      Я давно хотел устроить сравнение скорости Go и PHP на какой-нибудь реальной задаче  и в условиях близких к боевым. Интернеты кишат синтетическими тестами - например  вычисление квадратных корней в милион потоков  - причем эти тесты чаще всего выполняются на ноутбуке. 

    Итак, есть реальная задача - backend для автосаджеста городов. На вход передается набранная строка - возвращается список возможных городов в JSON. Сами города находятся в sphinx, в количестве 30 тысяч. 

Что с чем сравниваем:

    Текущая реализация написана на PHP c использованием фреймворка Yii. Состоит буквально из 10 строчек, 5 из которых комментарии. Естественно используется opcode cacher.  

   Go реализация занимает чуть побольше - 35 строчек кода. Тестировалось 2 варианта FastCGI и HTTP. Различаются они фактически только подключаемой библиотекой - "net/http" или "net/http/fcgi".  Забегая вперед сразу скажу - разница между этими реализациями лежит в пределах погрешности - менее 1 сотой секунды.

    На чем собственно проводилось тестирование: PHP реализация была разложена на 2-х фронтах(Intel Xeon 8CPU/32GB RAM/Ubuntu 12.xx).  Go реализация была разложена только на одном фронте - потому как деплойный скрипт написан именно под PHP, а раскидывать ручками больше чем на один сервер было лень.

       Как тестировалось: был сгенерирован список URL для siege, состоящий примерно из 250 тысяч различных запросов к автосаджестеру. siege запускался с одного из фронтов - чтобы не учитывать сетевые задержки. Тестировалось с 30, 40 и 50 одновременных соединений.

        Итак результаты:

При 30 одновременных соединениях

Среднее время ответа: PHP - 0.36 секунд, Go - 0.01 секунда.

Самая длинная транзакция: PHP 12.04 секунды, Go - 5.02 секунд.

Самая короткая транзакция: PHP 0.02 секунды, Go - 0.00 секунд.

При 40 одновременных соединениях

Среднее время ответа: PHP - 0.65 секунд, Go - 0.09 секунд.

При 50 одновременных соединениях

Среднее время ответа: PHP - 0.96 секунд, Go - 0.22 секунд.

Выводы:

1. Переписывание на Go данной задачи выглядит более чем оправдано.  

2. При увеличении числа одновременных подключений разница между GO и PHP сильно сокращается. Объяснение этому одно - начинает засасывать sphinx - который запущен только на одном сервере. Также на это повлияло то что siege был запущен на одном из фронтов. 

Также я сравнивал варианты когда обращение идет к Go серверу напрямую и через Nginx: результат порадовал - среднее время ответа различается буквально на 0.01-0.02 секунды. Что в общем еще раз доказывает что проксирование через Nginx работает очень быстро.

Еще я проводил сравнение при разных GOMAXPROCS: результат фактически не изменился. Чего собственно и следовало ожидать в данных условиях.

   

На стачку!

В минувшие выходные на моей малой Родине, в городе Ульяновске прошла отличная конференция веб разработчиков: На стачку
Там было куча интересных докладов:
1. NoSQL под нагрузкой: практика. Подробно рассмотрены redis, mongodb, memcachedb.  Популярно объяснили почему не стоит использовать mongodb когда данные не помещаются в памяти. На мой взгляд это практически означает профнпригодность этой базы данных. Потому как в случае когда все данные помещаются в памяти - любая база может выдавать в общем-то приемлемые результаты, если конечно руки из правильного места растут. В общем этот доклад всем рекомендую к просмотру.
2. Нагруженный поиск на Sphinx. Роман Павлушко - очень подробно разобраны стратегии оптимизации sphinx. Также рекомендуется всем кто планирует использовать его в своих проектах.

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