Цели и задачи тестирования

1. Тестовый стенд
2. Тестовый сайт
3. Методика тестирования
4. Тестирование – этап 1 (без кэширования)
5. Тестирование – этап 2 (с частичным кэшированием)
6. Оценка результатов тестирования
7. Выводы

Тестовый стенд

Перед началом тестирования мы располагали тремя серверами различной конфигурации на основе процессоров Intel:

1. Xeon 1: Intel Xeon 3.2 GHz (1 процессор), 2 GB RAM, SATA RAID 1 250GB
2. Xeon 2: Intel Xeon 3.2 GHz (2 процессора), 2 GB RAM, SAS RAID 1 250 GB
3. Core Quad: Intel Core Quad Q6600 (1 процессор), 2GB RAM, SATA RAID 1 500GB

В настоящее время одно- и двух- процессорные сервера на базе Intel Xeon предыдущего поколения являются одними из самых распространенных серверов начального и среднего уровня, установленных в современных дата-центрах. По данным, предоставленным компанией Мастерхост, к началу лета 2008 года доля серверов на этих процессорах в дата-центрах Москвы составляла до 2/3 от общего количества. Ощутимую долю также занимают серверы начального уровня на устаревающих Pentium IV и Celeron.

Третий участник нашего теста, сервер на базе Intel Core Quad Q6600, олицетворяет собой сервер начального уровня на новом поколении процессоров Intel. Линейка Core Duo/Quad позиционируется Intel как «настольная», что не мешает, тем не менее, использовать эти процессоры в серверах начального уровня. Осмелимся предположить, что несмотря на «настольную» ориентацию, Intel Core Duo/Quad займут не последнее место среди однопроцессорных серверов. Подобная история уже происходила с Pentium IV, который завоевал высокую долю рынка бюджетных веб-серверов благодаря невысокой стоимости при относительно неплохой производительности.

Тестовый сайт

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

В качестве тестового сайта мы использовали полнофункциональную копию информационно-новостного ресурса, содержащего около 4500 статей и аналитических материалов, а также пользовательские аккаунты, комментарии, темы форума, баннеры, RSS-потоки и др. Общий объем информации в базе данных сайта, с учетом связей между контентами, составляет около 30,000 записей.

Методика тестирования

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

Как видно из рисунка, 94% всей нагрузки пришлось на 5 типов страниц:

• Главная страница – 23%
• Просмотр статьи – 23%
• RSS-потоки – 18%
• Комментарии пользователей – 17%
• Поиск по сайту – 13%

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

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

Тестирование – этап 1 (без кэширования)

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

• Core Quad – СУБД и веб-сервер работают на одном сервере;
• Xeon 1 + Xeon 2: однопроцессорный сервер Xeon 1 выступает в качестве веб-сервера, двухпроцессорный сервер Xeon 2 – в качестве сервера СУБД, соединение осуществляется по локальной сети с пропускной способностью 1Гбит/с;
• Xeon 2 – СУБД и веб-сервер работают на одном двухпроцессорном сервере Xeon 2.

Честно говоря, результаты данного теста нас удивили. Мы предполагали, что Core Quad вероятно окажется быстрее двухпроцессорного Xeon предыдущего поколения, но то что отрыв окажется таким значительным, а также то, что Core Quad сможет обойти даже двух-серверную конфигурацию, стало для нас неожиданностью.

Интересны также данные о распределении нагрузки между сервером приложений и СУБД. На протяжении теста Xeon 1 + Xeon 2 мы замеряли среднюю загрузку процессора на обоих серверах:

Как видно из диаграммы, узким местом в данной конфигурации является СУБД, и как бы мы не повышали нагрузку, нам не удавалось полностью загрузить мощности веб-сервера. Посмотрим, как изменится ситуация после активации кэширования SQL-запросов.

Тестирование – этап 2 (с частичным кэшированием)

Встроенный в FrontContent механизм кэширования SQL-запросов позволяет «прозрачным» для разработчика способом кэшировать произвольные запросы к БД на заданное время. Кэшированные данные хранятся в памяти веб-сервера и при обращении к ним СУБД не задействуется вовсе. В процессе проведения теста мы включили кэширование на блоках сайта, отвечающих за навигацию и формирование вспомогательной информации. Основное содержимое страниц (главная новостная лента, тексты самих новостей, комментарии пользователей и т.д.) остались без кэширования, от 1 до 3 не-кэшированных SQL-запроса на страницу. Период кэширования был установлен в 5 минут, таким образом чтобы во время проведения каждого теста (30 минут) кэш успевал обновиться несколько раз, получая обновленные данные из БД.

Как видим, применение кэширования увеличило производительность одно-серверных конфигураций приблизительно в 1,8 раза, а двух-серверной – в 1,55 раза. Меньшая эффективность на двух-серверной конфигурации, по видимому, объясняется тем что в ней узким местом стал веб-сервер на базе более слабого Xeon 1.

Полное кэширование всех SQL-запросов сайта, очевидно, могло бы дать еще более значительный прирост производительности, однако следуя идее нашего теста – максимальная приближенность к реальным условиям - мы не стали проводить такой эксперимент. Кэширование создает побочный эффект – задержки в публикации информации, и на живых проектах практически не применяется в «тотальном» варианте. Напомним, что в данном случае использовалось кэширование только SQL-запросов. Дальнейшее увеличение производительности может быть достигнуто кэшированием целиком сгенерированных веб-страниц.

Загрузка процессоров в тесте Xeon 1 + Xeon 2:

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

Оценка результатов тестирования

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

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

На рис. 7 изображен типичный для исследуемого сайта график распределения нагрузки по времени суток. Четко видны два пика посещаемости – в районе 10-11 и 16-17 часов. В каждый из пиковых часов нагрузки сайт обрабатывает до 7-7,5% от общего количества загрузок страниц в сутки. По данным статистики посещений, среднее время пребывания посетителя на сайте составляет 6 минут 33 секунды, среднее количество просмотренных страниц – 4.1 шт.

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

• здесь Pсек – максимальная производительность системы, веб-страниц в секунду;
• умножая на 3600, получаем теоретическую максимальную производительность в час;
• применяем коэффициент запаса – делим максимальную производительность на 1.5;
• учитывая, что в пиковый час нагрузки обрабатывается около 7% от общего количества загрузок страниц в сутки, получаем общее количество обработанных страниц в сутки;
• разделив количество страниц на 4,1 (среднее количество страниц, просмотренных одним посетителем), получаем оценку по количеству посетителей в сутки.

Серверная конфигурация	Прогноз по максимальному количеству уникальных посетителей сайта в сутки, с учетом распределения нагрузки по времени
	Без кэширования	С кэшированием
Core Quad	298 тыс.	536 тыс.
Xeon 1 + Xeon 2	253 тыс.	293 тыс.
Xeon 2	149 тыс.	271 тыс.

Выводы

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

1. Система управления сайтом FrontContent способна обслуживать сайты с реальной посещаемостью более полумиллиона посетителей в сутки при работе на современном однопроцессорном сервере начального уровня;
2. Использование подсистемы кэширования SQL-запросов в FrontContent дает высокий прирост производительности, а также существенно снимает нагрузку с СУБД;
3. Кластеризация веб-серверов, совместно с подсистемой кэширования FrontContent, предположительно может быть весьма эффективным средством повышения общей производительности системы, без прибегания к кластеризации СУБД;
4. Налицо преимущество более современных «настольных» процессоров Core Quad по сравнению с серверными процессорами Xeon предыдущего поколения. Предполагаем, что процессоры Xeon нового поколения могли бы продемонстрировать еще более высокие результаты.