Posts Tagged ‘Performance’

Увеличиваем производительность Sphinx BuildExcerpts

Posted in Performance, Sphinx Search, Tips And Tricks on August 7th, 2011 by Yaroslav Vorozhko – Be the first to comment

English version of this post.

Начиная с версии 2.0.1 в Sphinx появилась возможность параллельного построения поисковых сниппетов. Под параллельным построением имеется ввиду, что процесс обработки массива текста предназначенного для построения сниппетов будет распределен по нескольким CPU. Приведенная ниже реализация лучше всего подойдет системам в которых требуется генерировать сниппеты для сотен мегабайт текста.

Для распараллеливания процессов в Sphinx предусмотрена опция dist_threads, которая указывает searchd на сколько CPUs разбивать задачу. dist_threads используется как для обработки поисковых запросов в распределенных индексах, так и для обработки сниппетов, которые мы рассмотрим ниже.

Рассмотрим функцию SphinxAPI BuildExcerpt. По умолчанию функция BuildExcerpt в качестве первого параметра принимает массив текста для обработки,
но к сожалению такой вызов функции не использует параллельную обработку.

Но, начиная с версии 2.0.1, для BuildExcerpt был разработана новая опция load_files. load_files указывает Sphinx, что первый параметр функции BuildExcerpt должен содержать имена файлов, в которых должен находиться текст для обработки. Опция load_files совместно с опцией dist_threads позволяет Sphinx распаралеливать процесс построения сниппетов.

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

Для создания файлов в оперативной памяти в ядро Linux начиная с версии 2.4. включена файловой системой tmpfs, который мы и воспользуемся.

Файловая система

Для этого создадим директорию будущей системы и смонтируем ее.

CODE:
  1. mkdir /space
  2. mount -t tmpfs -o size=1G,nr_inodes=10k,mode=0700 tmpfs /space

В данном примере права на запись будут только у владельца директории /space, а максимальный размер файловой системы будет установлен в 1Gb.

Модифицируем BuildExcerpts

CODE:
  1. function buildExcerptFile($documents, $options = array())
  2. {
  3.     foreach($documents as $doc){
  4.             $file = "/space/".'snip_'.md5($doc).'_'.time();
  5.             file_put_contents($file, $doc);
  6.             $files[] = $file;
  7.         }
  8.  
  9.     $client = new SphinxClient();
  10.         $client->setServer('localhost', 9312);
  11.  
  12.     $res = $client->BuildExcerpts( $files, 'index', $keywords,
  13.         array(
  14.                     'around'=>10,
  15.                     'limit' => 300,
  16.                     'load_files' => 1
  17.                     )
  18.                 );
  19.  
  20.         foreach($files as $file){
  21.             unlink($file);
  22.         }
  23.  
  24.     return $res;
  25. }

Функция работает в три этапа:

  • Первый. Записываем все документы в файлы, причем имена файлов выбираются так, чтоб не получилось коллизий.
  • Второе. Вызываем функцию Sphinx BuildExcerpt, первым параметром передаем массив файлов вместо массива текста. А в третьем параметре указываем опцию load_files = 1
  • Третий. Удаляем созданные файлы для очистки памяти.

Sphinx.conf

В разделе searchd добавляем следующую строку:

CODE:
  1. dist_threads = 2

dist_thread лучше делать равным количеству CPU в системе.

На моих тестовых данных, данная реализация работает в два раза быстрее «стандартного» вызова BuildExcerpts на системе с двумя CPU. Средний размер документа 1-3 Mb, количество документов для одной было равным 100, т.е. один вызов обрабатывал в среднем 200 Mb текста.

Тестирование производительности Обычных, Real Time и Смешанных индексов Sphinx Search

Posted in Sphinx Search on September 21st, 2010 by Yaroslav Vorozhko – Be the first to comment

Немного определенй

Обычный индекс - это индекс, который имеет блок source в конфигурационном файле Sphinx и заполняется путем вызова утилиты indexer.
Real time (RT) - не имеет блока source, а содержит только определение полей и атрибутов. Заполнение RT индекса уже не является обязанностью утилит Sphinx, а ложиться на плечи разработчика приложения.
Смешанный индекс - это индекс, который образуется путем создания распределенного индекса из обычного индекса и RT индекса.

Пример смешанного индекса:

CODE:
  1. index distributed
  2. {
  3. type = distributed
  4. local = plain_main_index
  5. local = real_time_increment_index
  6. }

В данном примере мы через один распределенный индекс можем обращаться одновременно к RT и обычным индексам.

Измерение производительности

Я провел несколько сравнительных тестов над всеми типами индексов, а именно:

  1. Сравнил использования HDD каждым из типов
  2. Сравнил скорость поиска по одиночному запросу
  3. Сравнил скорость поиска по мулти запросам

Все тесты проходили на четырех различных наборах данных. Данные были взяты из wikipedia и распределены на четыри части по:
10 тыс., 100 тыс., 1 млн. и 2 млн. записей.

Сравнение HDD

Я сравнил использование hdd, только для обычных и RT индексов.

hdd usage by RT and plain index

Красное поле RT индексы.
Синее поле обычные индексы.

Как видно из диаграммы, RT индексы для 1 млн. и 2 млн. данных используют примерно на 20% больше места.
Но, Я считаю, что RT индексы все таки по этому показателю лучше, так как для обычных индексов при переиндексации требуется в 2 раза больше места чем сам индекс. Соответственно используя RT мы сможем экономнее использовать hdd на сервере.

Сравнение скорости поиска по одинчоному запросу

Для запросов я создал словарь из 1000 самых популярных слов из каждого индекса. И по этим словам выполнил запросы.

single query performance tests

Красное поле RT индексы.
Синее поле обычные индексы.
Желтое поле смешанные индексы.

Из диаграммы мы видим, что на небольших индексах скорость поиска практически одинаковая.
В то время как на больших данных RT индексы существенно проигрывают обычным индексам, а смешанные индексы заняли положение посередине.

Сравнение скорости поиска по мулти запросам

Словарь я использовал тот же, что и для предыдущего теста, только поиск исполнял сразу по пять запросов паралельно.

multi query performance tests

Красное поле RT индексы.
Синее поле обычные индексы.
Желтое поле смешанные индексы.

Тут мы видим практически туже самую картину. На больших объемах RT индексы сильно проигрывают обычным индексам.
Но, стоит отметить, что производительность мультизапросов примерно в 5 раз лучше чем у одинчоных запросов.

Из этого можно сделать несколько выводов:

  • RT индексы работают быстро только на малых масивах данных
  • Для поддержки высокой производительности приложение стоит проектировать с поддержкой мульти запросов
  • RT индексы могуть стать хорошей заменой инкрементному индексу

Благодарю за внимание.
Желаю удачи!

Sphinx query log parser – анализ query performance

Posted in Sphinx Search, Tips And Tricks on June 2nd, 2010 by Yaroslav Vorozhko – Be the first to comment

Написал простой скриптик на awk для парсинга Sphinx query.log файла.

Парсинг всего файла:

CODE:
  1. awk '{ s += $6 } END { print "seconds: ", s, " average: ", s/NR, " queries: ", NR }' query.log

Парсинг за конкретный период, например за второе Июня:

CODE:
  1. awk '{ if($2=="Jun" && $3==2) {s += $6; r++} } END {print "total seconds: ", s, "average: ", s/r, " total queries: ", r}' query.log

В приведенных скриптах $N - это номер строки в лог файле.

NR - это общее количество записей в файле разделенных переводом строки.

Пример лог файла:

[Wed Jun  2 11:20:52.379 2010] 0.002 sec [ext2/0/rel 2024 (0,10)] [wordpress] spectrum
[Wed Jun  2 11:20:52.384 2010] 0.003 sec [ext2/0/rel 2 (0,1000) @post_type] [wordpress] spectrum
[Wed Jun  2 11:20:52.709 2010] 0.002 sec [ext2/0/rel 963 (0,10)] [wordpress] tin
[Wed Jun  2 11:20:52.713 2010] 0.002 sec [ext2/0/rel 2 (0,1000) @post_type] [wordpress] tin
[Wed Jun  2 11:20:52.997 2010] 0.003 sec [ext2/0/rel 1154 (0,10)] [wordpress] xi
[Wed Jun  2 11:20:53.004 2010] 0.004 sec [ext2/0/rel 2 (0,1000) @post_type] [wordpress] xi
[Wed Jun  2 11:20:53.029 2010] 0.003 sec [ext2/0/rel 1945 (0,10)] [wordpress] nasa
[Wed Jun  2 11:20:53.035 2010] 0.003 sec [ext2/0/rel 2 (0,1000) @post_type] [wordpress] nasa
[Wed Jun  2 11:21:09.359 2010] 0.005 sec [ext2/0/rel 22308 (0,10)] [wordpress] september

На выводе получится:

seconds:  566.738  average:  0.00948642  queries:  59742

Надеюсь это краткое описание языка awk поможет вам написать парсер для своих лог файлов.

Спасибо!

Ускоряем PHP с HipHop

Posted in HipHop, Performance, PHP on February 4th, 2010 by Yaroslav Vorozhko – 1 Comment

Сегодня Facebook анонсировал релиз HipHop.

Коротко, что такое HipHop для PHP:

  • HipHop - это компилятор кода PHP в C++. Т.е. он преобразует PHP код в C++ код для дальнейшей компиляции. Это не другой язык. И это не компилятор времени исполнения (JIT).
  • HipHop будет выпущен Facebook под opensource лицензией, под такой же как и основной код PHP. Facebook возлагает надежды, что разработчики улучшать HipHop и расширят его функциональность, таким образом HipHop сможет заменить больший набор функций PHP.
  • HipHop был одним из проектов в Facebook по улучшению его производительности. Все таки Facebook, второй сайт по объему траффика в интерент и в основном построенный на PHP. HipHop запущен на большинстве LAMP PHP серверах Facebook и в среднем улучшил производительность этих серверов в два раза.
  • HipHop достигает этого, путем исследования вашего PHP приложения и на его основе строить C++ проект. C++ проект потом компилируется и запускается на собственном веб серврере. Это дает возможность исключить PHP Zend engine и Apache из цепочки.
  • Учитывая что, некоторые возможности PHP не поддерживаются. Также, дополнения к PHP написанные на C, должны быть переписаны в HipHop C++ дополнения.
  • Преимущества в скороости HipHop достигаются благодаря статическому анализу, который парсит ваш PHP код ищя пути преобразования динамических частей в статические.
    Учитывая это, ваше улучшение производительности, может сильно варьроваться - более структурированный код получить наибольший прирост в производительности.

Что значит HipHop для вас:

  • Если ваш проект использует sharing хостинг - то ничего.
  • Если ваш проект использует 2 или менее серверов - то ничего.
  • Если у вас нет выделенного development и deployment окружения и у вас нет разработчика знающего C++ - то ничего.
  • Если вы разработчик open source приложения - то немного.
  • Если вы shared хостинг компания - то немного.
  • Если PHP не bottleneck вашего приложения - то пока еще ничего.
  • Если ваше приложения использует много серверов, и в основном на них работает PHP, а также у вас есть все исходники PHP кода, у вас есть немного знаний C/C++, тогджа ответ возможно.
  • Если вы разрабатываете php framework, то ответ иногда.
  • Если у вас есть сильно-связанные части архитектуры, которые удовлетворяют требованиям выше и эти части слабо связаны (через API) с остальной системой, то ответ много что.
  • Если вы обдумываете какой язык выбрать для реализации вашей системы, то ответ очень много.
  • Если вы обдумываете аргумент, переписать весь сайт на другой язык, то вы потеряли свой аргумент.

Есть очень много языковы возможностей, хороших или плохих, которые PHP должен поддерживать, а HipHop нет. Потому как HipHop уникальное решение, он никгода не заменит Zend Engine.

Статья является частичным переводом статьи Terry Chay Faster PHP fo shizzle—HipHop for PHP

XtraDB новый Storage Engine от Percona

Posted in Development, MySQL, Performance on December 23rd, 2008 by Yaroslav Vorozhko – 1 Comment

Новый движок XtraDB был выпущен Percona как замена стандартного InnoDB.

XtraDB на 100% совместим с InnoDB, поэтому вы можете использовать его как полную замену InnoDB. XtraDB разрабатывался для улучшения масштабируемости на современном железе, а также включает в себя множество других возможностей и патчей оптимизированных для высоко нагруженных систем.

Percona XtraDB включает всю InnoDB ACID-совместимую архитектуру и расширенную MVCC архитектуру, добавлены новые возможности, более тюнингована, более информативна, более масштабируема на мульти-процессорных системах, и с улучшенной системой использования оперативной памяти.

Что нового в этом движке? Вот список улучшений:

  • INFORMATION_SCHEMA.XTRADB_ENHANCEMENTS. Эта таблица содержит информацию про различия XtraDb и той же версии InnoDb.
  • Улучшения в SHOW INNODB STATUS.
  • Улучшения в InnoDB IO.
  • InnoDB RW-lock fixes. Улучшена масштабируемость для систем с 8+ ядер.
  • Buffer pool fixes
  • innodb_buffer_pool_pages

В общем это сейчас тунингованый InnoDB, только OpenSource. Для комьюнити публичный OpenSource считаю большим плюсом.

Percona сделала и продолжает делать отличную работу по развитию и поддержке MySQL.

Думаю Percona это новая MySQL и уже в скором будущем мы не раз в этом убедимся. :)

Оффициальный анонс XtraDB

Тесты производительность ввода вывода XtraDB

Тесты производительности и нагрузки CPU XtraDb

Документация по XtraDB http://www.percona.com/docs/wiki/percona-xtradb:start

Исходные коды на XtraDB https://launchpad.net/percona-xtradb

Обсуждения XtraDB и остальных разработок Perocona http://groups.google.com/group/percona-dev