Приглашаю на семинар по Интернет-бизнесу |
Дорогие читатели Highload. Приглашаю вас 12 мая на семинар по Интернет-бизнесу. Который проведу вместе со своими коллегами в Киеве.
На семинаре мы расскажем как построить успешную Интернет-компанию.
Обещаю только практические примеры и много полезной информации по вопросам:
Посмотреть детали и записаться
Проекты, которые подняли своими усилиями:
Connect.ua, Plirt.ru, Flirchi.ru
Суммарное количество показов страниц в месяц на сайтах Connect.ua, Plirt.ru, Flirchi.ru превышает 300 000 000. Это в 2 раза больше, чем на i.ua, почти в 4 раза больше, чем на bigmir.net и всего в 4 раза меньше, чем на yandex.ua.
Вывели компанию на прибыльность 2 года назад. И каждый месяц добиваемся новых высот. Про это и расскажем на семинаре
Читателям Highload скидка.
|
Используем Nginx, как кеширующий сервер |
В этой статье рассмотрим применениt Nginxa в качестве кеширующего сервера. Подробно о HTTP кеширования написано в статьях о продвинутом кеширующем сервере Varnish. Сразу следует отметить, что Nginx полностью не заменяет Varnish по функционалу и возможностям, но тем не менее продставляет очень хорошое решение. Учитывая великолепную работу этого Web-сервера, наличие функциональности кеширования делает возможным подключить ее к своему сайту буквально за 2 минуты.
|
Sphinx RT (real-time) индексы |
Sphinx 1.10 поддерживает индексы реального времени (Reat-time или RT). Это самая важная функция в новой версии этого отличного полнотекстового поисковика. Индексы реального времени позволяют синхронно добавлять документы для поиска в индекс. Это позволяет избежать задержки появления новых документов в результатах поиска. Пробуем RT индексы на практике.
|
Используем Nginx как “long polling” (Comet) сервер |
Принцип Long Polling (или Comet) позволяет сделать возможным установление постоянного соединения клиента с Web приложением и также периодичной отправки данных клиенту в рамках этого соединения (без необходимости клиента постоянно делать HTTP запросы для проверки новых данных). Другими словами, эта модель позволяет реализовать постоянные HTTP соединения для получения данных порциями. Наиболее популярное применение - чаты, твиттеры и другие live-updated потоки - клиент постоянно слушает сервер на предмет появления новых сообщений, и как только новые сообщения появляются - они мгновенно доставляются ему.
Сам принцип не несет в себе инноваций в HTTP протоколе, т.к. этот подход реализуем обычными средствами. Проблема заключается в том, что стандартное решение - установка постоянного соединения с обычным Web сервером (а значит и с обслуживающей платформой, например php-бекендом) - крайне ресурсоемкое и не применимо на практике. Другой подход - постоянно опрашивать приложение на предмет появления новых данных является еще более ресурсоемким.
Решением этой проблеммы стали т.н. HTTP-PUSH (или comet) сервера, позволяющие облуживать огромное количество постоянных соединений эффективно расходуя ресурсы. Как они устроены и как применяются на практике?
Необходимо отметить, что Comet сервер решает задачу отправки клиенту определенных данных порциями. Comet сервера реализуют т.н. HTTP Push Relay протокол (например, Basic HTTP Push Relay Protocol). Принцип работы такого протокола заключается в следующем:
Таким образом, сервер реализует стэки сообещений, а их раздача происходит без участия тяжелых бекендов. Бекенды вступают в силу только тогда, когда необходимо отправить сообщение.
Модуль 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
Для базовой конфигурации нам необходимо объявить две рабочих точки в Nginxe: точка публикации сообщений (приватная - доступна только для самого приложения) и точка раздачи сообщений (публичная - к которой будут подключаться клиенты):
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-серверами?
|
NoSQL - подходы к решению типичных задач |
Врядли сегодня найдется тот, кто еще не слышал про key-value базы данных, или как их называют в народе NoSQL. Те, кто успел попробовать продукты вроде Redis, MemcacheDB и других, обнаружили некторые сложности при решении привычных задач - выборка списков и поиск.
В этой статье мы рассмотрим принципы решения типичных задач в key-value базах данных.
|
Полнотекстовый поиск в MongoDB используя Sphinx |
Многие из тех, кто успел попробовать MongoDB в действии, столкнулись с трудностями с полнотекстовым поиском. Встроенный механизм полнотекстового поиска в MongoDB (его так можно назвать с большой натяжкой) не пригоден для реальных потребностей.
Основная проблема заключается в том, что sphinx не позволяет использовать буквенно-цифровые значения в качестве ID документов. Есть несколько вариантов решения этой проблемы.
|
memcache vs memached - сравниваем клиенты для PHP |
Какой клиент лучше использовать при разработке на PHP - php-memcached или php-memcache? Все зависит от того, какие особенности Вам нужны (неужели?). Давайте сравним в двух аспектах - функциональность и производительность.
|
Делаем ленту обновлений на MongoDB + PHP |
Вы, конечно, много раз видели ленту обновлений на фейсбуке и твиттере. В двух словах - это список событий, которые произошли недвано на сайте и касаются Вас (чаще всего это деятельность Ваших друзей). Это очень удобный инструмент информирования пользователей и неотъемлемая часть современных социальных проектов. А как обстоит дело с реализацией?
На первый взгляд все очень просто, а на практике все сложно. Давайте разберемся детально (на примере MongoDB + PHP, заодно посмотрим на эту новую шумную СУБД).
|
Sysbench - тестируем производительность MySQL и платформы |
Sysbench - утилита для тестирования производительности MySQL (и других СУБД), а также параметров операционной системы. Подобный инструмент незаменим для предварительного тестирования эффективности системы с (потенциально) высокой нагрузкой. Sysbench позволяет оценить производительность сервера СУБД и операционной системы в различных условиях при различной нагрузке.
|
Mongo DB - документо-ориентированная база данных и MySQL |
Одним из основных принципов разработки масштабируемых и эффективных приложений является выбор подходящих технологий для решения той или иной задачи. Многие современные РСУБД представляют из себя решения универсальные, но во многих случаях в них просто нет необходимости.
Одним из альтернативных решений для хранения и обработки данных является СУБД Mongo DB (humongous - огромный, невероятный).
|