Особенности 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

Основные возможности

• Полная поддержка Redis 1.2.1 API. Список обновлений, доступный в новой версии.
• Работа с несколькими серверами
• Несколько алгоритмов “размазывания” ключей по серверам: “consistent hashing” и crc32. Причем подключить свой не составит труда.
• Работа с ключами как с объектами
• Работа с списками и “сетами”, как с обычными PHP массивами
• Pipelining - быстрая отправка серии команд на сервер.
• Простое и удобное расширение Редиски - добавление, удаление и замена команд.
• Lazy loading (”Ленивая загрузка”) - загрузка функцинала Редиски по требованию.
• Полная интеграция с Zend Framework
• Исчерпывающая документация.

Скоро

• Теги - получения списка и удаление ключей по тегу.
• Поддержка Ketama - быстрой consistent hashing библиотеки.
• Оптимизация производительности.
• Интеграция с другими фреймворками.
• Учебное приложение - реальное приложение написанное с использованием Rediska с подробными комментариями.

Примеры работы

Создаем ключ на 2 минуты и сохраняем значение, если пусто:

<?php
// инциализация ключа
require_once 'Rediska/Key.php';
$key = new Rediska_Key('keyName', 60 * 2);

// старый способ
$value = $key->getValue();
if ($value === null) {
   $value = $exampleObject->getNewValue();
   $key->setValue($value);
}

// новый способ
$value = $key->getOrSetValue($exampleObject)->getNewValue();
?>

Работаем со списком:

<?php
// инициализация списка
require_once 'Rediska/Key/List.php';
$list = new Rediska_Key_List('list');

// добавляем новые элементы
$list[] = 'first element';
$list[] = 'second element';

// получаем элемент
echo $list[1]; #=> 'second element';

// Заменяем элемент
$list[0] = 'new first element';

// Получаем количество элментов
echo count($list); #=> 2

// Проверяем установлен ли элемент с указанным индексом
echo isset($list[0]); #=> true

// Итерация списка
foreach($list as $element) {
   echo $element;
}
?>

Работа с “пайплайнами” и выполнение команд на указанном сервере:

<?php
// инициализация
$options = array(
   'namespace' => 'MyApplication_',
	'servers' => array(
       'exapmleAlias' => array('host' => '127.0.0.1'),
	    array('host' => '127.0.0.1', 'port' => 6380)
	)
);
require_once 'Rediska.php';
$rediska = new Rediska($options);

// создать ключ на сервере "exampleAlias"
$rediska->on('exampleAlias')->set('a', 'b');

// выполяем серию команд в "пайплайне"
$result = $rediska->pipeline()->set('a', 1)
                                          ->increment('a', 10)
                                          ->rename('a', 'b')
                                          ->get('a')
                                          ->execute(); // выполнить команды и вернуть ответы
?>

Более подробную информацию и примеры читайте в документации.

Rediska - открытый проект: вы можете поучаствовать в разработке или стать автором интеграции с любимым фреймворком. Контакты авторов вы найдете на сайте проекта.

За обзорную статью большое спасибо Ивану Шумкову - создателю клиента Rediska.

Related posts:

1. Redis
2. PHP + Redis платформа “Ключ=Значение”

В этой статье поговорим о кешировании страниц и их частей, а также о том, какие плюсы это дает.

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

В этой статье речь пойдет о том, как кешировать страницы с персональными данными используя Varnish и язык ESI.

ESI

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

<HTML>
<BODY>

Всем привет!

<esi:include src="/news.php?UID"/>

Всем пока!!!

</BODY>
</HTML>

Веб сервер, поддерживаюий ESI вызовы, встретив ESI вызов, просто сделает дополнительный запрос, а результат вставит на его место. Допустим наш скрипт “news.php” содержит такой код:

<?
echo "<ul><li>News title 1</li></ul>";

После обработки первого примера, клиенту вернется такая страница:

<HTML>
<BODY>

Всем привет!

<ul><li>News title 1</li></ul>

Всем пока!!!

</BODY>
</HTML>

Зачем это нужно, если это только увеличивает количество запросов к серверу?
Все просто, если использовать кеширование - у Вас появляется удобное средство кешировать различные куски страниц (с разной логикой и временем жизни кеша). В нашем примере мы могли бы, например, закешировать главную страницу на 1 день, а скрипт новостей на 1 час. Тогда в сутки мы бы получали только 25 запросов к PHP. Это позволило бы значительно разгрузить бекенд, а также увеличить скорость загрузки страниц.

Как все работает?

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

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

Обратите внимание, что один запрос генерирует еще 3 запроса к бекенду (т.к. у нас три ESI вызова на странице). После первого запроса все части закешировались, и теперь (при последующих запросах) картинка будет выглядеть так:

Как видите, второй запрос (и каждый последующий) не вызвали обращений к бекенду, а все нужные куски страниц были отданы из кеша.

Что необходимо сделать, чтобы все это заработало:

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

Персональные данные

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

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

Пример

Для примера возьмем такую задачу. У нас есть сайт с новостями. Новости обновляются каждый час. На сайте также есть блок авторизации и скрытые ссылки для авторизированных пользователей. Исходя из этого логическое разбиение на блоки будет следующим:

• Блок авторизации
• Меню
• Блок новостей

Исходный код стартовой страницы:

<HTML>
<BODY>

<h1>Тестируем ESI</h1>

<esi:include src="/app/auth.php?UID"/>
<esi:include src="/app/menu.php?AUTH"/>

<h3>Новости</h3>
<esi:include src="/app/news.php"/>

</BODY>
</HTML>

Все скрипты для ESI вызовов будут находиться в папке app. Их исходники:

Скрипты бекенда

Скрипт авторизации

<?

session_start();

if ( $_POST['user'] )
{
	$_SESSION['user'] = $_POST['user'];
	header('Location: /'); exit;
}

$user = $_SESSION['user'];

?>

<? if ( $user ) { ?>
	<div>Привет, <b><?=$user?></b>!</div>
<? } else { ?>
	<form method="post" action="/app/auth.php">
		Войдите в систему
		<input type="text" name="user" />
		<input type="submit" name="Войти">
	</form>
<? } ?>

Скрипт меню

<? session_start(); ?>

<ul>
	<? if ( $_SESSION['user'] ) { ?>
		<li><a href="#">Пункт меню только для пользователей</a></li>
	<? } ?>
	<li><a href="#">Публичный пункт меню</a></li>
</ul>

Скрипт новостей

<?

$rss = file_get_contents('http://feeds.nytimes.com/nyt/rss/HomePage');
$xml = simplexml_load_string($rss);

echo "<ul>";
foreach ( $xml->channel->item as $item )
{
	echo "<li><a href=\"{$item->link}\">{$item->title}</a>";
}
echo "</ul>";

Вся логика крайне упрощена, но тем не менее сохраняет суть стандартных задач подобного рода.

Настройка Nginx

Для обслуживания будем использовать Nginx. Конфигурация включает два виртуальных сервера. Первый (80 порт) принимает и обрабатывает запросы от клиента. Все запросы проксирует на Varnish. Второй сервер (порт 8090) нужен для запросов от Varnish’a:

server {
    listen 80;
    server_name esi.dev;
}

server {
    listen 8090;

    root /home/golotyuk/www/localhost/esi;

    # Если включен gzip, обязательно нужно выключить!
    gzip off;

    location / {
        index index.php;
    }

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

Настройка varnish + esi

Перед конфигурацией varnish’a определяем логику кеширования:

• Главную страницу кешируем на 24 часа, блоки - на 1 час
• Кешировать будем все запросы кроме POST
• Для кеширования персонального блока будем использовать значение сессионных cookie (PHPSESSID) - для установки ключа кеширования
• Для разделения персонализированных блоков от обычных блоков для авторизированных пользователей будем использовать соотв. приставки к запросам: UID (персонализированные блоки) и AUTH (обычные блоки, учитывающие только статус пользователя)

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

# Бекенд сервер - виртуальный сервер Nginx
backend default { .host = "127.0.0.1"; .port = "8090"; }

# Процедура формирования ключа для кеширования
sub vcl_hash {
       # Стандартные параметры - имя сервера и URL
        set req.hash += req.url;
        set req.hash += req.http.host;

       # Если установлена сессионная кука, сохраняем ее значение в переменную
        if( req.http.cookie ~ "PHPSESSID" ) {
            set req.http.X-Varnish-Hashed-On =
                regsub( req.http.cookie, "^.*?PHPSESSID=([^;]*?);*.*$", "\1" );
        }

        # Если в строке запроса мы находим "UID", то необходимо добавить
        # значение сессии в параметры кеширования
        if( req.url ~ "/app/.*UID" && req.http.X-Varnish-Hashed-On ) {
             set req.hash += req.http.X-Varnish-Hashed-On;
        }

        # Если в строке запроса мы находим "AUTH", то необходимо добавить
        # флаг статуса (logged in) в параметры кеширования
        if( req.url ~ "/app/.*AUTH" && req.http.X-Varnish-Hashed-On ) {
            set req.hash += "logged in";
        }

        hash;
}

sub vcl_recv {
        # Если тип запрос не POST, то ищем объект в кеше
        if ( req.request != "POST" )
        {
                lookup;
        }
}

sub vcl_fetch {
    # Для запроса "/" используем обработку esi и кешируем на 1 сутки
    if (req.url == "/") {
        esi;
        set obj.ttl = 24h;
    }
    # Для запросов "/app" (ESI вызовы) кешируем результат на 1 час
    elseif (req.url ~ "^/app/") {
        set obj.ttl = 1h;
    }

    deliver;
}

После конфигурации и запуска, получим приблизительно следующее:

Для анализа производительности воспользуемся утилитой ab (из пакета apache2-utils):

ab -n 100 -c 5 http://esi.dev/

Результат:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:     2    5   3.8      3      18
Waiting:        2    5   3.8      3      18
Total:          2    5   3.8      4      19

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      5
  80%      8
  90%     12
  95%     15
  98%     17
  99%     19
 100%     19 (longest request)

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

ab -n 100 -c 5 http://127.0.0.1:8090/index_standard.php

Результаты:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   354  579 666.2    458    5484
Waiting:      354  579 666.2    458    5483
Total:        354  579 666.2    458    5484

Percentage of the requests served within a certain time (ms)
  50%    458
  66%    492
  75%    517
  80%    539
  90%    602
  95%    667
  98%   3572
  99%   5484
 100%   5484 (longest request)

Как видим скорость обслуживания отличается в 100 раз!

Возможно тесты покажуться слишком хитрыми (новости мы получаем из внешнего источника, что очень медленно). Но следует понимать, что пример содержит очень мало логики и для симуляции реального примера был использован 1 внешний запрос. По существу это тоже самое, что несколько десятков запросов к MySQL + несколько сотен запросов к memcached + логика приложения + логика отображения.

Итог

Применение принципа частичного кеширования страниц позволяет кешировать страницы с динамическими и персональными данными с нетривиальной логикой. Плюсы такого подхода:

1. Существенно увеличивается скорость отдачи страниц
2. Сильно разгружаются бекенд сервера от повторяющейся логики

Текущие проблемы

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

В качестве альтернативных решений следует привести связку Nginx + SSI + Memcache, которая будет рассмотрена в будущих статьях.

Ссылки

Описание работы ESI в Varnish
Исходники примеров

Какие еще есть решения частичного кеширования страниц?

Related posts:

1. Varnish - быстрый старт
2. Кеширование тяжелых запросов (на примере memcache)
3. Varnish

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

Hotmail представляет собой гигантскую службу во всех измерениях. Вот некоторые из основных:

• Наш сервис присутствует по всему миру. Hotmail поставляется на 59 региональных рынка, на 36 языках
• Мы предоставляем свыше 1.3 миллиарда почтовых ящиков (некоторые пользователи имеют несколько ящиков)
• Более 350 миллионов людей активно используют Hotmail ежемесячно (по данным comScore, август 2009)
• Мы обрабатываем свыше 3 миллиардов сообщений в день и фильтруем более 1 миллиарда спамерских писем
• Объем данных растет на 2 петабайта в месяц
• В настоящий момент у нас хранится свыше 155 петабайт данных(70% этого объема вложения, обычно фотографии)
• У нас крупнейшая в мире база данных SQL Server 2008, мы контролируем и управляем многими тысячами Sql серверов

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

Архитектура

Hotmail и другие сервисы Windows Live размещены в нескольких дата центрах по всему миру. Hotmail организуется в логические масштабируемые элементы – кластеры. Кроме того, у нас есть инфраструктура, которая распределяет нагрузку между кластерами в каждом дата центре:

• Сервера для обработки входящей и исходящей почты
• Спам фильтры (от переводчика: если данная статья понравится сообществу, я могу перевести блог пост о спам фильтрах в Hotmail)
• Хранилище пользовательских данных и данных полученных с наших мониторинговых систем
• Инфраструктура мониторинга и реагирования на инциденты
• Инфраструктура для управления автоматизированным развертыванием кода и настройки обновлений

На одном кластере расположено несколько миллионов пользователей (как много зависит от возраста аппаратного обеспечения) и автономный набор серверов, включая:

• Frontend серверы – серверы, которые проверяют сообщение на наличие вирусов и размещают код, который отвечает за общение с вашим браузером или почтовым клиентом, используя такие протоколы как POP3 и DeltaSync
• Backend серверы – SQL серверы, файловые серверы, фильтры спама, хранилище данных мониторинга и спам фильтров, каталог агентов и серверов, обработка входящей и исходящей почты
• Балансировщик нагрузки – аппаратное и программное обеспечение, используемое для равномерного распределения нагрузки для повышения общей производительности.

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

Вот несколько способов предотвращения сбоев:

• Избыточность – мы используем сочетание массивов хранилищ SQL Server для сохранности ваших данных. Мы пользуемся активной и пассивной отказоустойчивой технологией. Это необычный способ сказать, что у нас есть много серверов и копии ваших данных, которые постоянно синхронизируются. В целом мы храним 4 копии ваших данных на разных дисках и серверах, чтобы минимизировать вероятность потери данных в случае ошибки оборудования.
• Еще одно преимущество данной архитектуры в том, что мы можем производить плановое обслуживание, такое как развертывание обновлений или исправление безопасности, без простоя.
• Мониторинг — у нас есть разветвленная система мониторинга программного и аппаратного обеспечения. Тысячи серверов наблюдают за состоянием “здоровья” сервиса, транзакциями, общей производительностью системы. Поскольку наш сервис настолько огромен, мы отслеживаем производительность и uptime в совокупности, а также на уровне кластера и по географическому положению. Мы хотим быть уверены, что ваш персональный опыт вернется назад к нам и не потеряется, когда мы будем смотреть общие показатели системы. Мы заботимся о каждом из пользователей. В будущих постах мы поговорим больше о мониторинге и производительности.
• Группа реагирования – у нас есть круглосуточная группа реагирования, которая следит за нашей глобальной системой мониторинга и принимает меры всякий раз, когда есть проблема. У нас есть процесс расширения, которым могут заниматься наши инженеры в течение нескольких минут в случае необходимости.

Технологический процесс

Я рассказал немного о нашей архитектуре, и тех шагах, которые мы предпринимаем, чтобы обеспечить бесперебойное обслуживание. Однако наш сервис не статичен; помимо роста за счет использования, мы регулярно вносим обновления. Таким образом, наши технологические процессы также важны, как и архитектура, чтобы обеспечить вас бесперебойной услугой. Мы соблюдаем определенные меры предосторожности при развертывании нового кода, от патчей и небольших обновлений до крупных релизов.

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

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

Развертывание кода и изменение управления. У нас тысячи серверов в тестовой лаборатории, где мы развертываем и тестируем код, задолго до того, как он попадет клиенту. В дата центрах у нас так же есть кластеры, специально зарезервированные для тестирования “dogfood” и бета версий на заключительном этапе разработки. Мы проверяем все изменения в наших лабораториях, будь то обновление аппаратного или программного обеспечения, или исправление безопасности.

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

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

Заключение

Этот топик должен дать вам понимание тех масштабов разработки, которые подразумевает развитие Hotmail. Мы посвящаем себя техническому превосходству и непрерывным усовершенствованиям наших служб для вас. Мы продолжаем изучать, как растет служба, и прислушиваемся к вашим отзывам, серьезно, вы можете оставить мне здесь комментарии с вашими мыслями и вопросами. Я страстный поклонник наших сервисов, как и вся команда Windows Live – мы можем быть инженерами, но мы используем службы сами, наряду с миллионами наших пользователей.

→ Оригинал статьи / → Перевод на Хабре

No related posts.

Apache Solr - это расширяемая поисковая платформа от Apache. Система основана на библиотеке Apache Lucene и разработана на Java. Особенности ее в том, что она представляет из себя не просто техническое решение для поиска а именно платформу, поведение которой можно легко расширять/менять/настраивать под любые нужды - от обычного полнотекстового поиска на сайте до распределенной системы хранения/получения/аналитики текстовых и других данных с мощным языком запросов.

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

• Расширенные возможности полнотекстового поиска
• Оптимизирован под Web системы с большой нагрузкой
• Стандартные интерфейсы протокола - XML, JSON, HTTP
• Web панель администрирования (интерфейс для тестовых запросов, статус сервера и компонент, отладка и оптимизация анализатора…)
• JMX статистика
• Масштабирование - репликация и шардинг в составе платформы
• Огромная гибкость благодаря мощной системе конфигурации
• Расширяемость благодаря поддержке плагинов
• Индексация в реальном времени
• Текстовый анализ (разнообразные текстовые фильтры)
• Кеширование
• Мощный язык запросов (фильтры, сортировки, работа с датой/временем, функциональные запросы и многое другое)
• Готовые клиенты для множества языков разработки (в том числе PHP)
• Приблизительный поиск (неточные совпадения) и проверка запросов на ошибки (подсказки вариантов)

Lucene

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

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

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

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

No related posts.

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

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

Самое главное

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

Оборудование

Как всегда перед Вами выбор - покупать дорогой комплекс (файловый супер сервер) либо строить систему из дешевых серверов. Как всегда выбор падает на второй вариант, так как:

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

По сравнению с дорогостоящим комплексом, такое решение обладает единственным недостатком: реализацию самой подсистемы распределения файлов придется разрабатывать самим. При грамотном подходе это вовсе не большой кусок работы. На connect.ua переход на такое решение занял около недели (на тот момент у нас было 2.5 Тб данных).

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

Архитектура

Перед нами стоят следующие задачи:

• Загрузка файлов
• Траскодирование файлов
• Распредение файлов по серверам
• Выдача файлов

В общем плане схема работы подсистемы такова:

Теперь детальнее. У нас есть ряд серверов-хранилищ, каждый из которых ничего не знает о всех остальных. Все они доступны извне под определенным адресом (например, m1.connect.ua, m2.connect.ua и т.п.). После получения файла (загрузка пользователя) на бекенд, мы выбираем из набора серверов тот, на который мы сохраним файл. Выбор делается на основе предпочитаемого критерия (случано; учитывая свободное место; учитывая загрузку процессора и т.п.).

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

Репликация

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

Распределенные файловые системы

Обычно медиа-подсистемы характеризуются огромными объемами отдачи данных. Минус использования распределенных файловых систем в нашем случае в том, что Вы получаете огромный внутрисетевой трафик, и это выливается в малую эффективность при отдаче файлов. После ухода от GlusterFS на connect.ua наш исходящий медиа трафик вырос со 150 до 800 Мб/с.

Изоляция крупных и мелких файлов

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

Cloud hosting

Сегодня большую популярность набирают cloud хостинги. Это решение имеет смысл, когда Вы планируете разработать и вывести прототипное решение.

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

Какие технологии Вы используете для обмена файлами между серверами? Используете ли распределенные файловые системы?

Related posts:

1. Отдача и ресайзинг фотографий

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

Почему так происходит и что делать?

Почему баннеры делают сайт медленнее

Как обычно работают системы открутки баннерной рекламы? Зачастую это просто JavaScript код, который вставляется в нужное место на странице (туда где баннер будет). Далее по мере загрузки страницы, выполняется этот самый код, который делает запрос к баннерной системе. Далее она (баннерная система) генерирует код баннера, который и отрисовывается на страничке. Только после этого продолжается загрузка страницы.

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

Учитывая это, а также то, что баннеров на странице обычно несколько, эффект от влияния рекламы на скорость загрузки страницы может быть очень негативным.

Для оптимизации нужно сделать следующее:

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

Далее - подробнее.

Баннерные системы

В качестве системы открутки баннерной рекламы есть выбор из двух вариантов: ставить свою собственную и использовать hosted (внешнее) решение.

Ставить свою собственную систему открутки крайне не выгодно. Ни одно из современных решений не является эффективным, а проблем с производительностью будет масса. Мы когда-то использовали OpenX, которая хорошо масштабируется, но для этого ей нужны “хорошие масштабы железа”.

В качестве внешних решений, есть целый ряд предложений. Мы в качестве такого решения используем Google Ad Manager. Продукты компании Google - это хороший выбор в терминах надежности и стабильности, как и в быстродействии.


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

Отложенная загрузка баннерной рекламы

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


Большинство баннерных кодов используют JS вызов document.write(). Это делает невозможным прямой запуск такого кода на событии body.onLoad().

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

1. Все баннерные коды нужно вставлять в скрытые блоки (со стилем style=”display: none”). Современные браузеры имеют встроенные механизмы оптимизации, поэтому всё, что находится в скрытых элементах не отрисовывается вообще. Далее на событие body.onload() нужно повесить вызов, который покажет все скрытые баннерные блоки. Пример с использование jQuery:

   ...
   Баннерный блок:
   <div style="display: none;" class="banner"><script>Тут баннерный код</script></div>
   ...
   <script>$(document).ready(function() { $('.banner').show(); });</script>
   ...
   

2. Выносите баннеры в iframe. Формально это не отложит загрузку, но баннеры будут грузится параллельно с загрузкой страницы, а не последовательно. Это позволяет добиться максимального эффекта. В этом случае единственное неудобство - фиксированный размер фрейма.

Оптимизация загрузки баннеров

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

Сталкивались ли Вы с проблемами производительности баннерной рекламы, и как их решали?

Related posts:

1. Оптимизация картинок для Web
2. Google analytics - отслеживание скорости загрузки страниц

Connect.ua - это первый украинский социальный сервис. За два года проект вырос в достаточно крупный, а следовательно имеет свою собственную историю масштабирования и роста.

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

Наши показатели и цифры

Некоторые цифры проекта

• 720 тыс. пользователей
• 2 миллиона фотографий
• 400 тысяч видео роликов
• 20 миллионов личных сообщений
• 50 миллионов оценок в ЖЖОТ
• 25 миллионов событий в ленте новостей
• 40 миллионов отправленных “Подмигнуть”

Технические показатели

• 500 запросов в секунду на MySQL
• 300 активных соединений на фронте + 200 активных соединений на медиа серверах (HTTP)
• 1.5 тысячи запросов в секунду на каждом из бекендов
• 8 миллионов запросов к бекендам в день
• 7 Тб медиа (видео + аудио + фото)
• 3 сервера баз данных
• 4 бекенд сервера
• 1 фротенд
• 4 медиа сервера
• 2 сервера транскодирования
• 20 Гб памяти под Memcached

Технологии

Технологий используется огромное множество, причем динамика использования новых технологий очень высокая. За год на проекте появилось множество улучшений, связанных с новыми техническими решениями.

• MySQL
• Sphinxsearch
• Memcached
• MemcacheDB
• PHP
• PHP-FPM
• Eaccelerator
• Nginx
• Imagemagick
• FFmpeg
• Mencoder
• Flvtools
• Varnish
• GFS
• Munin
• Nagios
• Xhprof
• Minify (библиотека сжатия статики)
• Linux shell

Далее наш опыт, архитектура, решения, ошибки и выводы:

Мониторинг и статистика

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

Для мониторинга используем Nagios.

Система статистики не только помагает обнаруживать проблемы, но и прогнозировать расширение.

Оборудование

Мы используем подход горизонтального расширения, а не вертикального. Поэтому мы делаем выбор в сторону недорого оборудования. Что это дает:

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

СУБД: не в MySQL проблема, проблема в эффективности

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

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

Движки таблиц - InnoDB для всех таблиц, кроме случаев с полностью статическими таблицами (города, страны и т.п.) - для них MyISAM.

Для полнотекстового поиска используем Sphinx. Работает по схеме дельта индексации. Самая тяжелая часть - полная переиндексация, поэтому запускаем ее раз в неделю. Планируем внедрить объединения индексов (index merging).

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

Что мы делали для оптимизации нагрузки

• Кеширование (подробнее - ниже)
• Тюнинг настроек сервера MySQL - никогда не используйте настройки по умолчанию
• Оптимизировали (и все еще продолжаем) запросы. EXPLAIN + maatkit - это наш набор оптимизатора.
• Тяжелые запросы зачастую можно упростить на порядки выкинув малозначимые части логики
• Для особо тяжелых и не поддающихся ускорению запросов есть слейв
• Денормализация + индексация - постоянные задачи

Кеширование: кешируйте все и еще немножко

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

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

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

Система кеширования носит двухслойных характер: кеш приложения => memcached.

Клиентская оптимизация

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

Что мы делали:

• Gzip всего
• Склеивание и сжатие статики
• Вынос статики на другой домен
• Установка необходимых заголовков для кеширования на клиентах

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

Медиа

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

PHP

С PHP было меньше всего проблем. Единственным шагом, который привел к ощутимому росту скорости работы, стала установка eAccelerator’a. Большинство изменений в коде были связаны с архитектурными изменениями.

Для профилирования используем XhProf - хорошо подходит для работы в продуктивных условиях.

Что мы планируем

• Переводить часть логики с MySQL на key=value базы данных
• Внедрить систему очередей сообщений
• Оптимизировать клиентскую часть дальше
• Искать затычки и исправлять их

В качестве итога

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

• Если решение работает у кого-то, это еще не значит, что оно будет работать для Вас
• Во многих случаях приходиться экспериментировать. Нужно позаботиться о том, чтобы небольшие изменения в системе не вызывали огромных трудностей
• Думайте о росте заранее, но не решайте не существующих проблем
• Многие технологии умеют гораздо больше, чем кажется - гораздо больше
• Творчество Ваш самый необходимый инструмент
• Не делайте того, о чем ничего не знаете

Надеюсь будет полезно!

No related posts.

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

Рассмотрим, как использовать Google Analytics, чтобы отслеживать скорость загрузки страниц Вашего Web сайта у пользователей.

Event Tracking

В GA есть раздел Event Tracking, который и позволяет отслеживать статистику пользовательских событий. Для использования этой возможности Вы должны установить новую версию скрипта статистики (ga.js).

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

Для отправки пользовательских событий, нужно воспользоваться методом _trackEvent():

pageTracker._trackEvent('category', 'action', 'label', value);

• category - Категория события
• action - Тип события
• label - Название события (необязательно)
• value - Значение события (необязательно, числовой параметр)

После этого, в разделе Content (Содержание) -> Event Tracking (Отслеживание событий) можно смотреть статистику, пользуясь удобным и мощным инструментом.

Скорость загрузки страниц

Для начала, необходимо установить переменную, которая будет содержать в себе значение скорости загрузки страницы. Пример на PHP:

define('TS_START', microtime(true));

# Тут много много кода - вся логика страницы

define('TS_SPEED', microtime(true) - TS_START);

После этого в константе TS_SPEED будет доступно время выполнения скрипта в долях секунды.

Далее в шаблоне страницы необходимо зарегистрировать событие при помощи _trackEvent():

...
<? $uri = $_SERVER['REQUEST_URI']; $speed = (int)(TS_SPEED*1000); ?>
<script>
pageTracker._trackEvent('Response time (ms)', '', '', );
</script>
...

Несколько моментов:

• _trackEvent() нужно вызывать после объявления счетчика (частая ошибка)
• Последний аргумент должен быть только целым числом, поэтому мы умножили его на 1000 (будем отслеживать скорость загрузки в миллисекундах)
• Первые три аргумента всегда должны быть строчками, иначе событие будет проигнорировано

После установки кода и спустя некоторое время в GA будет доступен отчет приблизительно такого вида:

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

• Всего событий - количество вызовов конкретного события (action)
• Уникальных событий - количество уникальных вызовов конкретного события
• Полезность события - сумма всех value данного события. В нашем случае это суммарное время генерации конкретной страницы
• Среднее значение - среднее значение value данного события. В нашем случае это среднее время генерации конкретной страницы

Детальное описание Google Analytics Event Tracking (англ.).

А Вы пользуетесь Event Tracking в GA, в каких целях?

Related posts:

1. Оптимизация клиентской части с Google Page Speed