company_banner

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

    imageВесной этого года наша команда получила заказ на нагрузочное тестирование и оптимизацию нескольких версий CMS 1C-Битрикс. Прекрасная задача, но как ее делать? В этой статье мы поговорим о том, как правильно тестировать и что вообще означает “нагрузочное тестирование”? А в следующих — как мы тестировали Битрикс и что у нас получилось.

    Цели


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

    image

    Лирическое отступление. Несколько лет назад, проект “Рамблер-Фото”, проводится нагрузочное тестирование. Системные администраторы внимательно изучают поведение системы. Результат странный – большую часть времени система проводит в System Mode (это можно увидеть простой утилитой top). Это означает, что вместо выполнения кода проекта работает операционная система, тратя время на переключения контекста и выполнения системных вызовов.

    По результатам анализа (совместного с программистами) оказалось, что HTML::Mason (шаблонизатор, используемый в проекте Рамблер-Фото) при каждом запросе осуществляет нескольких десятков проверок наличия различных файлов “по умолчанию”. Одна директива в настройках HTML::Mason’а решила проблему.


    Как проводить?


    image

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

    Нагрузка дается на систему в совокупности!

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

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

    Как должен выглядеть поток пользователей? Ответ простой – максимально приближенный к реальным условиям. Самый лучший вариант — взять реальный сайт на 1С-Битрикс и реальные лог-файлы и, проанализировав их, составить:

    Профиль нагрузки

    Пользователи не только ходят по разным страницам, но и ходят по-разному. Беда любого крупного проекта — пользователи на модемах ;) Представьте себе — такой медленный вальяжный пользователь запрашивает страничку, подключается к тяжелому mod_php-серверу, сервер быстро-быстро ее обрабатывает и уже готов вернуть пользователю. И пользователь медленно-медленно начинает эту страничку забирать, например, со скоростью 1 килобайт в секунду. Таким образом при размере странички в 100 килобайт наш php-сервер будет занят 100 секунд, почти две минуты.

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

    image

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

    Соответственно, тестировать мы должны с учетом того, что часть пользователей у нас будет медленно забирать результат быстрой работы сервера:

    Нагрузочная система должна имитировать медленных пользователей

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

    За нагружаемой системой наблюдают все: тестировщики, администраторы и разработчики!

    О том, что мы должны получить в результате, что такое кривая деградации, как интерпретировать результаты и о том, как нас удивил 1С-Битрикс, мы поговорим в следующий раз.
    Конференции Олега Бунина (Онтико)
    628,27
    Конференции Олега Бунина
    Поделиться публикацией

    Комментарии 44

      +26
      Осталось ощущение незавершенности статьи. Замах широкий, а мяса как-то не хватает.
        +3
        Полностью согласен, нехватает описания того каким образом нагружался сервер, какая програмулина для этого использовалась. Мне бы было очень интересно…
          +3
          Все будет, это ж начало только. У нас с этим Битриксом очень длинная долгая история получилась, всю ее опишем.
            0
            ОК, ждем продолжения.
              +4
              ок, только не превращайте в санта-барбару…
            –1
            Все будет, это ж начало только. У нас с этим Битриксом очень длинная долгая история получилась, всю ее опишем.
          • НЛО прилетело и опубликовало эту надпись здесь
              +1
              … сколько раз с тексте звучит «1С-Битрикс», очевидно ведь :)
                0
                Тогда уж Рамблер-Фото — ему посвящено целых два абзаца ;)
                  0
                  Вы рассказали на примере Рамблер Фото, это понятно. Но казалось бы, причем здесь 1С-Битрикс, которое вы даже болдом выделили.
                    –2
                    Я написал же об этом в первом абзаце — мы получили заказ на нагрузочное тестирование этой системы и решили открыть в нашей компании новое направление.

                    Вот о том, как оно создавалось, как выбирался софт, как тестировалось, как интерпретировались результаты мы и будем рассказывать. Понятно, что ссылки на Битрикс будут — они же были подопытными ;)
                +1
                А если это не реклама, то Вас переклинит? ;)

                Мы рассказываем про свою услугу — нагрузочное тестирование, о том, как мы это делаем. Надеюсь, что кому-нибудь будет интересно.
                +1
                Судя по первой иллюстрации(Нагрузили->Посчитали...) Вы так и не смогли оптимизировать эту CMS :)
                  +12
                  не стоит так делать :(, жители хабрахабры не любят Бразильские телехабрасериалы.

                  шёл читать, для пополнения своих знаний, а оказалось фейк :(
                    0
                    ОК, учту. Я думал, что длинные посты читать лениво и лучше три-четыре маленьких.
                      +4
                      Если начали с «заказ на нагрузочное тестирование и оптимизацию нескольких версий CMS 1C-Битрикс», не стоит заканчивать «о том, как нас удивил 1С-Битрикс, мы поговорим в следующий раз».
                        +1
                        я бы разбил на 3-4
                        1 — базовая платформа базовый битрикс, провели те те и те тесты получили то то и то использовались такие такие и такие методы.
                        2-4 — детальный разбор каждого метода, пусть это будет eAcce… там ещё какая-то битриксовская феня, БД и т.п.
                        И статья бы получилась логически завершённая, и неплохая затравка для следующих постов.

                        мне как админу более десятка различных серверов, было бы очень интересно читать об этом, т.к. писать у меня не очень получается :(

                        А тут такое счастье, такая компания, которая живёт и дышит оптимизацией и хайлоадом, и такой пост :)) Не серьёзно…

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

                          0
                          Спасибо, учтем.
                      0
                      Очень во-время.
                      Спасибо.
                        0
                        очень вовремя что, извините? :)

                        О том, что проблему сначала лучше рассматривать в общем — мы вроде знали и до этого
                        +1
                        скажите хоть чем тестировали, сам почитаю.
                          +1
                          Начинали с самописных инструментов, закончили tsung'ом.
                            0
                            а можно вкратце рассказать, какие плюсы у tsung? или об этом будет следующий пост?
                              0
                              Я запросил сравнительную характеристику различных систем. Пока не знаю, как узнаю — опубликуем.
                          0
                          Воткнули надуманную схему, где одинаково выглядят электрический сигнал и PHP. Вставили банальные два абзаца про фронтэнд на nginx.

                          В чём суть-то?
                            +1
                            Я привел пять правил, мне казалось, что они далеко не всем понятны. Схема лишь для того, чтобы показать — при обработке даже самой простой страницы задействуется множество подсистем. У каждой из них есть свои буфера, свой кэш и свои ограничения.

                            Отсюда возникают различного рода «странности», например, почти одинаковая скорость чтения файла с диска и отдачи фрагмента памяти (файл положился в кэш файловой системы). Или отсутствие загрузки при молчании сервера (забита очередь на открытие TCP-соединений в сетевой подсистеме).

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

                            Или волшебный URL, который при выполнении вызывает коллапс всей системы. Одна из самых сложно уловимых ошибок.

                            Возможно, Вам все это понятно — я поздравляю Вас, коллега, на Хабре разная аудитория, возможно, для кого-то даже такие основы были интересны и полезны.
                            +1
                            Анекдот был про любителя бокса, который затарился пивом, раками, с друзьями собрались у телика, а Тайсон или кто там закончил бой в 30 секунд нокаутом.

                            Я к тому что статья должна быть самодостаточна. А то такое ощущение что кто-то тут SEO балуется.
                              +1
                              На днях попробовал OpenSource проект JMeter для создания тестовых нагрузок — очень понравился. Функционал даже больше чем в коммерческих продуктах которые доводилось использовать.
                                0
                                Там пока проект настроишь — охренеть можно. Потому и собираю свой велосипед понемножку.
                                0
                                лучше не торопится и подготовится к полной статье, а то получается так что начали хорошо, а когда и как завершится — не ясно.
                                  0
                                  Ок, учтем. Думаю, что следующую статью сделаем большой и подробной.
                                  0
                                  а зачем там вообще тяжелый апачи? если нгинкс с fast-cgi или fpm его полностью может заменить и заметно снизить нагрузку, плюс с легкостью позволяет горизонтально масштабировать проект
                                    0
                                    Fast-CGI процесс все равно занимает больше места в оперативной памяти, чем одно подключение в nginx. Я помню, как Игорь Сысоев бился за каждый килобайт — в результате он довел дело до смешных цифр — на одно соединение несколько десятков килобайт.
                                      0
                                      а вы сравните сколько памяти кушает nginx+fast-cgi и nginx+apache+mod_php — я не сранивал нгинкс и фаст цги, я спросил зачем там вообще апачи?
                                        0
                                        Предпочитаю лёгкий сервер + FastCGI, но иногда достаётся тяжёлое наследие в виде километрового htaccess с настолько извращёнными правилами mod_rewrite, в сравнении с которыми создатели «Техасской резни бензопилой» выглядят сопливыми малышами.
                                          0
                                          насколько мне известно нгинкс поддерживает в реврайтах регулярные выражения, и лучше 2 дня убить на перепись регулярок под нгинкс с апача, чем потом выгребать костыли…
                                            0
                                            Я же написал, что извращённые: с использованием %{REMOTE_USER}, %{QUERY_STRING} и прочих подобных параметров практически во всех правилах.
                                            Пока разберешься со всем этим зоопарком, работать такому «чуду» как-то же надо.
                                              0
                                              Вы все изменения делаете сразу на продакшене?
                                                0
                                                А вы разве нет?
                                                Шутка: разумеется, сначала всё обкатывается на staging-серверах и только затем деплоится на продакшен.
                                                В данном конкретном случае заморачиваться с переписыванием правил смысла не имело — там, помимо самих правил mod_rewite (их было около 2к! строк), всё было настолько грустно, что эффекта особого от этого мы бы не получили. Поэтому и воткнули nginx перед apache, который чаще лежал, чем работал, и за несколько месяцев переписали систему.

                                                Или в условиях хостинга — не будешь же каждому клиенту правила переписывать при тотальном увлечении ЧПУ.

                                                Так что решение nginx + apache в определённых случаях также имеет право на жизнь, хотя я и не являюсь его сторонником.
                                    0
                                    ты такой смешной ;)
                                      +1
                                      Олег, добавь пожалуйста в пассаж про Рамблер-Фото год, когда ты этим занимался. А то складывается впечатление, что ты для нас сейчас что-то делаешь, а это совсем не так.

                                      Спасибо.
                                      +1
                                      Начали за здравие, а кончили за упокой. «В следующий раз» — это через пол года?
                                        0
                                        Ну и где продолжение?

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

                                        Самое читаемое