Принцип “Long Polling” (или “Comet“) позволяет сделать возможным установление постоянного соединения клиента с Web приложением и также периодичной отправки данных клиенту в рамках этого соединения (без необходимости клиента постоянно делать HTTP запросы для проверки новых данных). Другими словами, эта модель позволяет реализовать постоянные HTTP соединения для получения данных порциями. Наиболее популярное применение - чаты, твиттеры и другие live-updated потоки - клиент постоянно “слушает” сервер на предмет появления новых сообщений, и как только новые сообщения появляются - они мгновенно доставляются ему.

Сам принцип не несет в себе инноваций в HTTP протоколе, т.к. этот подход реализуем обычными средствами. Проблема заключается в том, что стандартное решение - установка постоянного соединения с обычным Web сервером (а значит и с обслуживающей платформой, например php-бекендом) - крайне ресурсоемкое и не применимо на практике. Другой подход - постоянно опрашивать приложение на предмет появления новых данных является еще более ресурсоемким.

Решением этой проблеммы стали т.н. HTTP-PUSH (или comet) сервера, позволяющие облуживать огромное количество постоянных соединений эффективно расходуя ресурсы. Как они устроены и как применяются на практике?

Принцип работы Comet-сервера

Необходимо отметить, что Comet сервер решает задачу отправки клиенту определенных данных порциями. Comet сервера реализуют т.н. HTTP Push Relay протокол (например, Basic HTTP Push Relay Protocol). Принцип работы такого протокола заключается в следующем:

• На Web сервере создается т.н. “канал” с уникальным ключем. Это делается на стороне приложения путем посылки запроса к Comet-серверу
• Клиент устанавливает обычное HTTP соединение с Comet-сервером, передавая в параметры ключ канала, из которого он будет получать данные. Сервер удерживает такое соединение, пока не отправит очередную порцию данных
• Основное приложение, по определенному событию (например, кто-то написал сообщение клиенту), шлет в канал Comet сервера с нужным ключем это сообщение
• Как только в канале появляется сообщение, Comet сервер отправляет его соответствующему клиенту и закрывает HTTP соединение (иногда соединения не закрываются, а продолжают быть активными)

Таким образом, сервер реализует “стэки” сообещений, а их раздача происходит без участия тяжелых бекендов. Бекенды вступают в силу только тогда, когда необходимо отправить сообщение.

Nginx и модуль HTTP Push

Модуль nginx_http_push_module позволяет превратить Nginx в Comet сервер, реализуя протокол Basic HTTP Push Relay Protocol. Преимущества этого модуля и протокола - в его простоте по сравнению с альтернативными решениями (например, протоколом Bayeux и сервером CometD).

Установка

Для установки модуля необходимо скачать его исходники и перекомпилировать Nginx, т.к. модуль является внешней разработкой:

wget http://pushmodule.slact.net/downloads/nginx_http_push_module-0.692.tar.gz
tar -xvf nginx_http_push_module-0.692.tar.gz
...
cd /where/nginx/sources/are
./configure \
  --add-module=/path/to/nginx/modules/sources/nginx_http_push_module-0.692/
make; make install

Конфигурация

Для базовой конфигурации нам необходимо объявить две рабочих точки в Nginx’e: точка публикации сообщений (приватная - доступна только для самого приложения) и точка раздачи сообщений (публичная - к которой будут подключаться клиенты):

	location /publish {
		# Название переменной с идентификатором канала
		# в нашем примере "cid", т.е. запрос будет таким:
		# http://example.com/publish?cid=s42378fwe
		set $push_channel_id $arg_cid;
		push_publisher;

		# Отключаем хранение очереди (сообщение удаляется после доставки)
		push_store_messages off;
	}

	location /listen {
		push_subscriber;

		# Обслуживать только первого "слушателя"
		# Остальным отправляем 403
		push_subscriber_concurrency first;

		# Идентификатор канала
		set $push_channel_id $arg_cid;

		# Тип ответа
		default_type text/plain;
	}

После этого при отправке сообщения нужно будет посылать его в соотв. канал, делая POST запрос на “/publish”. Клиент же отправляет GET запрос на “/listen” и ждет ответа. Когда приходит ответ, клиент делает повторный запрос на “/listen” и т.д.

Все параметры конфигурации с подробным описанием смотрите на официальном сайте.

Пример

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

# Определяем ID канала
$channel_id = 12345;

# Сообщение
$message = 'Привет тебе!';

# Отправляем сообщение в канал
$c = curl_init( 'http://localhost/publish?cid=' . $channel_id );
curl_setopt($c, CURLOPT_RETURNTRANSFER, true);
curl_setopt($c, CURLOPT_POST, true);
curl_setopt($c, CURLOPT_POSTFIELDS, json_encode($message));
$r = curl_exec($c);

Для получения сообщения код на Javascript будет выглядеть где-то так (на основе Jquery):

var channelId = 12345;
function check_messages() {
	$.get('/listen?cid=' + channelId, {}, function(r) {
		// Считаем, что у нас есть div c id=messages,
		// куда мы дописываем сообщения
		$('#messages').append(r);
		setTimeout(check_messages, 500);
	}, 'json');
}

check_messages();

В каких случаях Вам приходилось пользоваться comet-серверами?

Related posts:

1. Настройка nginx
2. Настройка nginx для отдачи файлов
3. Ресайзинг картинок в nginx

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

Суть

Зачем вообще нужны такие решения, как Gearman, читайте в статье “Очередь сообщений - что это и зачем?“. Наша задача реализовать отложенную отправку почты, т.к. это довольно ресурсоемкая операция и может сильно влиять на скорость ответа приложения клиенту.

Установка

Установка происходит в два этапа. Сначала ставим сам сервер (исходники качаем тут):

tar -xvzf  gearmand-version.tar.gz
cd gearmand
./configure
make; make install

Теперь устанавливаем php расширение:

pecl download gearman-0.7.0
tar -xvf gearman-0.7.0.tgz
cd gearman-0.7.0
phpize
./configure
make
make install

Не забываем добавить “extension=gearman.so” в php.ini. Если все хорошо, то phpinfo() покажет нам:

Клиент

В нашем клиенте (основное приложение) отправка email сообщений будет осуществляться путем регистрации новых задач на сервере Gearman:

...
$mail = array(
  'to' => 'test@gmail.com',
  'subject' => 'Привет',
  'body' => 'Это тестовое сообщение',
);
...

# Подключаемся к серверу
$client= new GearmanClient();
$client->addServer();

# Регистрируем задачу для фонового выполнения
# "sendmail" - это тип задачи
# $mail - это данные письма
$result = $client->doBackground("sendmail", serialize($mail));

Обратите внимание, что PHP клиент принимает только строку в качестве данных о задаче, поэтому необходимо любой другой тип объектов сериализовать. Мы использовали асинхронное выполнение задач (метод doBackground), поэтому реальное время отправки почты не повлияет на скорость выполнения нашего приложения.

Обработчик задачи

Обработчик - это отдельное приложение (скрипт), который “слушает” сервер на предмет появления новых задач. Как только задача приходит - он выполняет связанную с ней логику (в нашем случае это будет отправка письма с помощью почтового сервера).

# Создаем "воркера" и подключаемся к серверу задач
$worker= new GearmanWorker();
$worker->addServer();

# Регистрируем обработчик события "sendmail"
# "send_mail" - это имя функции, объявленной ниже
$worker->addFunction("sendmail", "send_mail");

while (1)
{
  echo "Ждем работы...\n";

  $ret= $worker->work();
  if ($worker->returnCode() != GEARMAN_SUCCESS) break;
}

# Функция реальной отправки почты
# В аргумент ей передается объект задачи
function send_mail($job)
{
  $workload= $job->workload();
  $data = unserialize($workload);

  mail($data['to'], $data['subject'], $data['body']);
}

Полезные ссылки

• Официальный сайт
• PHP клиент

Related posts:

1. Очередь сообщений на основе PHP и MemcacheQ

Когда речь идет об оптимизации Web приложений, большое внимание следует уделять оптимизации клиентской части. Размер статических данных обычно в разы превосходит размер динамически генерируемых. Большинство этих данных - это медиа данные. Чаще всего это изображения (картинки для верстки и фотографии), кроме того есть flash, видео, аудио и т.п.

В этой статье рассмотрим основные инструменты оптимизации картинок для Web приложений.

Суть оптимизации картинок

Зачастую файлы изображений хранят множество дополнительной информации, например детали о съемке фото, комментарии, текстовое описание, географические данные и т.п. При использовании в Web практически всегда эти данные не нужны. Существуют инструменты, которые позволяют вырезать всю ненужные мета данные, а также делать определенную оптимизацию изображения без потери качества. В некоторых случаях это может привести к 90% уменьшению размеров изображений.

Кроме этого, важно выбирать подходящий формат для каждой конкретной картинки, что позволит использовать максимально эффективное сжатие.

Форматы

В Web можно использовать три формата изображений:

• PNG - сегодня это основной формат, ввиду эффективности сжатия и функциональных особенностей. Поддерживается всеми современными браузерами. Этот формат следует всегда выбирать по умолчанию для графики
• GIF - этот формат следует использовать, когда необходима анимация. Также в некоторых случаях (очень маленькие файлы - менее 10х10 пикселей) этот формат обеспечивает лучшее сжатие, чем PNG
• JPEG - выбирайте всегда для фотографий. Этот выбор лучше, чем PNG, т.к. JPEG позволяет выбрать более эффективную стратегию сжатия благодаря размытию (экономия за счет небольшой потери качества)

Инструменты для оптимизации

imagemagick

Если Вы используете imagemagick для генерации превью (thumbnails), то включайте опцию “-strip” для вырезания всех ненужных метаданных из изображений:

convert test.jpg -resize 100x100 -strip test_100.jpg

Особенно хороший эффект дает для фотографий (в которых размер метаданных может достигать десятков килобайтов)

Оптимизация JPEG с помощью jpegoptim

В Debian системах эта утилита доступна в пакетах:

apt-get install jpegoptim

Для оптимизации файлов нужно указать их в параметрах с опцией “–strip-all”:

jpegoptim --strip-all test.jpg

Оптимизация PNG с помощью pngnq

В Debian системах эта утилита также доступна в пакетах:

apt-get install pngnq

Работает так (в результате создает новый файл - старый не перезаписывает):

pngnq test.png

Опыт

На одном из наших проектов простой обработкой картинок (не фотографий) вышеперечисленными инструментами удалось уменьшить общий их размер более чем на 15%. И это при том, что почти все картинки создавались с помощью специальных инструментов с оптимальными настройками. Таким образом процедура оказалась очень полезной, к тому же крайне простой.

Related posts:

1. Оптимизация картинок для Web
2. Оптимизация клиентской части
3. Ресайзинг картинок в nginx

Врядли сегодня найдется тот, кто еще не слышал про key-value базы данных, или, как их называют в народе, NoSQL. Те, кто успел попробовать продукты вроде Redis, MemcacheDB и других, обнаружили некторые сложности при решении привычных задач - выборка списков и поиск.

В этой статье мы рассмотрим принципы решения типичных задач в key-value базах данных.

Основная сложность

Восновном, все key-value базы данных представляют из себя распределенные хеш-таблицы. Это самая сильная их сторона, т.к. предоставляет высокую производительность и крайне упрощает масштабирование. Тем не менее, это свойство всплывает на поверхность, когда Вам необходимо работать со списками. В MySQL следующие задачи решаются в два счета:

• Выбрать 10 последних пользователей
• Выбрать Самые популярные посты в блоге
• Найти продукты, для которых оставлено более 3х комментариев
• Полнотекстовый поиск
• Поиск по любому свойству (найти пользователя, email которого такой-то)

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

И так, по порядку:

Поиск по ключу

Существует класс задач, когда Вам необходимо делать выборку одного объекта не по первичному, а вторичному ключу (например, поиск пользователя по email’у, поиск автора по никнейму т.п.). Принцип решения этой задачи следующий: после создания нового объекта, Вам необходимо создать ссылки на его первичный ключ для всех его свойств, по которым придется делать выборку. Например мы создаем пользователя:

user_134: {
  name: Den,
  email: golotyuk@gmail.com
}

И дублируем ключ email:

user_email_golotyuk@gmail.com: {
  id: 134
}

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

Использование РСУБД

Если Вам нужен MySQL - используйте его, не стреляйте по воробьям их танка

Существует класс задач, для которых можно и нужно использовать РСУБД, такие как MySQL и Postgres. Если Вам необходимо делать выборки списков с фильтрами и сортировками, то Вам следует использовать более подходящую для этого РСУБД. Хороший пример - это посты в блоге. (выборки, которые скорее всего нужно будет делать - самые новые, самые популярные, самые комментируемые записи и т.п.).

Подход довольно простой, но на практике очень часто задачи сильно переплетены, и в итоге Вы можете прийти к тому, что РСУБД возьмет все задачи обратно на себя. В этом случае следует подумать о гибридном решении:

Гибридное решение - дополнительная РСУБД

Это решение представляет из себя смесь key-value и РСУБД. Все данные Вы храните в key-value, но те свойства, по которым понадобиться делать агрегатные выборки дублируете в РСУБД (с указателем на ключ). Т.о. Вы сохраните производительность key-value базы данных и сможете решить свою задачу. Сложность тут заключается в том, что Вам придется следить за синхронизацией данных в обоих базах данных, что может сильно усложнить логику приложения.

Полнотекстовый поиск и выборки с задержками

Одна из частых задач - полнотекстовый поиск. Существуют отличные решения - Sphinxsearch, Solr и другие. К сожалению, ни одно из них еще не поддерживает индексацию key-value баз данных, но зато все предоставляют интерфейсы для ручной индексации. Вам нужно будет только описать реализацию для конкретного набора данных (например, с помощью XmlPipe в Sphinx’e).

Наряду с полнотекстовым поиском часто стоят и задачи, связанные с агрегатными выборками, которые не критичны к текущему состоянию данных. Например, когда Вы строите рейтинг пользователей (или постов в блоге, или продуктов в магазине или …), Вы можете спокойно использовать данные по состоянию на прошлый час(день/неделю/…). В качестве решения Вы можете использовать полнотекстовые серверы по их непрямому назначению. Многие из них поддерживают разнообразные фильтры и сортировки, которых достаточно для решения 90% задач подобного рода.

Распределенные выборки

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

Что еще сюда можно добавить?

Related posts:

1. Key=value (ключ=значение) базы данных

Основная проблема заключается в том, что sphinx не позволяет использовать буквенно-цифровые значения в качестве ID документов. Есть несколько вариантов решения этой проблемы.

Строим индекс с помощью xmlpipe

Поскольку в Sphinx пока нет реализации источника данных для mongo, то придется использовать XMLpipe для индексации:

source src_test {
    type = xmlpipe
    xmlpipe_command = php /home/golotyuk/www/mongosphinx/index.php
}

index test {
        morphology              = stem_enru
        charset_type            = utf-8
        source                  = src_test
        path                    = /var/lib/sphinxsearch/data/test
}

Реализация XML генератора может быть приблизительно такая:

<?='<?xml version="1.0" encoding="utf-8"?><sphinx:docset>'?>

<sphinx:schema>
<sphinx:field name="content"/>
</sphinx:schema>

<?

$m = new Mongo();
$c = $m->test->documents;
$list = $c->find();

?>

<? foreach ( $list as $document ) { ?>
<sphinx:document id="<?=$document['numeric_id']?>">
<content><![CDATA[[<?=$document['text']?>]]></content>
</sphinx:document>
<? } ?>

</sphinx:docset>

Все предельно просто кроме одной проблемы - ID mongo документа представлен в буквенно-цифровом виде, чего не понимает сфинкс. Есть несколько подходов:

Решение проблемы с ID документа

Пользовательский ID

Первый вариант - хранить в каждом mongo-документе пользовательский (сгенерированный руками) цифровой ID отдельным свойством:

{
	"_id" : ObjectId("4bf2c7f38ead0e0d05070000"),
	"sid" : 7,
	"text" : "Много текста"
}

В этом случае свойство sid будет использоваться для индексации в качестве ID документа (в примере выше атрибут называется “numeric_id”).

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

В качестве альтернативного решения можно использовать таблицы соответствий ID документа Mongo и ID документа Sphinx (например в MySQL). В этом случае не нужно будет руками реализовывать механизм автоинкремента, но придется использовать дополнительную СУБД.

Выборка ID, как атрибута

ID mongo-документа можно выбирать как атрибут при индексации. Это наиболее верное решение, но учитывая, что атрибут строчный, понадобится обновиться до версии 0.9.10 (на этот момент эта версия еще не в релизе).

В этом случае Вам просто придется генерировать уникальные ID для сфинкса (которые будут фактически бесполезными для Вас - их можно генерировать на этапе индексации), а mongo ID доставать как свойство. Схема индекса будет следующая:

<sphinx:schema>
<sphinx:field name="content"/>
<sphinx:attr name="_id" type="string"/>
</sphinx:schema>

Как видно, id mongo-документа описан как строчный атрибут. Для генерации id документа sphinx можно использовать простой инкремент, например:

<? $i = 0; foreach ( $list as $document ) { ?>
<sphinx:document id="<?=$i + 1?>">
<content><![CDATA[[<?=$document['text']?>]]></content>
<_id><?=$document['_id']?></_id>
</sphinx:document>
<? } ?>

В результате sphinx будет возвращать атрибут “_id”, в котором будет находится идентификатор документа Mongo.

Related posts:

1. Дельта индекс в Sphinx
2. Solr - полнотекстовый поиск от Apache (на основе Lucene)
3. Sphinxsearch - объединение индексов (index merging)

Какой клиент лучше использовать при разработке на PHP - php-memcached или php-memcache? Все зависит от того, какие особенности Вам нужны (неужели?). Давайте сравним в двух аспектах - функциональность и производительность.

Функциональность

Клиентская библиотека php-memcache была разработана еще в 2004 году и сегодня существует уже довольно стабильная версия, которая используется в 99.9% проектах (использующих сервер Memcache). Большим недостатком этой библиотеки является ее ограниченные способности - она реализует только часть протокола мемкеша, и не позволяет использовать его дополнительные возможности (какие именно - чуть ниже).

Библиотека php-memcached была разработана сравнительно недавно, но уже успешно используется на некоторых крупных проектах (например, digg.com - из которого и вышла эта разработка). Самое главное ее преимущество - это полная реализация протокола, в том числе:

• CAS токены для версионирования ключей
• Обратные вызовы (callbacks)
• Метод getDelayed() позволяющий уменьшить время ожидания откладывая фактическое чтение ключей
• Поддержка бинарного протокола
• Возможность избежать сериализации используя igbinary

Производительность

Теперь давайте сравним производительность на практике.
Для этого напишем небольшой скрипт, который делает одинаковые операции с обоими клиентами:

<?

$ops = 10000;

$m = new Memcache();
$m->addServer('localhost');

$md = new Memcached();
$md->addServer('localhost', 11211);

echo "Test operations: {$ops}";
echo "<h3>get test</h3>";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $m->get( md5(rand(1000, 99999)) );
echo "Memcache: " . ($res['memcache']['set'] = microtime(true) - $s ) . "<br />";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $md->get( md5(rand(1000, 99999)) );
echo "Memcached: " . ($res['memcached']['set'] = microtime(true) - $s );

echo "<h3>set test</h3>";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $m->set(md5(rand(1000, 99999)), 2);
echo "Memcache: " . ($res['memcache']['get'] = microtime(true) - $s ) . "<br />";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $md->set(md5(rand(1000, 99999)), 2);
echo "Memcached: " . ($res['memcached']['get'] = microtime(true) - $s );

echo "<h3>delete test</h3>";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $m->delete(md5(rand(1000, 99999)));
echo "Memcache: " . ($res['memcache']['delete'] = microtime(true) - $s ) . "<br />";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ ) $md->delete(md5(rand(1000, 99999)));
echo "Memcached: " . ($res['memcached']['delete'] = microtime(true) - $s );

echo "<h3>combined test</h3>";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ )
{
	$key = md5(rand(1000, 99999));
	$m->set($key, 2);
	$m->get($key);
	$m->delete($key);
}
echo "Memcache: " . ($res['memcache']['combined'] = microtime(true) - $s ) . "<br />";

$s = microtime(true);
for ( $i = 0; $i < $ops; $i++ )
{
	$key = md5(rand(1000, 99999));
	$md->set($key, 2);
	$md->get($key);
	$md->delete($key);
}
echo "Memcached: " . ($res['memcached']['combined'] = microtime(true) - $s );

Как видно, скрипт просто выполняет основные операции сохранения, чтения и удаления ключей 10 тыс. раз и замерает их время для каждого клиента.

Результаты работы теста

Как видно из графика, производительность клиента php-memcache почти втрое выше, чем php-memcached. Следует учесть, что показатели при работе с бинарным протоколом почти не отличалась по времени от ASCII протокола.

Обновление

Благодаря внимательному читателю этого блога удалось выяснить, что сильные отличия в показателях тестов связаны с конкретными версиями и настройками библиотек. Проверка на других платформах дает отличие в производительности не более 10%.

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

Хотя важно заметить: даже не смотря на трехкратное различие в скорости работы, операции общения с сервером Memcache обычно занимают доли процента от времени исполнения приложения. Различие в скорости работ библиотек может быть заметно только при массовой работе с кешом, или же на огромных объемах данных.

Related posts:

1. Memcached Multi-Get, зачем?
2. Твиттер на основе MemcacheDB и PHP

Вы, конечно, много раз видели ленту обновлений на фейсбуке и твиттере. В двух словах - это список событий, которые произошли недвано на сайте и касаются Вас (чаще всего это деятельность Ваших друзей). Это очень удобный инструмент информирования пользователей и неотъемлемая часть современных социальных проектов. А как обстоит дело с реализацией?

На первый взгляд все очень просто, а на практике все сложно. Давайте разберемся детально (на примере MongoDB + PHP, заодно посмотрим на эту новую шумную СУБД).

Что такое эта “лента обновлений”?

На этом скрине Вы видите ленту обновлений или “news feed” с фейсбука (facebook.com). Там представлены все события Ваших друзей.

Как будем делать? На первый взгляд все кажется довольно просто. У нас есть ограниченный набор действий (загрузить фото, обновить статус и т.п.). Для реализации подобной ленты новостей нужно выбрать все такие действия для каждого друга и отсортировать их по времени. Но сразу же становится видна недальновидность такого подхода:

• Очень тяжелые выборки в нескольких таблицах (выбрать все фотки, все статусы и т.п.)
• Требуется дополнительная сортировка и агрегирование данных на стороне системы (а не СУБД)
• Кеширование будет неоправданным, т.к. сделает ленту неактуальной
• Решение не масштабируется (не возможен шардинг)

Проведем небольшой анализ:

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

Архитектурное решение

Для начала уйдем от необходимости собирать все события с разных таблиц. Создадим одну таблицу типа “обновления” и будем складывать туда все события с такой информацией:

• кто совершил действие (автор)
• время действия
• доп. данные о действии (напр., список загруженных фоток)

Для генерации ленты обновлений нам нужно выбрать из этой таблицы все действия, совершенные друзьями пользователя:

SELECT * FROM updates WHERE user_id IN (1,2,3,4) ORDER BY time DESC

Тут 1,2,3,4 - это ID друзей пользователя

Уже лучше. Сортировку можно делать прямо на стороне СУБД, не нужно делать дополнительную агрегацию. Но остаются следующие проблемы:

• Таблица не шардится (ее невозможно разделить по какому-либо критерию для горизонтального масштабирования ввиду неопределенности списков друзей)
• Учитывая возможный большой размер таблицы, запросы к ней могут быть очень медленными
• Если понадобится учитывать приватность сообщений, запросы будут крайне тяжелыми

Опять не подойдет, думаем дальше:

Генерация пользовательской ленты

Необходимо устранить всякую записимость генерации ленты от количества данных и сложности функционала. Это возможно только тогда, когда мы для каждого пользователя генерируем ленту на лету. Т.е. при очередном событии делаем следующее:

1. Выбераем список друзей пользователя
2. Проверяем правила приватности для каждого из них
3. Вставляем событие в персональную ленту тем, кому нужно

В этом случае мы избавляемся от проблемы медленной генерации ленты, т.к. ее теперь не нужно генерировать. Мы просто читаем ее из СУБД (элементарный запрос, никаких преобразований). Самое важное - пользовательская лента теперь на 100% персональная (из нее даже можно что-нибудь удалить, не затронув остальных пользователей).

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

1. Пользователь загружает фотку
2. Обрабатываем его запрос, сохраняем фото и отправляем пользователю ответ
3. В фоне (асинхронно) выполняем обработку события и обновляем ленты его друзей

Платформа

Для управления лентами нам понадобятся простые операции работы со списками: добавить/удалить элемент, сортировка и возможно фильтрация.
Понятно, что использовать тяжелую СУБД, такую как MySQL, нецелесообразно для таких простых операций. Очень хорошо в этом случае подойдет, например, Redis или же MongoDB.

В этом примере мы рассмотрим реализацию на основе MongoDB. Для хранения ленты будем использовать внутренний массив документа. В качестве клиентской реализации используем PHPMongo.

Для выполнения задач на фоне можно использовать любую удобную систему очередей (например, RabbitMQ).

Пример

Для начала опишем главную функцию - вывод ленты обновлений (функцию get_feed() опишем позже):

<?
# Получаем ленту
# $user_id содержит идентификатор текущего пользователя
$feed = get_feed($user_id);

echo "<h3>Что делают Ваши друзья</h3>";

# Выводим все события из ленты
foreach ( $feed as $feed_item )
{
	# Время, имя пользователя и текст события
	echo "{$feed_item['time']} :: {$feed_item['user_name']} {$feed_item['text']}<br />";
}

Обновление ленты

Теперь посмотрим, как будет выглядет типичное действие, которое обновляет ленты друзей пользователя. Например, пользователь меняет свой статус. Обработчик будет выглядеть следующим образом:

<?
$status = $_POST['status'];

# коннектимся к Mongo (по умолчанию - localhost:27017)
$m = new Mongo();

# Обновляем статус пользователя (БД user, коллекция status)
# "'upsert' => true" - вставить запись, если ее нет
$m->user->status->update(
	array('user_id' => $user_id),
	array('$set' => array('status' => $status)),
	array('upsert' => true)
);

# Регистрируем событие для лент (реализация дальше)
update_feed($user_id, 'обновил статус: ' . $status );

Регистрация события

В предыдущем кусочке кода функция update_feed() регистрировала событие для добавления в ленты друзей. Реализация этой функции будет следующая:

<?
function update_feed($user_id, $text )
{
	# Получаем список друзей пользователя
	$friends = get_friends($user_id);

	$m = new Mongo();	

	# Вставляем событие каждому другу в ленту
	foreach ( $friends as $id )
	{
		# Получаем имя друга
		$user_name = get_user_name($id);

		# $data = array(
			'time' => date('H:i (m.d)'),
			'user_name' => $user_name,
			'text' => $text
		);

		# Вставляем событие в массив Mongo-объекта "list"
		# БД user, коллекция feed
		$m->user->feed->update(
			array('user_id' => $user_id),
			array('$push' => array('list' => $data)),
			array('upsert' => true)
		);
	}
}

Чтение ленты

Осталось описать функцию чтения ленты для пользователя:

<?
function get_feed($user_id)
{
	$m = new Mongo();	

	# Выбираем события из БД
	$data = $m->user->feed->findOne( array('user_id' => $user_id) );

	return $data['list'];
}

Некоторые замечания

Нужно следить, чтобы количество элементов в массиве не росло очень сильно (например, сотни тысяч), иначе объекты будут очень тяжелыми. Массивы необходимо периодически обрезать (пока в MongoDB нет удобного механизма это делать - надеюсь, появится).

Для реализации приватности необходимо в функцию update_feed() добавить функционал по проверке прав доступа для каждого пользователя.

В MongoDB пока довольно ограниченный набор функционала с вложенными массивами, поэтому фильтрацию ленты (если понадобится) придется делать на стороне PHP. Будем следить за развитием MongoDB.

Не забудьте поставить индексы на колонки по которым делаете выборки в Mongo (как это делать?).

Related posts:

1. Полнотекстовый поиск в MongoDB используя Sphinx
2. Твиттер на основе MemcacheDB и PHP
3. PHP + Redis платформа “Ключ=Значение”

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

Зачем нужно кешировать страницы?

Довольно детально принципы кеширования страниц и блоков были рассмотрены в предыдущей статье (Varnish + ESI).

В качестве краткого повторения, несколько основных идей и преимуществ кеширования на уровне странц:

• Кешируя страницы на отдающем сервере, Вы освобождаете ощутимое количество ресурсов на бекендах
• В случае медленных страниц, значительно уменьшается время ожидания страниц Вашего сайта (ускоряется его работа)
• Как показывает практика, во многих случаях внедрять систему кеширования странц в готовый проект легче, чем систему кеширования запросов

Nginx и memcached

Nginx позволяет читать данные из Мemcached - для этого Вам необходим модуль HttpMemcachedModule.

Самый простой пример - проверяем есть ли страница в кеше и, если есть, достаем из кеша, иначе - делаем запрос к бекенду.

server {
  location / {
    set $memcached_key $uri; # Ключ для проверки в memcached
    memcached_pass     127.0.0.1:11211; # Параметры подключения
    default_type       text/html; # Заголовок по умолчанию
    error_page         404 = @fallback; # 404 - данные в кеше не найдены
  }

  location @fallback {
    proxy_pass backend; # Бекенд
  }
}

В данный момент Nginx не умеет сохранять значения в memcached - только читать данные. Значит задача по сохранению страниц в кеш ложится на бекенд. Выглядит это приблизительно так (PHP):

<?
$memcache = new Memcache();
# какой-то код

ob_start();
# визуализация страницы - html
$html = ob_get_clean();

$memcache->set($_SERVER['REQUEST_URI'], $html);
echo $html;
?>

Кеширование блоков и SSI

Если у Вас не самый примитивный сайт (а он у Вас не такой), логика кеширования страниц будет несколько усложнена различными динамическими элементами страницы (блок авторизации, динамическое меню и т.п.). Подобные задачи решаются c помощью SSI - server side includes. Кроме всего прочего использование SSI экономит память, т.к. для каждой страницы Вы не будете хранить ее исходник целиком, а только внутреннюю (изменяемую) часть.

Синтаксис SSI очень простой и выглядит так:

<!--# include virtual="/authentication.php" -->

Следует отметить, что SSI - это уровень Web сервера. Для прилжения этот механизм полностью прозрачен. В приведенном примере, на месте вызова SSI, Web сервер (nginx) просто сделает еще один запрос к бекенду. Например, если у Вас два SSI вызова на страницу, то клиентский запрос к каждой странице будет генерировать три запроса к бекенду. Конечно, само по себе это бессмысленно, но в связке с кешированием представляет из себя мощный инструмент оптимизации систем.

Практический пример

Теперь соберем все выше изложенное в последовательный рецепт решения рассматриваемой задачи.

Для начала Вам необходимо выделить блоки в Вашем базовом (глобальном) шаблоне и заменить их вызовами SSI. Пример на PHP:

<html>
<body>

<h1>Тестируем nginx + memcached + ssi</h1>

<div class="auth">

<!--# include virtual="/authentication.php" -->
</div>


<!--# include virtual="/somepage.php" -->

</body>
</html>

Как видно, на странице есть два блока - блок авторизации и контентный блок (содержимое странички). В нашем примере блок авторизации будет персональным (допустим, после входа, там будет имя пользователя). Блок содержимого не будет персональным (т.е. он будет общим для всех пользователей).

Теперь необходимо настроить nginx для обработки SSI вызовов и использованию memcached:

# Upstream бекенда
upstream backend {
    server 127.0.0.1:8081;
}

server {
	listen 80;
	server_name test.com;

	root /var/www/test;
	index index.php;

	location / {
		# Все POST запросы отправляем на бекенд (не кешируя)
		if ($request_method = POST) {
			proxy_pass http://backend;
			break;
	        }

		# Включаем обработку SSI
		ssi on;
		default_type text/html;

		# Проверяем в мемкеше
		set $memcached_key "$uri";
		memcached_pass localhost:11211;
		proxy_intercept_errors  on;
		error_page 404 502 = @process;
	}

	# Сюда запрос приходит, если его небыло в кеше
	location @process
	{
		proxy_pass http://backend;
		ssi on;
	}
}

# Обычный бекенд
server {
	listen 8081;

	location ~* \.(php)$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /var/www/test$fastcgi_script_name;
    }
}

Следующим шагом в приложении необходимо будет реализовать сохранение исходников страниц в memcached.

Кеширование персонализированных блоков

Ясно, что для кеширования персонализированных блоков необходимо добавить идентификатор пользователя (не вздумайте использовать внутренний ID пользователя) в ключ memcached. SSI вызов необходимо пометить, чтобы отличать персональные блоки от общих. Т.е. персональный вызов SSI будет иметь такой вид:

<!--# include virtual="/uid/authentication.php" -->
</div>

Для генерации memcached ключей с идентификатором пользователя можно использовать куки (устанавливать его будет приложение при авторизации пользователя):

set $memcached_key "$uri:$cookie_uid";

Соответственно, необходимо в nginx добавить обработчик для “/uid” запросов:

        location /uid {
                ssi on;
                default_type text/html;

                set $memcached_key "$uri:$cookie_uid";
                memcached_pass localhost:11211;
                proxy_intercept_errors  on;
                error_page 404 502 = @process;
        }

Естественно, в самом приложении все “/uid” запросы должны кешироваться с идентификатором пользователя:

$m->set($_SERVER['REQUEST_URI'] . ':' . $_COOKIE['uid'], $html);

Следует обратить внимание

Недавно появился продукт, который должен стать типичным решением при кешировании страниц - Twicecache. Пока он на очень ранней стадии и доступны только его исходники. Будем внимательно следить.

Related posts:

1. Кеширование страниц - ускоряем сайт в 100 раз (Varnish + ESI)
2. Настройка nginx
3. Ресайзинг картинок в nginx

Особенности sysbench

Из преимуществ этого продукта следует отметить его простоту, гибкость, а также:

• Кроссплатформенность
• Мультипоточность
• Набор тестов для параметров уровня ОС (память, файловая система, процессор и т.п.)

Другими словами эта утилита нужна для решения следующих задач:

• Тестирование параметры ОС (даже без установки СУБД) для предварительной их оценки и последующей настройке
• Проверка производительности СУБД с различной конфигурацией и нагрузкой

Установка

Эта популярная утилита присутствует в пакетах многих дистрибутивов, поэтому:

sudo apt-get install sysbench

Или собираем из исходников (скачать можно тут):

./configure
make
make install

После этого утилита готова к работе.

Обзор функциональности

Синтаксис вызова утилиты:

sysbench --test=имя-теста [опции] команда

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

• prepare - подготовка теста (создание таблиц, вставка данных и т.п.) если актуально
• run - выполнение теста
• cleanup - очистка данных (после этапа подготовки)
• help - выводит дополнительные параметры теста

Параметр “–test” задает имя теста, который следует выполнять. Sysbench включает в себя несколько тестов:

cpu

Этот тест проверит производительность процессоров, используя вычисления с 64-разрядными числами. Например:

sysbench --test=cpu --cpu-max-prime=20000 run

memory

Этот тест служит для измерения производительности последовательных операций чтения/записи в оперативную память.

fileio

Этот тест используется для симуляции разнообразной нагрузки на файловую подсистему. При подготовке теста создается определенное количество файлов (указанного размера). Затем, при выполнении теста, над этими файлами происходят операции чтения/записи в несколько потоков.

sysbench --num-threads=16 --test=fileio --file-total-size=3G --file-test-mode=rndrw prepare
sysbench --num-threads=16 --test=fileio --file-total-size=3G --file-test-mode=rndrw run
sysbench --num-threads=16 --test=fileio --file-total-size=3G --file-test-mode=rndrw cleanup

threads

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

sysbench --num-threads=64 --test=threads --thread-yields=100 --thread-locks=2 run

oltp (Online transaction processing)

Этот тест служит для оценки производительности СУБД, о нем подробнее дальше:

OLTP тестирование - производительность MySQL

Этот тест проводится в несколько этапов. На этапе prepare

sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=10000 --mysql-user=root --mysql-password=root --db-driver=mysql --test=oltp prepare

Эта операция создаст innoDB таблицу на 10000 записей. По умолчанию таблица создается в базе данных sbtest (не забудьте создать эту БД либо указать другую).

Далее выполняются тесты:

sysbench --num-threads=8 --max-requests=500 --oltp-table-size=10000 --mysql-user=root --mysql-password=root --db-driver=mysql --test=oltp run

Эта команда выполнит тест с 8 клиентами (максимальное количество запросов - 500) на таблице, которая была создана на предыдущем этапе. После окончания теста не забудьте выполнить команду cleanup. После выполнения Вы увидите подробные результаты тестирования. Далее - живой пример.

Пример

Посмотрим на производительность innoDB таблицы с разными значениями конфигурационных параметров (проведем эксперимент со сбросом лога). Для начала подготовим innoDB таблицу (50 тыс. записей):

sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=50000 --mysql-user=root --mysql-password=root --db-driver=mysql --test=oltp prepare

.

Включим сброс лога на диск после каждой транзакции (используем стандартный метод сброса лога):

innodb_flush_log_at_trx_commit = 1
innodb_flush_method=fdatasync

Выполним тест:

sysbench --num-threads=8 --max-requests=1000 --oltp-table-size=50000 --mysql-user=root --mysql-password=root --db-driver=mysql --test=oltp run

И увидим следующие результаты:

OLTP test statistics:
    queries performed:
        read:                            14000
        write:                           5000
        other:                           2000
        total:                           21000
    transactions:                        1000   (263.49 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 19000  (5006.24 per sec.)
    other operations:                    2000   (526.97 per sec.)

Test execution summary:
    total time:                          3.7953s
    total number of events:              1000
    total time taken by event execution: 30.2361
    per-request statistics:
         min:                                  4.80ms
         avg:                                 30.24ms
         max:                                 53.01ms
         approx.  95 percentile:              33.07ms

Threads fairness:
    events (avg/stddev):           125.0000/0.00
    execution time (avg/stddev):   3.7795/0.01

Убедимя, что пропускная способность операций чтения/записи около 5 тыс в секунду. Теперь изменим параметры сброса лога:

innodb_flush_log_at_trx_commit = 0
innodb_flush_method=O_DIRECT

и проверим результаты:

OLTP test statistics:
    queries performed:
        read:                            14000
        write:                           5000
        other:                           2000
        total:                           21000
    transactions:                        1000   (485.37 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 19000  (9222.00 per sec.)
    other operations:                    2000   (970.74 per sec.)

Test execution summary:
    total time:                          2.0603s
    total number of events:              1000
    total time taken by event execution: 16.4255
    per-request statistics:
         min:                                  2.69ms
         avg:                                 16.43ms
         max:                                235.49ms
         approx.  95 percentile:              42.15ms

Threads fairness:
    events (avg/stddev):           125.0000/6.16
    execution time (avg/stddev):   2.0532/0.00

Убеждаемся, что во втором случае пропускная способность СУБД вдвое выше, чем в первом (о параметрах подробнее в статье Оптимальная настройка Mysql сервера).

Альтернативные утилиты

Кроме Sysbench, есть еще ряд инструментов, на который следует обратить внимание:

• MySQL Benchmark Suite (“sql-bench”) - входит в стандартную поставку MySQL (Perl)
• Super Smack - утилита для стресс тестирования/генерации нагрузки для MySQL
• Mybench - маленькая и простая утилита для тестирования производительности (Perl)

Ссылки

Официальный сайт Sysbench

Related posts:

1. Mongo DB - документо-ориентированная база данных и MySQL
2. check-unused-keys - проверка неиспользуемых индексов в MySQL
3. Maatkit - расширенные возможности MySQL

Одним из основных принципов разработки масштабируемых и эффективных приложений является выбор подходящих технологий для решения той или иной задачи. Многие современные РСУБД представляют из себя решения универсальные, но во многих случаях в них просто нет необходимости.

Одним из альтернативных решений для хранения и обработки данных является СУБД Mongo DB (”humongous” - огромный, невероятный).

Что такое Mongo DB?

Mongo DB - высокопроизводительная документо-ориентированная база данных. Особенности этой СУБД:

• Документное хранилище, не требующее создания схем (таблиц)
• Запросы в стиле JSON (очень удобно)
• Широкий набор (атомарных) операций над данными (условный поиск, сложная вставка/обновление и т.п.)
• Разные типы данных (поддержка массивов)
• Поддержка индексов (B-Tree)
• Автовосстановление, шардинг и репликация в коробке
• Профилирование, хранение больших объектов, административный интерфейс, серверные функции, Map/Reduce и многое другое

Mongo DB и MySQL

Многое из вышеперечисленного есть и в решениях более знакомых, таких, как MySQL. Давайте сравнивать:

Итак преимущества Mongo:

• Объектный язык запросов (который намного легче SQL, что является важным преимуществом для большинства задач, не требующих сложных выборок)
• Поддержка Map/Reduce для распределенных операций над данным
• Документы, не требующие определения схемы. Одно из самых важных преимуществ. Преимущество заключается в том, что у Вас нет нужды хранить пустые ячейки данных в каждом документе.
• Поддержка сложных массивов. Каждый элемент массива может представлять из себя объект
• Поддержка шардинга на уровне платформы

Производительность

Для тестирования возьмем таблицу в MySQL (messages) с простой структурой (таблица личных сообщений пользователей одного из моих проектов). Количество записей в ней - около 200 тыс. Все данные скопированны в mongo с соотв. индексами.

Для тестирования будем использовать следующий скрипт:

<?php
$m = new Mongo();
$col = $m->messages->threads;

$s = microtime(true);
for ( $i = 0; $i < 5000; $i++ )
        $cursor = $col->find( array('user_id' => $i) );

$t = microtime(true) - $s;

echo "Mongo: " .  $t . "\n\n";

mysql_connect('localhost');
mysql_select_db('messages');

$s = microtime(true);
for ( $i = 0; $i < 5000; $i++ )
        mysql_query('SELECT id FROM messages WHERE mailed_by = ' . $i);
$t = microtime(true) - $s;

echo 'MySQL: ' . $t . "\n\n";

Как видно из скрипта, мы сделали по 5000 выборок из обеих СУБД. Поля, по которым проходила выборка являются индексными. Ниже приведены результаты второго запуска скрипта (в первый раз значения были гораздо большими, т.к. таблицы не были подтянуты в память):

Mongo: 0.010502815246582
MySQL: 0.27930092811584

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

Когда выбирать Mongo DB, а когда MySQL?

Mongo представляет из себя очень функциональное решение, тем не менее обладает рядом ограничений. Например, возможность сделать JOIN (а нужен ли он?). Также язык запросов Mongo конечно устапает SQL в гибкосте и возможностях. Но нужна ли Вам эта гибкость в Ваших задачах? Одним словом, Mongo подходит почти под любой класс задач, не требующих сложных выборок.

Что же касается MySQL (или родственных продуктов), то он остается решением для задач требующих нетривиальных выборок (например, статистические или аналитически запросы).

Личное впечатление

После первого знакомства с Mongo DB, этот продукт оставил очень хорошее впечатление и заставил вернуться к нему еще раз. Помимо прочих преимуществ:

• Очень легкий и интуитивно понятный
• Простая установка, все заработало с первого раза
• Отличная документация, хорошее сообщество
• Множество клиентских разработок, в т.ч. под PHP

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

Совсем недавно мы переписали несколько фукнциональных частей проекта на Mongo. В процессе работы проблем почти не возникало, за исключением некоторых:

• Mongo строго типизирован и не приводит типы автоматически (такой возможности впринципе нет, учитывая отсуствие каких-либо метаданных о коллекциях и документах). Поэтому в динамически типизированном PHP приходится приводить данные к нужным типам (например, когда они приходят из формы).
• Не хватило возможностей для работы с массивами, что немного сбило с толку. С одной стороны - вложенные массивы - очень удобная вещь, с другой стороны - нет таких штук, как их фильтрация или сортировка. Надеюсь все это будет вскоре, хотя сейчас есть возможность реализовать это с помощью серверных функций.

Интересно узнать мнение и опыт читателей, кто использовал или знаком с MongoDB.

Related posts:

1. Sysbench - тестируем производительность MySQL и платформы
2. Maatkit - расширенные возможности MySQL
3. check-unused-keys - проверка неиспользуемых индексов в MySQL