Как 1С-Битрикс справляется с высокими нагрузками? Нагрузочное тестирование битрикс

Нагрузочное тестирование на примере "1C-Битрикс"

Олег Бунин Генереральный директор студии разработки высоконагруженных интернет-проектов "Онтико".

Олег Бунин: Добрый день! Несмотря на то, что в заголовке доклада указан «1С-Битрикс», мой доклад будет про нагрузочное тестирование вообще. Я рассказываю о том, что нагрузочное тестирование — это правильно, здорово и очень полезно. Провести его не так уж сложно. Следующий докладчик подробно остановится на том, как это делать (у него много таблиц, цифр и слайдов). У нас парные доклады. Постараемся дать исчерпывающую информацию.

Итак, нагрузочное тестирование на примере "Битрикса". Мы будем препарировать именно эту систему.

Интересно, многие ли здесь делают нагрузочное тестирование? Шесть человек — это немного. Жаль, что остальные пока не оценили эту возможность.

Зачем проводить нагрузочное тестирование? В чем его цель? Многие думают, что цель нагрузочного тестирования — получить цифру. «Смотрите, система выдерживает 2 миллиона запросов! Здорово».

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

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

Возьмем знакомые всем московские пробки. Разберем два вопроса. Например, Юрий Михайлович Лужков вот уже пару лет заботливо и старательно расширяет Ленинградское шоссе до 16 полос. Почему это довольно бессмысленное действие?

Реплика из зала:

— Потому что оно упирается...

Олег Бунин:

— Совершенно верно. Ленинградское шоссе упирается в шестиполосную Тверскую, две полосы которой постоянно стоят, они все время заставлены машинами. Это первый пример.Другой пример. Давно ходят разговоры о том, чтобы закрутить Садовое кольцо в одну сторону. Почему этого не делают?

Реплика из зала:

— Потому что лень.

Олег Бунин:

— Очень просто... Нет, не лень. Есть исследования, результаты которых говорят, что в этом случае скорость движения автомобилей по Садовому кольцу может даже уменьшиться. Почему? Сейчас мы четко понимаем, что крайний правый ряд движется медленнее всего (автомобили уходят на развороты, съезжают и так далее). Крайний левый ряд движется быстрее всего. Если все 12 полос будут двигаться в одном направлении, то подобного разделения не будет. Начнется хаос. Вполне возможно, что этот хаос приведет к тому, что скорость движения снизится. Наверняка это неизвестно, но есть подобные подозрения.

Как ответить на эти вопросы в применении к интернет-проекту? Веб-система — это система не менее сложная, чем схемы движения транспорта, иногда она намного сложнее.

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

Есть Apache, который тоже что-то делает: 16 или 12 обработчиков (англ. handler) для обработки запросов. Что-то начало читаться с диска, запустились еще какие-то процессы... Операционная система, опять диск, дисковая подсистема, у которой есть кэши в памяти и так далее.

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

К чему я клоню? Результаты простого тестирования вроде Apache Benchmark, которое все очень любят, или тестирования какого-то отдельного компонента могут оказаться бессмысленными. Тестировать нужно всю систему в целом, в совокупности.

Берем и даем нагрузку на весь комплекс от начала до конца, начиная от nginx и заканчивая базой данных. Мы не даем нагрузку на какую-то страничку отдельно. Мы даем нагрузку на все компоненты системы. Нужно попытаться смоделировать, сымитировать нагрузку реальных пользователей.

Проще всего это сделать, взяв реальный log-файл сайта. Нужно посмотреть его, построить профиль нагрузки, задать некоторое количество запросов и попробовать "побомбить" сайт. Если такой log-файл у нас есть, конечно.

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

Нагрузка должна даваться в течение длительного времени. Если вы протестируете вашу систему в течение 5 минут — отлично. Она, может быть, и заработает как-нибудь. Но не факт, что все и дальше пойдет гладко.

Если вы будете проводить тестирование в течение дня, то в какой-то момент у вас переполнится система для хранения сессии, и все перестанет работать. Это, кстати, одна из типичных проблем в работе таких CMS-систем, как "Битрикс". Их нужно тестировать в течение длительного времени, потому что кэш постепенно накапливается.

Например, рассмотрим как "Битрикс" сбрасывает кэш. У него есть разные кэши — есть интеллектуальный кэш, есть не очень. Все «не очень» сбрасываются. RM минус DR — происходит сброс кэша.

Что произойдет? При 5-минутном тестировании мы этот момент не "отловим". Нам нужно в течение дня тестировать систему и иногда сбрасывать запросы вида "post"... Существуют сигнальные запросы, получая которые Битрикс считает: «Ого! У меня все изменилось. Нужно сбросить кэш». Нужно в течение дня смотреть на реальные результаты.

Профиль нагрузки я уже упомянул. Нужно максимально воссоздать работу реальных пользователей. Реальные пользователи далеко не так просты, как кажется. Это не просто набор URL.

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

Например, возьмем PHP-сессии. Если мы будем тестировать систему, не имитируя надлежащим образом работу PHP-сессий, мы получим нереальный результат.

Если на каждый запрос будет со стороны PHP создаваться новая сессия — это не сработает. Это не будут реальные цифры. Все это нужно учитывать.

Как мы даем нагрузку? У нас есть несколько вариантов. Первый вариант довольно простой — это профиль нагрузки.

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

Более сложные варианты — это имитация сессий пользователя. Берем и выстраиваем цепочку. Пользователь у нас сначала пришел на главную, потом авторизовался, потом сделал то-то, например, выполнил поиск, потом ушел. Параллельно мы запускаем много таких цепочек.

Есть еще масса различных аспектов. Есть клиенты с медленным соединением, о которых часто забывают. Все было бы хорошо, если бы клиент тут же "забирал" запрос, как только Apache сформирует его. Так не бывает.

Медленные соединения не редкость. А если клиент на модеме, а если Интернет медленный - и так далее? Apache, nginx или то, что у вас работает, может забирать этот ответ долго.

Имитацией клиентов с медленным соединением тоже не стоит пренебрегать. Разница будет колоссальная - в разы. Либо мы имитируем работу "медленных" клиентов, либо мы делаем вид, что у всех отличный двухмегабитный стрим.

При проведении тестирования вы первым делом описываете его методологию и возможные допущения. Также вы описываете ограничения и отступления от реальной ситуации. Воссоздать реальную ситуацию невозможно.

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

Нам приходится многое упрощать. Например, у нас будет не миллион точек, чтобы отдавать запросы, а всего 4 или 5, то есть несколько серверов, с которых мы будем гнать нагрузку. Это первое упрощение.

Второе упрощение. Скорее всего, мы не расставим эти точки в разных местах Интернета. А если и расставим, то всего в четырех.

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

Мы получим 20 миллионов хитов — «Вау!». Это нереальная цифра. Оно большая, хорошая, но реальная цифра будет намного меньше.

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

Как мы делали его для "Битрикса"? Компания «Мастерхост» выделила нам несколько серверов, мы их объединили, развернули тестовую ферму. На одном из них развернули "Битрикс".

"Битрикс" мы настроили определенным образом. Естественно, мы применяли не настройки по умолчанию.

Настройки по умолчанию - это просто беда. Проводить нагрузочное тестирование стоит хотя бы ради нормальных настроек. Настройки по умолчанию MySQL, PostgreSQL и Apache в принципе не предназначены для работы. Наверное, это специально сделано для того, чтобы разработчики "включали мозги".

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

Самое главное — это оптимизация настроек. Конкретная машина, конкретное оборудование, конкретное количество памяти. Если у вас 2 гигабайта памяти и если у вас 4 гигабайта памяти, настройки Apache будут разными. Это очевидно. Оптимальные настройки nginx, Apache и базы данных будут разными, чтобы получить максимальную производительность.

Рефакторинг узких мест - это то, что мы проводили и проводим совместно с компанией "1С-Битрикс". Я сейчас расскажу, как мы это делаем.

Данные о поведении системы под нагрузкой — тоже важный момент. Вам же не просто надо получить цифру... Хорошо, система держит 8 миллионов соединений. Что при этом происходит? Сколько времени она обрабатывает запрос? Например, система держит 8 миллионов соединений, но обрабатывает запрос за 120 секунд. Это бесполезная цифра.

Нужно построить так называемую «кривую деградации», которая показывает, как "умирает" система. Она в любом случае "умирает". Понятное дело, что мы ее нагрузим до такой степени, что она "умрет". Как и в какой момент она это сделает? Она это сделает сразу или будет долго "сражаться" за свою работоспособность?

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

Тестировщики над нагрузкой никогда в одиночку не работают. Это, на мой взгляд, бессмысленно. Программисты, системные администраторы, архитекторы — все задействованы. Дается нагрузка... Как это делается?

Примерно так: нагрузили, куча народу смотрит, что происходит. Идет нагрузка, в данный момент 100 запросов в секунду. Что происходит с системой? Как она себя ведет: работает, не работает, ушла она в подкачку (англ. swap) или нет - наблюдаем за всем этим. Мониторинг осуществляется вживую, понятное дело.

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

Гипотеза — тестируем — смотрим — проверяем. Гипотеза — тестируем — смотрим — проверяем. Изменение — тестируем — смотрим — проверяем. Это бесконечный цикл.

На самом деле, это не так сложно. Это дает вам информацию, которую вы не получите, имея только самомнение «я гениальный архитектор, я задумал так». Цифры помогут какие-то мельчайшие вещи поменять, например, значение параметра start service в Apache с 50 на 10 — и подобные вещи приводят к изменениям в работе системы.

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

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

Опишу классический случай, с которым сталкиваются очень многие начинающие разработчики. «У нас система не справляется с нагрузкой». — «Давайте увеличим количество процессов Apache». — «Хорошо, давайте увеличим».

«Опять не справляется с нагрузкой» — «Давайте еще увеличим?» — «Отлично». Бац! «Что это она у нас умерла? Почему? Странно». Она в память не влезла, ушла в подкачку и умерла. Очень логично. 50% случаев "смертей" того же "Битрикса" происходит именно поэтому.

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

Она выходит на какой-то уровень, и начинает увеличиваться время ответа. Сначала 1 секунда, 2 секунды, 10 секунд, 20 секунд — оно становится неприемлемо большим. Но система продолжает работать.

Как умирает "Битрикс"? Мы его, конечно, завалили. Мы получили фантастические цифры: 222 запроса в секунду (если просто умножить, это 19 миллионов хитов в сутки с одной машины). Фантастика!

Но это совершенно бессмысленное число. Почему? Потому что при такой цифре "Битрикс" отвечает примерно 2,5 секунды. Для большинства сайтов это очень долго.

Если смотреть как раз на ту самую кривую деградации, нам нужно не крайнее, а среднее значение. Нужно реальное число.

Сенсационные цифры — отличные. Реальные цифры гораздо скромнее, но, тем не менее, их тоже можно вычислить. Среднее время ответа 0,44 — половина секунды. Вполне нормально.

При дальнейшем увеличении нагрузки система начинает тормозить. Но при 0,44 секунды она вполне нормально работает. Это реальная цифра.

На данный момент мы полностью закончили 2 вида тестирования "Битрикса" — это HTML плюс автокэширование. Это отчасти не корректно, потому что это, по сути, тестирование производительности nginx. Nginx работает хорошо. Мы все про это знаем.

Более корректное тестирование — только автокэширование (это внутреннее кэширование "Битрикс"). Цифры скромнее. Если кому-то они важны, — это 8 миллионов запросов в день со стандартной средней машины западного хостера.

Вопрос из зала:

— А память увеличивали?

Олег Бунин:

— Мы решили не увеличивать. Можно увеличить количество памяти и посмотреть к чему это приведет. Тоже интересно.

Вот и все, что я хотел сказать. Тестировать надо. Это просто и полезно. Вы получите информацию о своей системе, которую чистая теория не даст вам никогда. Жду вопросов.

Вопросы и ответы

Вопрос:— Я, на самом деле, хочу сказать большое спасибо и порадоваться, что все мои лекции не проходят даром. Если внимательно слушать, я последние время очень сильно настаиваю на том, чтобы мы имели какие-то цифры, требования до того, как мы ввязались в это, начали тестирование, может быть, даже построение нашей системы.Скажи, пожалуйста, имели ли вы до начала тестирования (или в процессе тестирования) какие-нибудь требования: функциональные, нефункциональные, требования бизнеса, требования к нагрузке, к последующему масштабированию, к росту?Олег Бунин:— Нам нужно было выяснить несколько вещей. Сейчас новая версия Битрикса тестируется. Есть результаты - замеры скорости работы предыдущей версии. Во-первых, нам нужно было повторить методологию — какая сейчас выдерживается нагрузка при таком же процессе тестирования.Во-вторых, нужно было оптимизировать настройки - это то, за что я агитирую. Наша задача была — дать нагрузку на "Битрикс" с тем, чтобы его разработчики смогли посмотреть, как их система себя ведет, что-то оптимизировать, "подкрутить" и так далее.Вопрос:— Другими словами, во-первых, вы проводите регрессионное тестирование, сравнивая с показателями предыдущей версии на тех же условиях, чтобы убедиться, что стало не хуже. У вас все равно есть какие-то требования, полученные с предыдущих тестов.Во-вторых, вы проводите оперативное тестирование для того, чтобы дать возможность разработчикам покопаться внутри, зная о результатах?Олег Бунин:— Да.Вопрос:— То есть профилирование и всякое прочее. Хорошо, молодцы.Вопрос:— Я так понимаю, что тестирование конкретных подсистем не проводится, исходя из того, что там получаются совершенно непонятные попугаи.Олег Бунин:— Почему? Отдельно конкретную подсистему тестировать не совсем логично.Вопрос:— Если при приходе новой «железки» RAID-контроллера ее не протестировать и не узнать, что у нее есть конкретные «затыки» (например, не узнать DTO), то производительность базы можно намерить совершенно не ту. Более того, потом долго думать, почему база данных или само приложение так "тупит", и не обратить внимания на ту простую ошибку, которая была в настройках контроллера.Вопрос в том, что именно тестируя все сразу, при этом совершенно отметая тестирование конкретных подсистем, можно слишком долго искать ошибки во всей системе, тогда как причина, например, в том же контроллере.Олег Бунин:— Тестируя конкретные подсистемы, сложно сделать вывод о производительности системы в целом. Отлично работает RAID-контроллер. И что? Или протестировали все отдельно. Оно работает все прекрасно. Собрали вместе — не работает.Реплика:— Все-таки я считаю, что тестировать подсистемы нужно.Олег Бунин:— Давайте найдем компромиссное решение. Мы будем использовать комплексный подход: и то, и другое.Вопрос:— Два вопроса. Первый — какие трудозатраты потребовались для разработки такой системы? Сколько по времени заняло?Олег Бунин:— Сама система не первый год уже используется. Красивый пример - как мы подобным образом разгоняли Imhonet.ru 2 года назад. Когда мы первый раз к ним приехали и дали нагрузку, мы прослезились. Нагрузка из кластеры серверов была всего порядка 200 тысяч хитов в сутки.Imhonet представляете? У них сложная математика, вычисление рекомендаций. Когда я прихожу, мне подсказывают, что мне может еще понравиться то-то и то-то (книжки, фильмы и так далее). В результате подобной двухмесячной работы (мы давали нагрузку, они что-то правили) мы увеличили производительность системы в 10 раз.Вопрос:— Система у вас собственная разработана? Или какие-то готовые инструменты есть?Олег Бунин:— Да. Perl рулит.Вопрос:— Была упомянута сеть ботнетов. Вопрос в некотором роде теоретический. Почему до сих пор нет бизнеса, который бы сдавал ботнеты в аренду? Очевидно, что такой бизнес есть в определенном смысле. Почему нет официального бизнеса, который делает то же самое на совершенно легальных основаниях?Олег Бунин:— Мне кажется, просто потому, что они нелегальные.Вопрос:— Но это же, в принципе, легально? Если это делается по заказу...Олег Бунин:— Посадить троян к пользователю и запустить его.Вопрос:— Зачем? Пользователю нужно платить. Как...Олег Бунин:— Компания Яндекс знает все про ботнеты. Почему вы не используете это легально? Вы используете легально ботнеты?Вопрос:— У нас вечер вопросов и ответов продолжается? Да, мы используем легальный ботнет. Подробности не расскажу.Олег Бунин:— Наверное, есть такая услуга. Я не встречал. Я встречал только нелегальные версии.Вопрос:— Я правильно понял, что вы грузите своими скриптами?Олег Бунин:— Да.Вопрос:— Почему не брали какие-то готовые решения?Олег Бунин:— Так нам проще.Вопрос:— Мы используем JMeter. У нас пока малая производительность.Вопрос:— Скажу про свое время... Но это было 10 лет назад. Для тестирования производительности Job.ru мы использовали OpenStar. Но это было очень давно. Соглашусь, это история.Реплика из зала:— JMeter — это единственное вменяемое решение сейчас. Все остальные вызывают желание спрятаться под тазиком и не выглядывать. Есть целая куча всяких разных общедоступных и не очень средств. Это я уже, простите, на своего «конька» сяду. Есть целая куча средств на основе открытых исходников, которые совсем плохи и которые приходится "дорабатывать напильником" со страшной силой. Есть целая куча очень дорогих продуктов, которые, тем не менее, хотелось бы доработать, но нельзя, потому что они проприетарные. Есть JMeter, который наиболее приемлем из всего перечисленного.Третья альтернатива — это взять и написать что-то самому. Мы используем подход «бери исходники, дописывай свое». В итоге мы написали сильно больше, чем было изначально в исходниках.Вопрос:— Если не секрет, что дописывали?Вопрос:— Свое?Реплика из зала:— Да, у нас свое большое и страшное. Тем не менее, мы в некоторых местах используем JMeter, потому что это быстро, дешево и очень удобно бороться с PHP-сессиями, например.Но он нас не устраивает по производительности. Совсем не устраивает. Поэтому в том месте, где нужна производительность в десятки, сотни тысяч запросов в секунду, мы используем свое.Вопрос:— Где у вас сотни тысяч запросов в секунду надо?Реплика из зала:— Догадайся. Раздели миллиард хитов на 86 400.Вопрос:— Сотни тысяч запросов в секунду? Это очень много.Реплика из зала:— Да.Вопрос:— Где у Яндекса есть сотни тысяч запросов в секунду?Реплика из зала:— Потом покажу.Олег Бунин:— Переходим к практике, отлично. У меня был вводный доклад. Сейчас будет хороший практический доклад от компании Rambler.Вопрос:— Добрый день. Мы используем LoadRunner Hewlett-Packard. Вы наверняка слышали о нем. Платное решение, достаточно крупное. Не могли бы перечислить недостатки? Мы о некоторых из них знаем. Может быть, у вас, как у более крупного нагрузочного тестера, есть информация....Олег Бунин:— Я не скажу. Тимур, ты ответишь квалифицированно?Реплика из зала:— Во-первых, он стоит денег. Денег на такой кусок программного кода жалко. Во-вторых, там Windows... Я сейчас не помню, потому что мы последний раз пересматривали их 2 или 3 года назад. По-моему, это Windows.Олег Бунин:— Это Windows.Реплика из зала:— Еще вопросы есть? Хорошо. Мне нужно сэмулировать нагрузку в 1000 запросов в секунду. К тому же, если нам понадобилось вдруг что-то странное, мы можем написать производителям LoadRunner, они вежливо ответят. Когда они вкрутят туда то, что нам прямо сейчас нужно, неизвестно никому.Олег Бунин:— Например, у нас стоит комплексная задача. Нам нужно протестировать все редакции "Битрикса", получить по ним цифры, включая корпоративный портал. Как с помощью LoadRunner протестировать их систему чата (Instant Messaging)? Это возможно - тестировать чат неручным способом?Реплика из зала:— Если там HTTP, я думаю, что возможно. Если там придется что-нибудь с SNTP делать, я не уверен.Вопрос:— Давайте я попробую ответить. На самом деле, там довольно простая система (позволяет записывать свои сценарии через визуальный интерфейс). Это очень удобно и быстро.Олег Бунин:— Визуальный интерфейс в браузере?Вопрос:— Да.Олег Бунин:— Хорошо. А если нам нужно тестировать не HTTP?Вопрос:— С помощью сценариев можно записать отдельный подсценарий в общем главном сценарии на каждую подсистему, грубо говоря. В результатах нагрузочного тестирования (после подготовки отчета) получить по каждому блоку свои показатели и в целом по системе. Это очень удобно, все быстро можно получить.Реплика из зала:— Кстати, да. Все эти HP LoadRunner, меркуревские инструменты, которые сейчас существуют... Они офигенно подходят для того, чтобы продавать вашим заказчикам отчеты. Они красивые - просто прекрасные. «Мы тут провели работу, было так — стало так». Все отлично. Заказчик прыгает от счастья. Но это "липа" во многом.Реплика из зала:— Мы понимаем.Реплика из зала:— Это не про нагрузочное тестирование серьезных высоконагруженных проектов.Олег Бунин:— Я не знаю, как остальные присутствующие, но я привык просто контролировать процесс, который происходит внутри системы (будь то работа веб-сайта или нагрузочное тестирование).В случае, когда работает LoadRunner... Я не знаю, как он работает. В случае, когда работают Perl-скрипты, я знаю, как они работают и могу сделать все, что нужно. Вот и все.Реплика из зала:— Только медленно очень.Олег Бунин:— Медленно — это решаемый вопрос. Это "прямизна рук" программистов.Реплика из зала:— Спасибо, я получил ответ.

profyclub.ru

Нагрузочное тестирование CMS «1С-Битрикс» / СоХабр

Знаете анекдот про самолет, в котором есть и бар, и бассейн, и ресторан, но только при взлете стюардесса говорит: «А теперь со всем этим мы попробуем взлететь»?

Веб-разработка немного похожа на такой самолет. Заказчик хочет от веб-студии и классный дизайн, и кучу интерактива, и все службы доставки и оплаты в интернет-магазины, студия с удовольствием все это программирует… А вот хватит ли мощностей сервера на обеспечение стабильной работы сайта — непонятно. Чтобы нагрузка была прогнозируемой, чтобы задать некоторые эталонные значения, мы провели нагрузочное тестирование «1С-Битрикс: Управление сайтом» и «1С-Битрикс: Энтерпрайз».

Мы постарались так провести тестирование, чтобы клиент понимал, что можно получить на текущем оборудовании, а разработчик мог понять, каковы перспективы роста проекта. Получится ли отмасштабироваться при росте нагрузки?

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

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

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

Постановка задачи

Многие по разному понимают смысл, цель и задачи нагрузочного тестирования.

Для начала, нужно сформулировать для себя — чего же мы хотим?

Какой продукт и в каком виде тестировать? Сначала мы хотели взять реально существующий интернет-магазин, его код и базу. Но это было бы тестирование именно этого решения, другие разработчики не смогут использовать его в качестве точки отсчета. Значит, тестировать надо стандартную «коробку», заполнив ее большим количеством позиций, соответствующим крупному интернет-магазину (по нашему опыту, это около 100 000 SKU). «1С-Битрикс» работал с включенной технологией «Композитного кэша» — решения, которое сначала подгружает быстрый кэш сохраненной страницы из nginx, а следом — ajax-запросом подгружает динамические данные. Таким образом, пользователь получает страницу максимально быстро. Для оценки числа запросов в секунду мы считали именно динамические запросы.

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

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

Какие нужно создать сценарии нагрузки? По результатам анализа нагрузки на ряд крупных магазинов, трафик интернет-магазина можно разделить на 3 категории:

60% пользователей приходят и просматривают несколько страниц в каталоге, зная, какой конкретно товар им нужен.
37% пользователей выбирают нужный товар из нескольких возможных, применяют фильтрацию (smart-фильтр).
3% пользователей (стандартный показатель хорошей конверсии) положили товар в корзину и купили его.

Как именно нагружать серверы? Существует две основных модели нагрузочного тестирования проекта: закрытая и открытая. Закрытая подразумевает собой искусственную постоянную статичную нагрузку, в которой запросы «пользователей» идут статичным потоком (а не волнами, как в реальной жизни). Ее цель — выяснить поведение проекта при максимуме нагрузки, понять максимальную «пропускную способность» системы. Это верхняя планка метрики, выше нее уже не подняться.

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

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

Какой SLA выбрать для тестирования? Нам нужно было четко обозначить для себя тот порог, ниже которого мы считаем систему стабильно обслуживающей запросы. Для этого мы воспользовались статистикой ТОП-100 крупных интернет-магазинов (по версии издания «Коммерсант», 2014 г.) и выбрали две главные метрики: ответ на 99% запросов должен быть дан меньше чем за 1 секунду, а число ответов с кодом, отличным от HTTP 200, должно быть не более 0,5%. Тестирование должно вестись непрерывно в течение 24 часов.

Какой хостинг выбрать? В качестве площадки для тестирования мы выбрали хостинг Selectel с дата-центром «Цветочная-1» в Санкт-Петербурге. Selectel предоставил нам серверы самой популярной своей конфигурации — Intel Xeon E3-1270v3 3,5 ГГц, 32 Гб оперативной памяти, 2 × 240 Гб SSD-накопители в RAID 1. Один из серверов был использован как центр нагрузки, остальные, в разных конфигурациях «1С-Битрикс», мы использовали для тестирования.

Конфигурация системы В рамках тестирования серверы работали на ОС Linux CentOS 6.6 с установленным на нем пакетом «1С-Битрикс: Веб-окружение», подробнее о нем можно почитать здесь.

PHP в системе был обновлен до версии 5.6.9, а директории кэшей были смонтированы в tmpfs. Для тестирования были подготовлены три конфигурации:

1) 1 сервер. «1С-Битрикс: Управление сайтом», web и MySQL работают на одном сервере

2) 2 сервера. «1С-Битрикс: Энтерпрайз», балансировщик nginx на первом сервере, web-application на обоих серверах, MySQL мастер и запись/чтение в него — на первом сервере, MySQL slave и чтение из него — на втором сервере

3) четыре сервера. Вариант, в котором вторая конфигурация горизонтально отмасштабирована slave-машиной.

Чем тестировать? В качестве средства тестирования был выбран Яндекс.Танк. Яндекс.Танк позволяет использовать две системы генерации нагрузки — Phantom и JMeter. Phantom превосходит JMeter в плане производительности, однако не позволяет генерировать POST-логику, сохранение и последующее использование куков. По этой причине мы генерировали нагрузку с помощью JMeter.

Кто тестирует? Нам хотелось, чтобы тестирование провела независимая компания, мнению которой могли бы доверять и мы, и сторонние компании, и эксперты индустрии. Это задачу мы доверили компании ITSumma , которая с 2008 года занимается круглосуточным администрированием и технической поддержкой известных в Рунете проектов и зарекомендовала себя на рынке. Ее сотрудники являются постоянными докладчиками профильных конференций (таких как Highload, РИТ++ и др.).

Тестирование

В ретроспективе тестирование можно разбить на три этапа.

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

односерверная конфигурация: 34 потока
конфигурация из двух серверов: 74 потока
конфигурация из четырех серверов: 136 потоков

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

На этом этапе мы столкнулись с рядом сложностей. Из опыта их преодоления мы вынесли ряд уроков:

Организуя нагрузочное тестирование, помните, что первый большой прогон теста будет далек от идеальных результатов. Возможно, вы что-то забудете в конфигурации ОС и софта сервера. Возможно, будут проблемы с самой системой тестирования (JMeter — это Java-приложение, со свойственными ему проблемами со сборкой мусора). Ну и главное — вы увидите тонкие места в своей системе, которые ранее не замечали и которые можно будет исправить. Например, в рамках нашего тестирования были обнаружены девять значимых багов, исправления которых выйдут в ближайших версиях продукта. Так что рассматривайте свой первый тест как инструкцию к оптимизации.
Несколько очевидная вещь, которую однако стоит проговорить: во время оптимизации все изменения конфигурации на серверах должны фиксироваться. В идеале не применяйте больше, чем несколько изменений за раз. Иначе будет трудно выяснить, какое же именно действие привело к улучшению производительности.
Суточное тестирование при наличии любой, не обнаруженной сразу ошибки — это потерянный день работы. После одной из итераций, когда мы внесли ряд изменений в конфигурацию, получили хорошие результаты и были тому обрадованы. Но потом обнаружили, что был отключен третий сценарий — оформление заказов пользователей, самый тяжелый в нашем случае. Пришлось запускать тестирование заново. Через сутки выяснили, что примененные изменения не ускоряют систему.
Система под нагрузочным тестом — это продакшн-система, и с ней могут случится все те же типовые проблемы, которые происходят на продакшн-сайтах. У нас в одном из тестов, через 12 часов после запуска, на одном из серверов закончилось место. Поэтому жизненно необходимо поставить стандартные оповещения о проблемах на сайте в своей привычной системе мониторинга, чтобы они приходили вам на телефон. И при получении нужно немедленно бежать исправлять ситуацию, чтобы не потерять уже собранные драгоценные данные.
Хорошие результаты чаще всего означают ошибки в тестировании. В одной из итераций мы получили двукратный прирост по сравнению с предыдущим тестом. Оказалось, что MySQL «вылетал» по max connections, а сайт в таких ситуация отвечал валидным для системы тестирования кодом HTTP 200.
В любом тестировании очень важна «бюрократия»: делайте максимально подробное описание проведённого теста — сценарии, конфигурацию системы, логи тестирования и т.д. Все это будет полезно для последующего анализа.

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

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

Конфигурация 1 (1 сервер, «1С-Битрикс: Управление Сайтом», редакция «Бизнес»)

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

Число PHP-запросов в секунду: 167, при 34 одновременных потоках
99-процентиль: 0,366 мс.
Число просмотренных страниц: 14 421 563
Процент невыполненных запросов: 0,31%

Процентиль Яндекс.Танка

«Полка» RPS (верхняя граница — 350 запросов в секунду, включая «композитные» запросы — 167 динамических запросов в секунду).

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

Конфигурация 2 (2 сервера, «1С-Битрикс: Энтерпрайз»)

Время выполнения теста: 86 850 секунд
Число PHP-запросов в секунду: 265, при 74 одновременных потоках
99-процентиль: 0,95
Число просмотренных страниц 23 082 301
Процент невыполненных запросов: 0,47%
Коэффициент масштабирования по сравнению с конфигурацией 1: 1,60

Процентиль Яндекс.Танка

«Полка» RPS (включая «композитные» запросы — верхняя граница — 550 запросов в секунду).

Число запросов в секунду выросло не так сильно, как хотелось бы — в 1,6 раз. Важно помнить, что в многосерверной конфигурации добавляется межсерверное взаимодействие и дополнительный overhead на обмен данными.

Конфигурация 3 (4 сервера, «1С-Битрикс: Энтерпрайз»)

Время выполнения теста: 86 402 секунд
Число PHP-запросов в секунду: 535, при 136 одновременных потоках
99-процентиль: 0,9
Число просмотренных страниц: 46 256 141
Процент невыполненных запросов: 0,47%
Коэффициент масштабирования по сравнению с конфигурацией 2 — 2,00

Процентиль Яндекс.Танка

«Полка» RPS (включая «композитные» запросы — верхняя граница — 1100 запросов в секунду).

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

Итоги и дальнейшие планы

Этим тестированием мы старались задать некий эталон, на который могут ориентироваться разработчики при оценке производительности своих систем. Для нас очень важным результатом стало подтверждение высокой эффективности горизонтального масштабирования «1С-Битрикс»: использование четырех серверов вместо двух и дало двукратный прирост. Ну и, конечно, приятная метрика — 167 запросов на динамике в сложной системе на одном сервере.

Теперь мы планируем провести тест уже в открытой системе, чтобы выяснить для себя следующие моменты:

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

Мы обязательно расскажем о результатах этого теста и вынесенном опыте.

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

Подробный отчет о нагрузочном тестировании 1С-Битрикс
Доклад Алексея Лавренюка о Яндекс.Танк в рамках конференции FailOver Conference 2015
Тюнинг JMeter

sohabr.net

Нагрузочное тестирование CMS «1С-Битрикс» / Блог компании 1С-Битрикс / Хабр

Постановка задачи

Многие по разному понимают смысл, цель и задачи нагрузочного тестирования.

Для начала, нужно сформулировать для себя — чего же мы хотим?

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

60% пользователей приходят и просматривают несколько страниц в каталоге, зная, какой конкретно товар им нужен.
37% пользователей выбирают нужный товар из нескольких возможных, применяют фильтрацию (smart-фильтр).
3% пользователей (стандартный показатель хорошей конверсии) положили товар в корзину и купили его.

1) 1 сервер. «1С-Битрикс: Управление сайтом», web и MySQL работают на одном сервере

3) четыре сервера. Вариант, в котором вторая конфигурация горизонтально отмасштабирована slave-машиной.

Тестирование

В ретроспективе тестирование можно разбить на три этапа.

односерверная конфигурация: 34 потока
конфигурация из двух серверов: 74 потока
конфигурация из четырех серверов: 136 потоков

На этом этапе мы столкнулись с рядом сложностей. Из опыта их преодоления мы вынесли ряд уроков:

Организуя нагрузочное тестирование, помните, что первый большой прогон теста будет далек от идеальных результатов. Возможно, вы что-то забудете в конфигурации ОС и софта сервера. Возможно, будут проблемы с самой системой тестирования (JMeter — это Java-приложение, со свойственными ему проблемами со сборкой мусора). Ну и главное — вы увидите тонкие места в своей системе, которые ранее не замечали и которые можно будет исправить. Например, в рамках нашего тестирования были обнаружены девять значимых багов, исправления которых выйдут в ближайших версиях продукта. Так что рассматривайте свой первый тест как инструкцию к оптимизации.
Несколько очевидная вещь, которую однако стоит проговорить: во время оптимизации все изменения конфигурации на серверах должны фиксироваться. В идеале не применяйте больше, чем несколько изменений за раз. Иначе будет трудно выяснить, какое же именно действие привело к улучшению производительности.
Суточное тестирование при наличии любой, не обнаруженной сразу ошибки — это потерянный день работы. После одной из итераций, когда мы внесли ряд изменений в конфигурацию, получили хорошие результаты и были тому обрадованы. Но потом обнаружили, что был отключен третий сценарий — оформление заказов пользователей, самый тяжелый в нашем случае. Пришлось запускать тестирование заново. Через сутки выяснили, что примененные изменения не ускоряют систему.
Система под нагрузочным тестом — это продакшн-система, и с ней могут случится все те же типовые проблемы, которые происходят на продакшн-сайтах. У нас в одном из тестов, через 12 часов после запуска, на одном из серверов закончилось место. Поэтому жизненно необходимо поставить стандартные оповещения о проблемах на сайте в своей привычной системе мониторинга, чтобы они приходили вам на телефон. И при получении нужно немедленно бежать исправлять ситуацию, чтобы не потерять уже собранные драгоценные данные.
Хорошие результаты чаще всего означают ошибки в тестировании. В одной из итераций мы получили двукратный прирост по сравнению с предыдущим тестом. Оказалось, что MySQL «вылетал» по max connections, а сайт в таких ситуация отвечал валидным для системы тестирования кодом HTTP 200.
В любом тестировании очень важна «бюрократия»: делайте максимально подробное описание проведённого теста — сценарии, конфигурацию системы, логи тестирования и т.д. Все это будет полезно для последующего анализа.

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

Конфигурация 1 (1 сервер, «1С-Битрикс: Управление Сайтом», редакция «Бизнес»)

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

Число PHP-запросов в секунду: 167, при 34 одновременных потоках
99-процентиль: 0,366 мс.
Число просмотренных страниц: 14 421 563
Процент невыполненных запросов: 0,31%

Процентиль Яндекс.Танка

Конфигурация 2 (2 сервера, «1С-Битрикс: Энтерпрайз»)

Время выполнения теста: 86 850 секунд
Число PHP-запросов в секунду: 265, при 74 одновременных потоках
99-процентиль: 0,95
Число просмотренных страниц 23 082 301
Процент невыполненных запросов: 0,47%
Коэффициент масштабирования по сравнению с конфигурацией 1: 1,60

Процентиль Яндекс.Танка

«Полка» RPS (включая «композитные» запросы — верхняя граница — 550 запросов в секунду).

Конфигурация 3 (4 сервера, «1С-Битрикс: Энтерпрайз»)

Время выполнения теста: 86 402 секунд
Число PHP-запросов в секунду: 535, при 136 одновременных потоках
99-процентиль: 0,9
Число просмотренных страниц: 46 256 141
Процент невыполненных запросов: 0,47%
Коэффициент масштабирования по сравнению с конфигурацией 2 — 2,00

Процентиль Яндекс.Танка

«Полка» RPS (включая «композитные» запросы — верхняя граница — 1100 запросов в секунду).

Итоги и дальнейшие планы

Теперь мы планируем провести тест уже в открытой системе, чтобы выяснить для себя следующие моменты:

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

Мы обязательно расскажем о результатах этого теста и вынесенном опыте.

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

Подробный отчет о нагрузочном тестировании 1С-Битрикс
Доклад Алексея Лавренюка о Яндекс.Танк в рамках конференции FailOver Conference 2015
Тюнинг JMeter

mhabr.win

Как 1С-Битрикс справляется с высокими нагрузками?

В этой статье мы рассмотрим, как система управления 1С-Битрикс справляется с большими нагрузками.

Данный вопрос особенно актуален сегодня, когда электронная торговля начинает конкурировать по обороту с традиционными продажами в офлайне, когда качество веб-сайта стало определяться скоростью его работы и отказоустойчивостью. Как следствие, при разработке интернет-проекта всё чаще возникают вопросы: Какую CMS использовать? Брать готовое решение или писать «с нуля»? Как выбрать разработчика с компетенцией по высоконагруженной разработке?

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

Мы живём в 21-ом веке — это время, когда есть готовые решения, которые отвечают всем требованиям рынка. Большая часть игроков, в том числе владельцы крупных проектов, выбирают CMS 1С-Битрикс. Какие же причины для этого?

Для начала давайте разберёмся, что такое «высокие нагрузки»?

Высокие нагрузки (highload)

Часто в термин «высокие нагрузки» (highload) вкладывают различный смысл, но в общем смысле среднестатистический владелец сайта ставит знак равенства между высокими нагрузками и высокой надёжностью.

Нагрузки могут формироваться следующими источниками:

Количеством посетителей. Обычному хостингу хватает 100 человек в день, чтобы начать «тормозить»
Нагрузкой на базу данных. К примеру, в интернет-магазине с огромным товарным ассортиментом при построении умного фильтра нужно сделать большое количество обращений к базе данных для создания выборки. Как правило нагрузки на базу данных лечатся с помощью одной из ключевых стратегий масштабирования — кеширования информации. Благодаря кешированию удается значительно уменьшить число повторяющихся запросов к базе данных и исключить повторяющиеся ресурсоемкие вычисления.
Ошибками в программном коде. К примеру, у вас 1000 хитов в сутки; ошибка, которая затрагивает 0,1% запросов, будет появляться 1 раз в день (1 запись в error.log) — что не страшно. Но когда у вас будет 100 000 хитов в сутки, то вы будете получать уже в 100 раз больше ошибок, что недопустимо для сайта, т.к. создаст дополнительную нагрузку.

Серверная инфраструктура

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

К примеру, большинство обычных хостингов (nic.ru, рег.ру, и др.) при запросе «На какую нагрузку вы рассчитаны», отвечают — 100 человек в день.

Если использовать виртуальную машину 1С-Битрикс, то можно добиться посещаемости в тысячи пользователей без особых проблем.

Решение «Веб-кластер» позволяет легко масштабировать систему, распределяя нагрузку на необходимое количество серверов.

Какое решение можно предложить?

Готовое решение «из коробки» для магазина, которое сразу оптимизировано под высокие нагрузки.

В итоге, если нужен движок сразу из коробки, оптимизированный под высокие нагрузки — берите 1С-Битрикс.

Сам по себе 1C-Битрикс давно зарекомендовал себя как надёжная корпоративная система. Почти все самые посещаемые сайты в рунете разработаны на этой системе управления.

Для того, чтобы предоставить гарантии клиентам в плане производительности и отказоустойчивости, компания 1С-Битрикс в 2015 году провела нагрузочное тестирование.

Нагрузочное тестирование CMS 1C-Битрикс

Готовый интернет-магазин на продукте «1С-Битрикс: Управление сайтом» (редакция «Бизнес»), содержащий до 99280 SKU и размещенный на одном типовом сервере, способен обслужить за сутки:

до 779 991 уникальных сессий;
до 14 781 832 просмотров страниц;
до 29 635 заказов.

Готовый интернет-магазин на продукте «1С-Битрикс: Энтерпрайз», содержащий 99280 SKU и размещенный на кластере из двух типовых серверов, способен обслужить за сутки:

до 1 214 858 уникальных сессий;
до 23 082 301 просмотров страниц;
до 46 436 заказов.

При тестировании использовалась технология Яндекс.Танк, версия 1.7.10. Yandex.Tank выбрана как надежная, зарекомендовавшая себя система, которая позволяет, на наш взгляд, предоставить наиболее подробные данные по проведенному тестированию. Результаты тестирования Yandex.Tank проверены во множестве проведенных нагрузочных тестирований компанией Яндекс и признаются независимыми экспертами. Подробнее: http://www.1c-bitrix.ru/products/cms/performance/

Устойчивость 1С-Битрикс к высоким нагрузкам можно доказать тем, что большинство популярных сайтов рунета сделано на данной системе управления (Евросеть, МТС, Государственная Дума, sapato.ru, Эльдорадо, Связной и др.)

Выводы:

Для высоконагруженного интернет-магазина лучше взять CMS 1С-Битрикс. По мимо большого количества готового функционала, вы получите высокопроизводительную систему (это подтверждено исследованиями и нагрузочным тестированием). Это лучше (как минимум надежнее и дешевле), чем писать аналогичную систему с нуля.
Не надо задумываться об отдельных составляющих программного кода, все компоненты и модули из коробки будут отлично работать при высоких нагрузках.
Для серверного веб-окружения достаточно «1С-Битрикс: Виртуальная машина». Ставим из коробки и пользуемся. Если нужны ещё мощности, можно быстро масштабироваться в кластер. Это очень сильно сократит затраты на подготовку веб-окружения и исключит человеческий фактор.
Не забываем про качество кода. Не стоит экономить на уровне разработчиков, потом заплатите намного больше за рефакторинг.
Дополнительные решения «Композитный сайт», использование платформы «1С-Битрикс: Энтерпрайз» позволит кардинально уменьшить время отклика и эффективно масштабироваться по числу серверов.

Диагностика устойчивости к высоким нагрузкам

Как проверить, справляется ли мой сайт с большими нагрузками?

В 1С-Битрикс встроены специальные инструменты для оценки производительности конфигурации, платформы «1С-Битрикс» и качества разработки интернет-проекта. А кроме того система автоматически производит диагностику работы и выдает рекомендации по улучшению производительности.

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

klondike-studio.ru

Нагрузочное тестирование 1С-Битрикс. методика проведения, специфика, как провести самим

Home
Internet
Нагрузочное тестирование 1С-Битрикс. методика проведения, специфика, как провести самим

Published on16-Apr-2017
View183
Download2

DESCRIPTION

PowerPoint Presentation Нагрузочное тестирование «1С-Битрикс»: методика проведения, специфика, как провести…

Transcript

PowerPoint Presentation Нагрузочное тестирование «1С-Битрикс»: методика проведения, специфика, как провести самим? Евгений Потапов ITSumma Партнерская конференция «1С-Битрикс» 1 О себе | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Евгений Потапов генеральный директор компании ITSumma Круглоcуточное удаленное администрирование серверов и техническая поддержка сайтов 100 миллионов уникальных посетителей в сутки Штат – 50 человек 2 О нас | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ На поддержке: 3 Содержание Цели и задачи тестирования Виды нагрузочных тестирований Чем тестировать - инструментарий Проведение теста «коробки» - архитектура, сценарии, проблемы Результаты тестирования Куда стремиться дальше? | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 4 Цели и задачи тестирования «Сколько посетителей может выдержать мой сервер? Я могу купить больше рекламы»? «Мы сейчас выдерживаем 100 запросов в секунду – это много или мало»? «Мне наш сисадмин говорит что можно выдерживать 500 одновременных соединений на нашем сервере» | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Типичные вопросы в разработке и эксплуатации: 1. Проверить максимальную производительность магазина со 100 000 SKU на стандартном оборудовании 5 Цели и задачи тестирования «Если мы возьмем второй сервер - мы сможем выдерживать нагрузку в два раза больше»? «Мы можем добавлять новые серверы до бесконечности»? «Вообще – кластер это эффективно?» | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 2. Проверить масштабируемость от 1 до 4 серверов 6 Цели и задачи тестирования Максимальное среднее число запросов в секунду в течение 24 часов Максимальное число просмотров страниц в течение 24 часов Максимальное число совершенных заказов в течение 24 часов | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 3. Получить 3 результата нагрузочного тестирования – для 1, 2 и 4-х серверной конфигурации 7 Цели и задачи тестирования | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 4. Подбор оптимальной конфигурации ПО и рекомендации по эксплуатации высоконагруженных проектов Оптимальная конфигурация серверного ПО Тестирование эффективности и оптимизация схемы БД Предложения для оптимизации 1С-Битрикс: Виртуальная машина и 1С-Битрикс: Веб-окружение 8 Как тестировать? Виды нагрузочного тестирования Закрытая модель – постоянная искусственная статическая нагрузка – «пользователи» идут равномерно, нагрузка со временем не меняется. Цель – понять максимальную производительность. Открытая модель – «пользователи» приходят волнами, иногда – с нагрузкой выше чем может справиться сервер. Цель – понять поведение в критических ситуациях в реальном мире. | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Закрытая и открытая модель нагрузочного тестирования 9 Виды нагрузочного тестирования Закрытая модель (нужна максимальная эталонная производительность) Тестирование длиной 24 часа 100 000 SKU Конфигурация: 1С-Битрикс: Управление сайтом – 1 сервер, 1С-Битрикс: Enterprise – 2 сервера, 1С-Битрикс: Enterprise – 4 сервера Выполнение SLA | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Параметры тестирования 10 Виды нагрузочного тестирования 99% динамических запросов должны быть выполнены быстрее 1000мс Число ответов не-HTTP-200 должно быть не более 0.5% | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Параметры тестирования - SLA 11 Инструментарий Яндекс.Танк (https://tech.yandex.ru/tank/ ) JMeter (http://jmeter.apache.org/ ) Серверы в Selectel - Intel Xeon E3-1270v3 3.5 ГГц, 32 ГБ, 2 × 240 ГБ SSD - 8800 р. (отдельный сервер под танк) | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 12 Сценарии тестирования 60% - просмотр каталога 37% - умный фильтр, выбор товара 3% - добавление товара в корзину и оформление заказа | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 13 Аппаратное обеспечение и конфигурация Intel Xeon E3-1270v3 3.5 ГГц, 32 ГБ оперативной памяти, 2 × 240 ГБ SSD диски в software RAID 1 1 сервер – «источник атаки» с Яндекс.Танком Серверы с 1С-Битрикс: 1С-Битрикс: Веб-окружение + PHP 5.6 | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 14 Аппаратное обеспечение и конфигурация | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Конфигурация из 1 сервера 15 Аппаратное обеспечение и конфигурация | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Конфигурация из 2 и 4 серверов 16 Тестирование — этапы Первый этап – «примерочная стрельба» Второй этап – первые запуски полноценных тестов, тюнинг, грабли Третий этап – стабильные тесты, фиксация результатов | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 17 Тестирование – «примерочная стрельба» Проверка конфигурации системы тестирования Исправление ошибок конфигурации, сценариев Подбор параметров для максимальной нагрузки при заданном SLA Первый тюнинг системы Фиксация параметров при заданном SLA | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 18 Тестирование – «примерочная стрельба» Односерверная конфигурация: 34 потока Конфигурация из двух серверов: 74 потока Конфигурация из четырех серверов: 136 потоков | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 19 Тестирование – первые полноценные запуски - грабли | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Первый большой «прогон» - обязательно будут не очень хорошие результаты Проблемы с конфигурацией сервера Проблемы с конфигурацией сайта Неоптимальные решения в конфигурации сайта Проблемы с системой тестирования Первые запуски – инструкция к оптимизации 20 Тестирование – первые полноценные запуски - грабли | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Все изменения конфигурации и оптимизации должны фиксироваться Изменения в конфигурационных файлах Изменения в настройках системы/сайта Одно изменение за раз 21 Тестирование – первые полноценные запуски - грабли | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Тестирование длиной в 24 часа – постоянный контроль Мониторинг серверов под нагрузкой (хватает места, отвечает сайт) Мониторинг сервера с системой тестирования “Ручной контроль” Слишком хорошие результаты – чаще всего – что-то не работает 22 Тестирование – первые полноценные запуски - грабли | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Бюрократия Сохранение конфигураций тестирования Сохранение «сырых» результатов тестирования Сохранение всех конфигураций, БД и кода 23 Тестирование – результаты | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Результаты тестирования – 1 сервер (1С-Битрикс: Управление Сайтом, редакция Бизнес) Время выполнения теста: 86892 секунд Число PHP запросов в секунду: 167, при 34 одновременных потоках 99-процентиль: 0,366мс. Число просмотренных страниц: 14 421 563 Процент невыполненных запросов: 0.31% 24 Тестирование – результаты | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Результаты тестирования – 1 сервер 99-процентиль 25 Тестирование – результаты | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Результаты тестирования – 1 сервер 26 Тестирование – результаты | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Результаты тестирования – 2 сервера (1С-Битрикс: Enterprise). Время выполнения теста: 86850 секунд Число PHP запросов в секунду: 265, при 74 одновременных потоках 99-процентиль: 0,950мс Число просмотренных страниц 23 082 301 Процент невыполненных запросов: 0.47% Коэффициент масштабирования по сравнению с конфигурацией 1: 1.60 27 Тестирование – результаты | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Результаты тестирования – 2 сервера 99-процентиль 28 Тестирование – результаты | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Результаты тестирования – 2 сервера 29 Тестирование – результаты | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Результаты тестирования – 4 сервера (1С-Битрикс: Enterprise). Время выполнения теста: 86402 секунд Число PHP запросов в секунду: 535, при 136 одновременных потоках 99-процентиль: 0,900мс Число просмотренных страниц: 46 256 141 Процент невыполненных запросов: 0.47% Коэффициент масштабирования по сравнению с конфигурацией 2 - 2.00 30 Тестирование – результаты | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Результаты тестирования – 4 сервера 99-процентиль 31 Тестирование – результаты | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Результаты тестирования – 4 сервера 32 Тестирование – итоги и планы | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Есть «эталон» и метрики Есть понимание перспектив масштабирования Хочется: тест в открытой модели – понять поведение системы в критических условиях, восстановление после сверхвысокой нагрузки 33 Тестирование проводилось в мае 2015 г. Информация о результатах теста: http://www.1c-bitrix.ru/products/cms/performance/#tab-test-link Подробный отчет - http://www.1c-bitrix.ru/download/manuals/ru/1cbitrix_tests_2015.pdf | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ Информация о тестировании 34 Контакты Евгений Потапов http://itsumma.ru [email protected] http://facebook.com/eapotapov | ПАРТНЕРСКАЯ КОНФЕРЕНЦИЯ 35

documents.tips

Нагрузочное тестирование CMS "1С-Битрикс"

Знаете анекдот про самолет, в котором есть и бар, и бассейн, и ресторан, но только при взлете стюардесса говорит: "А теперь со всем этим мы попробуем взлететь"?

Веб-разработка немного похожа на такой самолет.Заказчик хочет от веб-студии и классный дизайн, и кучу интерактива, и все службы доставки и оплаты в интернет-магазины, студия с удовольствием все это программирует... А вот хватит ли мощностей сервера на обеспечение стабильной работы сайта - непонятно. Чтобы нагрузка была прогнозируемой, чтобы задать некоторые эталонные значения, мы провели нагрузочное тестирование "1С-Битрикс: Управление сайтом" и "1С-Битрикс: Энтерпрайз".

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

Многие по разному понимают смысл, цель и задачи нагрузочного тестирования.

Для начала, нужно сформулировать для себя - чего же мы хотим?

Какой продукт и в каком виде тестировать? Сначала мы хотели взять реально существующий интернет-магазин, его код и базу. Но это было бы тестирование именно этого решения, другие разработчики не смогут использовать его в качестве точки отсчета. Значит, тестировать надо стандартную "коробку", заполнив ее большим количеством позиций, соответствующим крупному интернет-магазину (по нашему опыту, это около 100 000 SKU)."1С-Битрикс" работал с включенной технологией "Композитного кэша" - решения, которое сначала подгружает быстрый кэш сохраненной страницы из nginx, а следом - ajax-запросом подгружает динамические данные. Таким образом, пользователь получает страницу максимально быстро. Для оценки числа запросов в секунду мы считали именно динамические запросы.

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

Какие нужно создать сценарии нагрузки? По результатам анализа нагрузки на ряд крупных магазинов, трафик интернет-магазина можно разделить на 3 категории: 60% пользователей приходят и просматривают несколько страниц в каталоге, зная, какой конкретно товар им нужен. 37% пользователей выбирают нужный товар из нескольких возможных, применяют фильтрацию (smart-фильтр). 3% пользователей (стандартный показатель хорошей конверсии) положили товар в корзину и купили его.

Как именно нагружать серверы? Существует две основных модели нагрузочного тестирования проекта: закрытая и открытая. Закрытая подразумевает собой искусственную постоянную статичную нагрузку, в которой запросы "пользователей" идут статичным потоком (а не волнами, как в реальной жизни). Ее цель - выяснить поведение проекта при максимуме нагрузки, понять максимальную "пропускную способность" системы. Это верхняя планка метрики, выше нее уже не подняться.

Какой SLA выбрать для тестирования? Нам нужно было четко обозначить для себя тот порог, ниже которого мы считаем систему стабильно обслуживающей запросы. Для этого мы воспользовались статистикой ТОП-100 крупных интернет-магазинов (по версии издания "Коммерсант", 2014 г.) и выбрали две главные метрики: ответ на 99% запросов должен быть дан меньше чем за 1 секунду, а число ответов с кодом, отличным от HTTP 200, должно быть не более 0,5%. Тестирование должно вестись непрерывно в течение 24 часов.

Какой хостинг выбрать? В качестве площадки для тестирования мы выбрали хостинг Selectel с дата-центром "Цветочная-1" в Санкт-Петербурге. Selectel предоставил нам серверы самой популярной своей конфигурации - Intel Xeon E3-1270v3 3,5 ГГц, 32 Гб оперативной памяти, 2 x 240 Гб SSD-накопители в RAID 1. Один из серверов был использован как центр нагрузки, остальные, в разных конфигурациях "1С-Битрикс", мы использовали для тестирования.

Конфигурация системы В рамках тестирования серверы работали на ОС Linux CentOS 6.6 с установленным на нем пакетом "1С-Битрикс: Веб-окружение", подробнее о нем можно почитать здесь.

1) 1 сервер."1С-Битрикс: Управление сайтом", web и MySQL работают на одном сервере

2) 2 сервера."1С-Битрикс: Энтерпрайз", балансировщик nginx на первом сервере, web-application на обоих серверах, MySQL мастер и запись/чтение в него - на первом сервере, MySQL slave и чтение из него - на втором сервере

3) четыре сервера. Вариант, в котором вторая конфигурация горизонтально отмасштабирована slave-машиной.

Чем тестировать? В качестве средства тестирования был выбран Яндекс.Танк. Яндекс.Танк позволяет использовать две системы генерации нагрузки - Phantom и JMeter. Phantom превосходит JMeter в плане производительности, однако не позволяет генерировать POST-логику, сохранение и последующее использование куков. По этой причине мы генерировали нагрузку с помощью JMeter.

Кто тестирует? Нам хотелось, чтобы тестирование провела независимая компания, мнению которой могли бы доверять и мы, и сторонние компании, и эксперты индустрии. Это задачу мы доверили компании ITSumma, которая с 2008 года занимается круглосуточным администрированием и технической поддержкой известных в Рунете проектов и зарекомендовала себя на рынке. Ее сотрудники являются постоянными докладчиками профильных конференций (таких как Highload, РИТ++ и др.). Тестирование

В ретроспективе тестирование можно разбить на три этапа.

Первый этап - примерочная стрельба, в рамках которой мы подбирали максимальное число потоков, при котором будет сохраняться SLA: односерверная конфигурация: 34 потока конфигурация из двух серверов: 74 потока конфигурация из четырех серверов: 136 потоков

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

На этом этапе мы столкнулись с рядом сложностей. Из опыта их преодоления мы вынесли ряд уроков: Организуя нагрузочное тестирование, помните, что первый большой прогон теста будет далек от идеальных результатов. Возможно, вы что-то забудете в конфигурации ОС и софта сервера. Возможно, будут проблемы с самой системой тестирования (JMeter - это Java-приложение, со свойственными ему проблемами со сборкой мусора). Ну и главное - вы увидите тонкие места в своей системе, которые ранее не замечали и которые можно будет исправить. Например, в рамках нашего тестирования были обнаружены девять значимых багов, исправления которых выйдут в ближайших версиях продукта. Так что рассматривайте свой первый тест как инструкцию к оптимизации. Несколько очевидная вещь, которую однако стоит проговорить: во время оптимизации все изменения конфигурации на серверах должны фиксироваться. В идеале не применяйте больше, чем несколько изменений за раз. Иначе будет трудно выяснить, какое же именно действие привело к улучшению производительности. Суточное тестирование при наличии любой, не обнаруженной сразу ошибки - это потерянный день работы. После одной из итераций, когда мы внесли ряд изменений в конфигурацию, получили хорошие результаты и были тому обрадованы. Но потом обнаружили, что был отключен третий сценарий - оформление заказов пользователей, самый тяжелый в нашем случае. Пришлось запускать тестирование заново. Через сутки выяснили, что примененные изменения не ускоряют систему. Система под нагрузочным тестом - это продакшн-система, и с ней могут случится все те же типовые проблемы, которые происходят на продакшн-сайтах. У нас в одном из тестов, через 12 часов после запуска, на одном из серверов закончилось место. Поэтому жизненно необходимо поставить стандартные оповещения о проблемах на сайте в своей привычной системе мониторинга, чтобы они приходили вам на телефон. И при получении нужно немедленно бежать исправлять ситуацию, чтобы не потерять уже собранные драгоценные данные. Хорошие результаты чаще всего означают ошибки в тестировании. В одной из итераций мы получили двукратный прирост по сравнению с предыдущим тестом. Оказалось, что MySQL "вылетал" по max connections, а сайт в таких ситуация отвечал валидным для системы тестирования кодом HTTP 200. В любом тестировании очень важна "бюрократия": делайте максимально подробное описание проведённого теста - сценарии, конфигурацию системы, логи тестирования и т.д. Все это будет полезно для последующего анализа.

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

Конфигурация 1 (1 сервер,"1С-Битрикс: Управление Сайтом", редакция "Бизнес")

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

Число PHP-запросов в секунду: 167, при 34 одновременных потоках 99-процентиль: 0,366 мс. Число просмотренных страниц: 14 421 563 Процент невыполненных запросов: 0,31%

Процентиль Яндекс.Танка

"Полка" RPS (верхняя граница - 350 запросов в секунду, включая "композитные" запросы - 167 динамических запросов в секунду).

Конфигурация 2 (2 сервера,"1С-Битрикс: Энтерпрайз") Время выполнения теста: 86 850 секунд Число PHP-запросов в секунду: 265, при 74 одновременных потоках 99-процентиль: 0,95 Число просмотренных страниц 23 082 301 Процент невыполненных запросов: 0,47% Коэффициент масштабирования по сравнению с конфигурацией 1: 1,60

Процентиль Яндекс.Танка

"Полка" RPS (включая "композитные" запросы - верхняя граница - 550 запросов в секунду).

Число запросов в секунду выросло не так сильно, как хотелось бы - в 1,6 раз. Важно помнить, что в многосерверной конфигурации добавляется межсерверное взаимодействие и дополнительный overhead на обмен данными.

Конфигурация 3 (4 сервера,"1С-Битрикс: Энтерпрайз") Время выполнения теста: 86 402 секунд Число PHP-запросов в секунду: 535, при 136 одновременных потоках 99-процентиль: 0,9 Число просмотренных страниц: 46 256 141 Процент невыполненных запросов: 0,47% Коэффициент масштабирования по сравнению с конфигурацией 2 - 2,00

Процентиль Яндекс.Танка

"Полка" RPS (включая "композитные" запросы - верхняя граница - 1100 запросов в секунду).

А вот здесь - отличный результат по масштабированию. Добавив еще два сервера к двухсерверной конфигурации, мы получили двукратный же прирост в производительности. Этот результат говорит о том, что вы не упретесь в вертикальные пределы "железа", дополнительные серверы позволят адекватно распределить нагрузку между машинами. Итоги и дальнейшие планы

Этим тестированием мы старались задать некий эталон, на который могут ориентироваться разработчики при оценке производительности своих систем. Для нас очень важным результатом стало подтверждение высокой эффективности горизонтального масштабирования "1С-Битрикс": использование четырех серверов вместо двух и дало двукратный прирост. Ну и, конечно, приятная метрика - 167 запросов на динамике в сложной системе на одном сервере.

Теперь мы планируем провести тест уже в открытой системе, чтобы выяснить для себя следующие моменты: Что происходит с системой после достижения ее пределов в рамках одного сервера, что можно в ней оптимизировать? Как быстро система восстановится после сверхвысокой нагрузки? Как получить такой инструментарий, чтобы разработчики могли оценить реальное число пользователей, которое может обслужить созданный ими проект на текущем оборудовании?

Мы обязательно расскажем о результатах этого теста и вынесенном опыте.

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

Подробный отчет о нагрузочном тестировании 1С-Битрикс Доклад Алексея Лавренюка о Яндекс.Танк в рамках конференции FailOver Conference 2015 Тюнинг JMeter

voozl.com

Нагрузочное тестирование CMS «1С-Битрикс» - PCNEWS.RU

Веб-разработка немного похожа на такой самолет. Заказчик хочет от веб-студии и классный дизайн, и кучу интерактива, и все службы доставки и оплаты в интернет-магазины, студия с удовольствием все это программирует… А вот хватит ли мощностей сервера на обеспечение стабильной работы сайта — непонятно.Чтобы нагрузка была прогнозируемой, чтобы задать некоторые эталонные значения, мы провели нагрузочное тестирование »1С-Битрикс: Управление сайтом» и »1С-Битрикс: Энтерпрайз».

Постановка задачи

Многие по разному понимают смысл, цель и задачи нагрузочного тестирования.

Для начала, нужно сформулировать для себя — чего же мы хотим?

Какой продукт и в каком виде тестировать? Сначала мы хотели взять реально существующий интернет-магазин, его код и базу. Но это было бы тестирование именно этого решения, другие разработчики не смогут использовать его в качестве точки отсчета. Значит, тестировать надо стандартную «коробку», заполнив ее большим количеством позиций, соответствующим крупному интернет-магазину (по нашему опыту, это около 100 000 SKU).»1С-Битрикс» работал с включенной технологией «Композитного кэша» — решения, которое сначала подгружает быстрый кэш сохраненной страницы из nginx, а следом — ajax-запросом подгружает динамические данные. Таким образом, пользователь получает страницу максимально быстро. Для оценки числа запросов в секунду мы считали именно динамические запросы.

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

60% пользователей приходят и просматривают несколько страниц в каталоге, зная, какой конкретно товар им нужен.
37% пользователей выбирают нужный товар из нескольких возможных, применяют фильтрацию (smart-фильтр).
3% пользователей (стандартный показатель хорошей конверсии) положили товар в корзину и купили его.

Какой хостинг выбрать? В качестве площадки для тестирования мы выбрали хостинг Selectel с дата-центром «Цветочная-1» в Санкт-Петербурге. Selectel предоставил нам серверы самой популярной своей конфигурации — Intel Xeon E3–1270v3 3,5 ГГц, 32 Гб оперативной памяти, 2 × 240 Гб SSD-накопители в RAID 1. Один из серверов был использован как центр нагрузки, остальные, в разных конфигурациях »1С-Битрикс», мы использовали для тестирования.

Конфигурация системыВ рамках тестирования серверы работали на ОС Linux CentOS 6.6 с установленным на нем пакетом »1С-Битрикс: Веб-окружение», подробнее о нем можно почитать здесь.

1) 1 сервер.»1С-Битрикс: Управление сайтом», web и MySQL работают на одном сервере

2) 2 сервера.»1С-Битрикс: Энтерпрайз», балансировщик nginx на первом сервере, web-application на обоих серверах, MySQL мастер и запись/чтение в него — на первом сервере, MySQL slave и чтение из него — на втором сервере

3) четыре сервера. Вариант, в котором вторая конфигурация горизонтально отмасштабирована slave-машиной.

Кто тестирует? Нам хотелось, чтобы тестирование провела независимая компания, мнению которой могли бы доверять и мы, и сторонние компании, и эксперты индустрии. Это задачу мы доверили компании ITSumma, которая с 2008 года занимается круглосуточным администрированием и технической поддержкой известных в Рунете проектов и зарекомендовала себя на рынке. Ее сотрудники являются постоянными докладчиками профильных конференций (таких как Highload, РИТ++ и др.).

Тестирование

В ретроспективе тестирование можно разбить на три этапа.

односерверная конфигурация: 34 потока
конфигурация из двух серверов: 74 потока
конфигурация из четырех серверов: 136 потоков

На этом этапе мы столкнулись с рядом сложностей. Из опыта их преодоления мы вынесли ряд уроков:

Организуя нагрузочное тестирование, помните, что первый большой прогон теста будет далек от идеальных результатов. Возможно, вы что-то забудете в конфигурации ОС и софта сервера. Возможно, будут проблемы с самой системой тестирования (JMeter — это Java-приложение, со свойственными ему проблемами со сборкой мусора). Ну и главное — вы увидите тонкие места в своей системе, которые ранее не замечали и которые можно будет исправить. Например, в рамках нашего тестирования были обнаружены девять значимых багов, исправления которых выйдут в ближайших версиях продукта. Так что рассматривайте свой первый тест как инструкцию к оптимизации.
Несколько очевидная вещь, которую однако стоит проговорить: во время оптимизации все изменения конфигурации на серверах должны фиксироваться. В идеале не применяйте больше, чем несколько изменений за раз. Иначе будет трудно выяснить, какое же именно действие привело к улучшению производительности.
Суточное тестирование при наличии любой, не обнаруженной сразу ошибки — это потерянный день работы. После одной из итераций, когда мы внесли ряд изменений в конфигурацию, получили хорошие результаты и были тому обрадованы. Но потом обнаружили, что был отключен третий сценарий — оформление заказов пользователей, самый тяжелый в нашем случае. Пришлось запускать тестирование заново. Через сутки выяснили, что примененные изменения не ускоряют систему.
Система под нагрузочным тестом — это продакшн-система, и с ней могут случится все те же типовые проблемы, которые происходят на продакшн-сайтах. У нас в одном из тестов, через 12 часов после запуска, на одном из серверов закончилось место. Поэтому жизненно необходимо поставить стандартные оповещения о проблемах на сайте в своей привычной системе мониторинга, чтобы они приходили вам на телефон. И при получении нужно немедленно бежать исправлять ситуацию, чтобы не потерять уже собранные драгоценные данные.
Хорошие результаты чаще всего означают ошибки в тестировании. В одной из итераций мы получили двукратный прирост по сравнению с предыдущим тестом. Оказалось, что MySQL «вылетал» по max connections, а сайт в таких ситуация отвечал валидным для системы тестирования кодом HTTP 200.
В любом тестировании очень важна «бюрократия»: делайте максимально подробное описание проведённого теста — сценарии, конфигурацию системы, логи тестирования и т.д. Все это будет полезно для последующего анализа.

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

Конфигурация 1 (1 сервер,»1С-Битрикс: Управление Сайтом», редакция «Бизнес»)

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

Число PHP-запросов в секунду: 167, при 34 одновременных потоках
99-процентиль: 0,366 мс.
Число просмотренных страниц: 14 421 563
Процент невыполненных запросов: 0,31%

Процентиль Яндекс.Танка

Конфигурация 2 (2 сервера,»1С-Битрикс: Энтерпрайз»)

Время выполнения теста: 86 850 секунд
Число PHP-запросов в секунду: 265, при 74 одновременных потоках
99-процентиль: 0,95
Число просмотренных страниц 23 082 301
Процент невыполненных запросов: 0,47%
Коэффициент масштабирования по сравнению с конфигурацией 1: 1,60

Процентиль Яндекс.Танка

«Полка» RPS (включая «композитные» запросы — верхняя граница — 550 запросов в секунду).

Конфигурация 3 (4 сервера,»1С-Битрикс: Энтерпрайз»)

Время выполнения теста: 86 402 секунд
Число PHP-запросов в секунду: 535, при 136 одновременных потоках
99-процентиль: 0,9
Число просмотренных страниц: 46 256 141
Процент невыполненных запросов: 0,47%
Коэффициент масштабирования по сравнению с конфигурацией 2 — 2,00

Процентиль Яндекс.Танка

«Полка» RPS (включая «композитные» запросы — верхняя граница — 1100 запросов в секунду).

Итоги и дальнейшие планы

Этим тестированием мы старались задать некий эталон, на который могут ориентироваться разработчики при оценке производительности своих систем. Для нас очень важным результатом стало подтверждение высокой эффективности горизонтального масштабирования »1С-Битрикс»: использование четырех серверов вместо двух и дало двукратный прирост. Ну и, конечно, приятная метрика — 167 запросов на динамике в сложной системе на одном сервере.

Теперь мы планируем провести тест уже в открытой системе, чтобы выяснить для себя следующие моменты:

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

Мы обязательно расскажем о результатах этого теста и вынесенном опыте.

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

Подробный отчет о нагрузочном тестировании 1С-Битрикс
Доклад Алексея Лавренюка о Яндекс.Танк в рамках конференции FailOver Conference 2015
Тюнинг JMeter

pcnews.ru