Просто про веб технологии » Performance

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

Yaroslav Vorozhko — Sun, 07 Aug 2011 09:41:04 +0000

Начиная с версии 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, который мы и воспользуемся.

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

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

PLAIN TEXT

CODE:

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

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

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

PLAIN TEXT

CODE:

function buildExcerptFile($documents, $options = array())
{
foreach($documents as $doc){
$file = "/space/".'snip_'.md5($doc).'_'.time();
file_put_contents($file, $doc);
$files[] = $file;
}
$client = new SphinxClient();
$client->setServer('localhost', 9312);
$res = $client->BuildExcerpts( $files, 'index', $keywords,
array(
'around'=>10,
'limit' => 300,
'load_files' => 1
)
);
foreach($files as $file){
unlink($file);
}
return $res;
}

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

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

Sphinx.conf

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

PLAIN TEXT

CODE:

dist_threads = 2

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

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

© Yaroslav Vorozhko for Просто про веб технологии, 2011. | Permalink | No comment | Add to del.icio.us
Post tags: Performance, Search excerpts, Sphinx Search

Как увеличить производительность Sphinx Real Time индексов в 5-10 раз?

Yaroslav Vorozhko — Fri, 25 Mar 2011 14:05:05 +0000

На презентации доклада о Sphinx Real Time индексах на HighLoad++ я показал RT индексы не с лучшей стороны. По сути в докладе я показал, что RT индексы уступают обычным индексам минимум в 5 раз по производительности.

Соответсвенно обсуждение этой проблемы подтолкнуло меня провести эксперименты в поисках оптимальной настройки Sphinx для RT индексов. Задача была обойти или хотя бы достичь производительности обычных индексов.

Результаты и подробности исследования читайте на блоге компании Ivinco целиком посвященному Sphinx Search.

Ускоряем PHP с HipHop

Yaroslav Vorozhko — Thu, 04 Feb 2010 10:09:01 +0000

Сегодня 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

© Yaroslav Vorozhko for Просто про веб технологии, 2010. | Permalink | One comment | Add to del.icio.us
Post tags: C plus plus, Facebook, HipHop, Performance, PHP, Zend Engine

Мифы PHP оптимизации

Yaroslav Vorozhko — Tue, 11 Aug 2009 08:55:48 +0000

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

а. echo быстрее чем print
Echo может быть быстрее, так как оно не возвращает значение. Но, в моем бенчмарке преимущество было очень мало. А, в некоторых ситуациях print будет быстрее echo, например когда ob_start включен.

б. меньше комментариев ускоряет код
Если вы используете кеширование opcodes, то комментарии уже игнорируются. Этот миф идет от PHP3, когда каждая строка PHP интерпретировалась во время исполнения.

в. 'var='.$var быстрее чем, "var=$var"
Так было до версии 4.2 и было исправлено в версии 4.3.

Ускоряет ли код использование ссылок?
Ссылки не дают преимущества строковым, целым и другим базовым типам данных.
Например:

PLAIN TEXT

PHP:

function TestRef(&$a)
{
$b = $a;
$c = $a;
}
$one = 1;
ProcessArrayRef($one);

И тот же самый код без ссылки.

PLAIN TEXT

PHP:

function TestNoRef($a)
{
$b = $a;
$c = $a;
}
$one = 1;
ProcessArrayNoRef($one);

PHP не создает дубликат переменной "отправленной по значению", вместо этого он использует внутренних высокоскоростной подсчет ссылок. Поэтому в TestRef(), $b и $c будут дольше устанавливаться, так как надо вести "трэкинг" ссылок, в то время как в TestNoRef(), $b и $c сразу будут ссылаться на исходное значение $a, а значение счетчика ссылок будет инкрементировано.
В сравнении, функции которые принимают массивы и объекты, работают быстрее тех, которых принимают ссылки. Потому что, массивы и объекты не используют подсчет ссылок, а используется оригинальное значение переданное в параметре.
Например:

PLAIN TEXT

PHP:

function ObjRef(&$o)
{
$a =$o->name;
}

медленнее чем:

PLAIN TEXT

PHP:

function ObjRef($o)
{
$a = $o->name;
}

Примечание: в PHP5 все объекты передаются по ссылке, и нет необходимости устанавливать знак '&' в списке параметров. Производительность работы с объектами в PHP5 значительно выше, чем в php4.

© Yaroslav Vorozhko for Просто про веб технологии, 2009. | Permalink | No comment | Add to del.icio.us
Post tags: myths, optimization, PHP, php4, PHP5

XtraDB новый Storage Engine от Percona

Yaroslav Vorozhko — Tue, 23 Dec 2008 12:17:02 +0000

Новый движок 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

© Yaroslav Vorozhko for Просто про веб технологии, 2008. | Permalink | One comment | Add to del.icio.us
Post tags: MySQL, OpenSource, Percona, Performance, XtraDB

MySQL Row Format Tuning

Yaroslav Vorozhko — Tue, 18 Mar 2008 09:15:21 +0000

При создании или модифицировании таблиц используя MyISAM, вы можете запросить MySQL хранить строки в фиксированном или динамическом формате. Если таблица не содержит BLOB и TEXT полей, то фиксированный формат выбирается по умолчанию, который автоматически конвертирует VARCHAR в CHAR. Иначе, если выбрать динамический формат, то MySQL конвертирует все колонки из типа CHAR в VARCHAR.

Для MySQL, фиксированный формат легче в доступе, кешировании и обновлении информации. Также этот формат менее подвержен порче данных. Если дисковое пространство не является критическим, то фиксированный формат будет хорошим выбором.

Динамический формат использует меньше дискового пространства, но более подвержен риску фрагментации и/или порче данных.

Но давайте сначала посмотрим, на тесты и потом сделаем окончательное заключение.

(...)
Read the rest of MySQL Row Format Tuning (291 words)

© Yaroslav Vorozhko for Просто про веб технологии, 2008. | Permalink | One comment | Add to del.icio.us
Post tags: blob, char, MySQL, row format, text, tuning, varchar, динамический формат, кеширование, обновление, производительность, скорость