Первое нагрузочное тестирование

Всем привет.
Я снова с очередным отчетом о том, как продвигаются у нас дела для потенциальных клиентов и тестеров.

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

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

Для тестирования мы взяли наш рабочий дедик, таких характеристик:
Intel® Xeon™ E3-1245 Quad-Core inkl. – 4 ядра, 32 GB DDR3 RAM ECC, 2 x 3 TB 6 Gb/sec 7200 RPM HDD SATA3
ОС: Ubuntu 12.04 Precise LTS 64 bit
Cервер с апачем и ISPManager’ом, никаким образом пока еще не оптимизирован для наших БД.

Нагрузку давали с помощью написанного мной на python многопоточного эмулятора. Он эмулирует IP, ISP, Device, токены, вообщем все параметры клика.
Трекер обрабатывал клик, записывал его в базу, обрабатывал редиректы (тест проводился с рулсами), и на лендинге выводил время выполнения разных этапов его обработки.

Средний результат получился таким:
Click #4160
detect tokens: 0.00010395050048828
detect camp: 0.0002138614654541
detect device: 0.026785850524902
detect operator: 0.010999202728271
save detect: 0.00013208389282227
detect load: 0.038197994232178
save click: 0.00028395652770996
function redirect: 0.00063610076904297
all time: 0.041412115097046
И это при 100 потоках, примерно 120 кликов в секунду! (432к в час, 10 миллионов в сутки)
Все результаты в секундах. т е all time = 41мс

Тестирование не учитывает скорость загрузки ленда. Т. е. это время от клика по трекинг-урлу до открытия ленда. Грубо говоря разница во времени, если бы вы лили напрямую на ленд без трекера. Т. е. трекер добавляет всего 41 миллисекунду. И это достаточно долго для него, как показали следующие тесты.

Далее мы выводили только all time и тестировали на разных потоках трафика. Скажу заранее, "убить" трекер и сервак мы так и не смогли (не хватило проца на моем маке и 100мб инет-канала).

Выглядит тестирование примерно так:

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

Результаты тестирования

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

И самое главное – потери кликов составили ровно 0%. Каждый тест составлял 100000 кликов и абсолютно все клики доходили до базы, даже когда мы выжимали максимум из моего бедного мака и слали пакеты как могли.

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

Кроме того, на следующей неделе мы еще немного оптимизируем таблицу кликов (уберем из нее текстовый useragent, заменив его id). Что еще больше ускорит наши редиректы.

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

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

Для нас главное – экономить ваше время. В этом заключается наша клиентоориентированность и это наша работа.

Удачи нам в этом нелегком деле, и надеюсь уже скоро мы сможем наконец предложить для тестирования первые версии нашего трекера!

Комменты