«Легкие» счетчики для HighLoad ресурсов

На днях, на Хабре была статья о том, как можно уменьшить нагрузку на БД, путем экономии ресурсов на обновлении счетчиков. Действительно, различного рода счетчики, например, счетчик просмотра статей, генерируют массу запросов типа UPDATE, при этом неся очень малое количество пользы для кого бы то ни было. Отказаться от счетчиков совсем тоже неправильно. Многим интересно, насколько читаем тот или иной материал. Для кого-то малое количество просмотров статьи станет поводом для того, чтобы не тратить свое драгоценное время на ее прочтение. Есть и другие считалочки, наличие которых еще более привлекательно. Как же быть?

Лично я использовал бы кэш, например, демон Memcached. И обновление строки в БД производил бы один раз на определенный промежуток времени, допустим — 10 минут. Потеря кэша в данном случае не очень критична. Мы ведь считаем не школьников, присутствующих на уроке и не населении страны. Мы не слишком расстроимся если мимо нас проскользнут какие-нибудь 10-100 итераций. Да и при нормальной работе сервера с демоном, потеря данных кэша достаточно редкое явление.

Тем не менее, если варианты есть, давайте их рассмотрим.

Что предложили на Хабре?

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

Каждый раз, при просмотре страницы, используя генератор псевдослучайных чисел, мы генерируем число, например, в диапазоне от 1 до 100. Затем проверяем, равно ли это число 50-ти (можете взять любое другое, попадающее в выбранный диапазон). Если условие выполняется, то мы обновляем значение счетчика в БД на 100. Почему так?

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

Тесты

Мы заменили сотню UPDATE на один единственный. Неплохо, правда? Но насколько велика погрешность при такой организации? Тесты покажут :)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$totalCounter = 0;
 
$realCounter = 10000;
 
for ($i = 0; $i < $realCounter; $i++) {
    $number = rand(1, 100);
 
    if ($number == 50) {
        $totalCounter++;
    }
}
 
$result = $totalCounter * 100;
 
printf("Реальное значение: %d ", $realCounter);
echo '<br />';
printf("Искусственное значение: %d (%d)", $totalCounter, $result);
echo '<br />';
printf("Разница: %d", $realCounter - $result);

Вот такой вот простенький тест. Запускаем цикл на n-ое количество итераций, в данном случае на 10 тысяч. Далее генерируем «случайное» число и производим проверку. В результате выполнения получаем три строки. Первая показывает сколько было итераций — живых просмотров страницы. Вторая — сколько раз выполнилось условие равенства случайного числа и числа, определенного нами. В скобках отражено произведение этого счетчика и множителя 100. Ну и третья строка — разница между реальным значением счетчика и нашим.

Если вам лень самостоятельно гонять этот тест, то вот таблица с моими результатами.

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

На самом деле, результаты теста совершенно необъективны. Да и какая может быть объективность, если все зависит от случая. В таблице результаты одни. На деле же, при малом количестве итераций (читай «просмотров статьи») разница между реальной величиной и получившейся очень заметна. Попадались результаты, в которых искусственное значение было в три раза меньше реального (300 к 1000). В таблице наоборот — оно в 2 раза больше.

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

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

P.S: ссылку на хабротопик, который я здесь упоминал, я потерял. Если кто-то найдет его на хабре, оповестите и я обязательно на него сошлюсь.

Автор: Мурашов Олег
Источник: http://inroot.ru/