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

Мы не ищем баги: что такое нагрузочное тестирование

Как узнать, не превратится ли ваш интернет-магазин в тыкву во время «чёрной пятницы» — когда трафик вырастет в 10 раз.

кадр из фильма «Зомби по имени Шон»

Давид Нариманидзе

Taode01 в Twitter. 28 лет. Полтора года в нагрузочном тестировании, куда перекатился из системного администрирования и любительской разработки мобильных приложений. В абсолютном восторге от работы, потому что это редкая возможность спасать компанию от лишних трат, а клиентов — от расходования совсем не казённых нервов. Да ещё и практически неограниченно развиваться самому: во время работы в НТ приходится и код писать, и железо подбирать, и взаимодействовать с большим количеством клёвых специалистов из других отделов.

Нагрузочное тестирование (НТ) — один из тестов производительности. От любой системы требуется быстро и правильно отвечать на запросы пользователей: и если правильность ответов относится скорее к функциональному тестированию, скорость является как раз заботой специалистов по нагрузочному тестированию. Однако формулировка «система должна отвечать быстро» — слабое требование.

Мне нравится определение из блога Miro на «Хабре»: «Нагрузочное тестирование — это тип тестирования, в котором мы проверяем, соответствует ли наша система поставленным нефункциональным требованиям к производительности при работе под высокой нагрузкой в различных сценариях».

В основе статьи — Twitter-тред автора.

Какими бывают нагрузочные тесты

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

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

Нефункциональное тестирование (НФ). Определяет характеристики ПО, которые измеряются в каких-то конкретных величинах. В первую очередь на таких тестах изучают производительность системы — проводят нагрузочное и стрессовое тестирование, исследуют стабильность и работу с большими базами данных. А после этого проверяют настройки, отказоустойчивость и восстановление системы, ищут способы увеличить её производительность. Тестирование производительности помогает узнать, как меняются стабильность и быстродействие системы под разной нагрузкой, а также проверить её масштабируемость, надёжность и уточнить, сколько ресурсов она будет использовать.

Тесты, связанные с изменениями. К этой категории относятся:

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

Методика нагрузочного тестирования (МНТ) — почти как Библия для нагрузочника. Это документ, в который необходимо вписать всё, что может случиться на проекте, учесть максимальное число сценариев и результаты тестов.

Чтобы обезопасить себя от факапов, в методике нужно сразу прописать значения всех терминов, чтобы потом не возникло недопонимания, которое обычно приводит к судам и нервотрёпке.

Я разрабатываю методику нагрузочного тестирования по такой структуре:

1. Информация о проекте и определения терминов.

2. Цели тестирования. Например, «внедрить в программу новую фичу» или «подготовить интернет-магазин к распродаже, когда пользователей на сайте будет в X раз больше».

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

У меня заглушки и эмуляторы работают на Java, скрипты я пишу в HP LoadRunner, а запускаю в Performance Center.

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

6. Раздел с описанием тестового стенда. Это схемы с серверами, заглушками и генераторами нагрузки.

7. Таблица с требованиями к железу.

8. Таблица отличий стенда от системы на продакшене.

9. Стратегия тестирования.

10. Описание видов тестирования.

11. Требования к производительности от заказчика.

12. Моделирование нагрузки.

13. Профиль (который мы получаем от аналитиков или собираем на основе бизнес-прогнозов).

15. Стоимость внезапного изменения требований к проекту. Это избавит исполнителя и заказчика от лишних забот.

16. Материалы для сдачи проекта, куда входит всё, что мы подготовили для следующего специалиста.

Зачем всё это?

Если заказчик ничего не знает о конкретном тестировании, методика ответит на все его вопросы. В ней объясняется, за что компания платит деньги подрядчику и какие результаты получит на выходе.

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

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

Как проводят нагрузочное тестирование

Чтобы провести нагрузочные тесты новой системы, я использую такой чек-лист:

ПО для НТ

Для проведения нагрузочного тестирования необходимо специфическое ПО.

Я лично работаю с HP LoadRunner, ещё есть ПО Gatling, Apache JMeter, BlazeMeter, LoadNinja и даже отечественный «Яндекс.Танк». У каждого из них есть свои плюсы и минусы: одни не работают со специфическими протоколами, другие бесплатны, третьи больше дружат с тяжёлыми скриптами и так далее.

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

Зато LoadRunner позволяет тестировщикам ПО проводить комплексную оценку производительности своей системы. Его фишка — выявление узких мест ещё до того, как приложение будет внедрено или развёрнуто. В результате пользователи могут оценить каждый компонент по отдельности — даже прежде, чем он начнёт работать.

Выводы

Заглушка — часть кода, которая на время теста заменяет другой компонент, например сторонний API. Она отдаёт системе черновые данные.

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

Средства виртуализации позволяют запустить на одном железе несколько независимых систем с нужными настройками. Например, это помогает тестировать Windows-приложения в среде Linux.

Источник

Нагрузочное тестирование: что в нем интересного и какие навыки нужны?

Попросили рассказать о перспективах и задачах в сфере тестирования производительности Василия Кудрявцева, директора по качеству АО РТЛабс и руководителя нашего курса «Нагрузочное тестирование».

Самая актуальная на сегодня область в QA

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

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

Можно рассчитывать на зарплату на 30-50% выше, чем по другим направлениям тестирования.

Каждый проект в нагрузочном тестировании уникален

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

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

Василий Кудрявцев

QA Load — самая разнообразная область, где специалисту надо не только заниматься кодом, но и всесторонне развиваться.

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

Как стать нагрузочным тестировщиком?

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

Курс «QA Load» мы собрали из крупиц материалов, объединив свой опыт решения задач для различных компаний. 70% программы содержит практику — и именно это отличает ее от остальных учебных проектов. У нас нет поверхностных тем, каждая изучается вглубь, с разбором кейсов и возможностью попробовать инструмент, потренировать навык.

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

Во втором модуле вы изучите 4 основных инструмента нагрузочного тестирования: Performance center, Jmeter, Gatling, k6.io. Хотя их на рынке несколько больше, мы после опросов выделили используемые повсеместно и этого набора должно хватить, чтобы решить 90% «нагрузки». Чтобы эти инструменты сразу можно было встраивать в DevOps-процессы, есть отдельный урок про автоматизацию нагрузочного тестирования с помощью Jenkins, встраивание с помощью CI/CD. Также отдельно расскажем про Grafana и InfluxDB, чтобы соединить эту часть мониторинга с вашими тестами.

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

В течение обучения вас ждет интенсивная работа и 8 домашних заданий: закрепить пройденный материал, попробовать каждый инструмент, написать скрипты, провести тестирование и т.д. Будут задачи на разработку профиля НТ, настройку логирования и проведения регрессионного тестирования для веб-сайта. Для тех, кто хочет получить еще больше навыков и пользы, в заданиях есть пункты со звездочкой. Тренироваться вы будете на реальных системах, серверах, сайтах. Стенды для отработки предоставит партнер курса AdvancedHosting.

Завершающая часть программы — проектная работа, которую можно выполнить для своей рабочей или нашей учебной системы. Вы пройдете полный цикл тестирования и примените все навыки, полученные в процессе обучения. Если у вас нет своего проекта, мы подберем индивидуальный сервис, поэтому не будет двух одинаковых работ. Каждый студент сможет увидеть, какие проблемы встретились его сокурсникам, сможет перенять их опыт и решения.

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

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

Василий Кудрявцев

Кому нужны навыки нагрузочного тестирования?

Наш курс рассчитан на уже разбирающихся в тестировании специалистов. Чтобы успешно осваивать программу нужно обладать базой программирования на одном из языков — в ходе обучения вы столкнетесь с SQL, Java, C, Scala, также предстоит много работы в Linux, поэтому понадобится знать базовые вещи: как подключиться к консоли, найти файл и т.д.

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

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

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

В новом потоке «QA Load» занятия начнутся 29 октября и будут длиться 4 месяца. Если направление вас заинтересовало, проходите вступительный тест и записывайтесь в группу, пока есть места. Ждем вас и до встречи в OTUS!

Источник

Нагрузочное тестирование веб-проекта — без купюр

Друзья, добрый день!

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

Зачем нужно нагрузочное тестирование веб-проекта?

Дело в том, что если для удержания качества в некоторых веб-проектах еще пишут автотесты, то контролем производительности на стадии разработки мало кто занимается в принципе. Увидеть веб-проект и с автотестами и с бенчмарками кода — большая редкость. Гораздо чаще и по разумным причинам при разработке придерживаются следующих эвристик, обладающих хорошим соотношением польза-стоимость:

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

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

Аналогичная ситуация с запросами к MySQL. Если запросы выполняются по индексам, то, в общем случае, запросы будут выполняться… «быстрее». Можно верить, что время выполнения таких запросов логарифмически зависит от объема данных (O(log(n))). Но на практике часто оказывается, что одни запросы влияют на другие, используя одновременно общие подсистемы БД (сортировка на диске, который начинает тормозить) и сразу предвидеть это — нельзя.

Также часто при нагрузке выявляются любопытные особенности операционной системы, в частности, переполнение диапазона исходящих клиентских портов TCP/IP, при интенсивной работе с memcached. Или apache забивается запросами на обработку картинок, т.к. при конфигурации забыли настроить их обработку кэширующим прокси-сервером nginx.

Иногда забывают установить в MySQL путь для временных таблиц на диск, отображающий данные в оперативную память («/dev/shm»), из-за чего при возрастании нагрузки сервер БД ложится от интенсивных сортировок.

Также, при добавлении в веб-проект данных, в объеме, приближенном к боевому, запросы и алгоритмы начинают агрессивно проявлять свою «О-нотацию»: если cartesian для небольшого объема данных незаметен, то при появлении боевого объема сервер БД от напряжения становится красным.

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

Как определить целевые показатели нагрузочного тестирования?

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

Все просто! Сейчас нарисую и покажу в прекрасной среде для анализа данных: Jupyter notebook/Python.

Допустим, на веб-сайт сделали 10 хитов с таким временем в миллисекундах:

Теперь отсортируем время выполнения хитов по возрастанию:

Мы в шаге от понимания медианы, 25 и 75 перцентелей. Все просто — разделим график пополам и в середине будет «медиана» (цифра 1 на графике). Первая четверть графика будет соответствовать 25 перцентилю (цифра 2 на графике) и третья четверть будет соответствовать 75 перцентилю (цифра 3 на графике). Соответственно получаются и другие перцентили (или, как их еще называют, квантили) — 90, 95, 99 и т.п.:

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

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

И получится примерно такая картина:

Надеюсь теперь все стало ясно и на свои места. Если нет, спрашивайте в комментариях.

Время проведения нагрузочного тестирования

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

Планирование распределения нагрузки

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

Расчет интервалов и нагрузочных потоков несложно сделать в Excel или на листике карандашом.

Структура нагрузочной цепочки

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

Коню ясно, что нельзя при нагрузочном тестировании дергать только одну детальную страницу каталога, поэтому полезно считывать и ротировать их список из CSV-файла:

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

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

Как сделать так, чтобы нагрузочное тестирование благополучно закончилось?

На практике, почти всегда, нагрузочное тестирование в первые минуты-часы обрушивает веб-систему, все начинает дымиться, затем гореть, сайт не открывается, MySQL падает в своп и не дает к себе подключиться, LA на серверах приближается к 100, разработчики начинают бегать со словами «это не должно было произойти», а сисадмины с ухмылкой обычно отвечают «справедливость в жизни есть!» и начинают пить пиво в серверной.

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

Перечислю, что происходит при коллапсе веб-системы чаще всего и как это можно исправить.

Прежде всего «забивается» запросами веб-сервер apache или php-fpm:

Чаще всего это происходит из-за коллапса MySQL — вырастает число висящих потоков запросов:

Чем это обусловлено? Часто сверху забывают забивают ограничить число apache или потоков запросов к МySQL, что вызывает выпадение приложений из оперативной памяти в медленный своп с конвульсиями:

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

Однако, иногда проблема оказывается на стороне медленной дисковой подсистемы. В этом случае резко вырастает LA и процент утилизации диска приближается к 100 (правый нижний график):

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

Интерпретация результатов нагрузочного тестирования

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

Имея эти артефакты, вы можете, используя простой awk-скрипт в начале поста, построить распределения (гистограммки) по этим логам и посчитать число и типы HTTP-ошибок. По сути, вы можете сформировать очень емкий и полезный для бизнеса и принятия решений отчет об успешности нагрузочного тестирования примерно такого содержания:

В течение суток сделан 1 млн. хитов. 25% хитов сделаны менее, чем за 50 мс, 50% хитов сделаны менее, чем за 0.5 сек (медиана), 75% хитов сделаны менее, чем за 1 сек, 95% хитов сделаны менее, чем за 5 сек, число ошибок HTTP — 0.01%. Тестовые данные: каталог, пользователи, новости, статьи были залиты в объеме, приближенном к ожидаемому. Один разработчик — застрелился.

Главная — Новости — Детальная новости = 50%
Главная — Обзор каталога — Детальная каталога = 30%
Детальная каталога — Обзор каталога — Детальная каталога = 15%
Результаты поиска — Детальная каталога = 5%

Графики использования ресурсов серверов:
…

Это уже хороший и понятный отчет о нагрузочном тестировании веб-системы. Для любителей острой боли еще можно рекомендовать при нагрузочном тестировании включить ежеминутный импорт-экспорт данных на веб-сайт из систем класса SAP, 1C и т.п. и синхронные соединения по TCP/IP сокетам с внешними сервисами курсов, скажем, криптовалют 🙂

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

Откуда берутся ошибки при нагрузочном тестировании?

Кстати да, мы не осветили этот момент. Из банальных причин обычно всплывает отсутствие балансировки между nginx — apache — mysql воркерами. Т.е. воркеры сверху не ограничивают, в результате в apache может подняться сразу 500 воркеров (каждый иногда по 100 МБ) и на MySQL прийдут сразу 500 потоков с запросами — что вызовет всплеск HTTP 50х ошибок и возможный коллапс.

Тут рекомендуется ограничить число apache/php-fpm воркеров до числа, умещающегося в ОЗУ и, аналогично, ограничить число потоков на MySQL, для защиты от переполнения доступной оперативной памяти. Идея проста — пусть клиенты ждут перед nginx, немного может замедляясь на асинхронных и неблокирующих TCP/IP сокетах, чем «ломятся» сразу в apache/MySQL.

Из более неприятных причин тут может быть segfault PHP. В этом случае необходимо включить сбор coredump и с помощью gdb посмотреть, почему это происходит. В большинстве случаев через обновление/конфигурацию PHP проблему удается обойти.

Что осталось за кадром

Ходят упорные слухи, что современный фронтэнд для веба так активно зажил своей жизнью, что классическое нагрузочное тестирование бэкэнда, приведенное в данном посте, уже не закрывает всех возможных рисков зависания построения веб-страницы в «потрохах» Angular/React/Vue.js — поэтому не используйте тяжелый и непрозрачный, плохо тестируемый фронтэнд можно, при необходимости, адаптировать нагрузочные цепочки и к такой ситуации.

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

Если серьезно, то в ближайших постах мы надеемся осветить и эту важную тему.

Итоги и выводы

Итого — нет ничего сложного в организации и проведении полезного для разработки и бизнеса нагрузочного тестирования веб-системы.

Для проведения нагрузочного тестирования важно привлекать не только разработчиков, но и экспертов по операционным системам и железу — опытных системных администраторов, и тогда проблемы «выпадения в своп» или «переполнения локального диапазона IP-адресов» не вызовут кровотечения из глаз и обмороков.

Удачи, друзья и задавайте вопросы в комментариях!

Источник