Метрика, показывающая количество памяти, использованной приложением. Использованная память делится на несколько категорий:

Virtual — объём виртуального адресного пространства, которое использует процесс. Этот объём подразумевает, как использование соответствующего дискового пространства, так и оперативной памяти. Система виртуальной памяти гарантирует, что потоки одного процесса не получат доступа к памяти, принадлежащей другому процессу.

Private — объём адресного пространства, занятого процессом и не разделяемого с другими процессами.

Working Set — набор страниц памяти, недавно использованных процессом. В случае, когда свободной памяти достаточно, страницы остаются в наборе, даже если они не используются. В случае, когда свободной памяти остаётся мало, использованные страницы перемещаются из ОЗУ на жёсткий диск (или другой накопитель, такой как Флеш-память), освобождая ОЗУ для загрузки других активных страниц памяти.

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

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

Потребление сетевых ресурсов

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

Работа с дисковой подсистемой (время ожидания ввода-вывода, англ. I/O wait)

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

Время выполнения запроса, мс

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

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

Подготовка, отправка и публикация отчета по проведенному нагрузочному тестированию

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

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

Наиболее частые и популярные ошибки при тестировании и интерпретации результатов теста:

· Нет четкой цели, для чего нужно тестирование данного проекта.

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

· Получают большое количество результатов и не могут их растолковать, не знают, что с ними делать.

· Неправильное представление результатов нагрузочного тестирования клиенту. Клиент может не знать всех терминов и инструментов тестирования. Нужно объяснить клиенту результаты тестирования понятным ему языком: «было столько-то, стало столько-то» и «хорошо стало или плохо», а также предложить ему решение проблемы, если она есть.

· DDOS тестируемой системы. Нагрузили систему, и через некоторое время она перестала отвечать. Причина – безнадежно «заDDOSили» инструментами тестирования.

Поэтому при нагрузочном тестировании:

· Нужно обращаться к разным страницам веб-системы.

· Нужно загрузить демо-данные (реальный объем будущего проекта).

· Важно использовать авторизованные хиты.

· Также полезно проверять производительность загрузки статики (CSS, JS).

Здесь можно выявить различные ошибки. Например, верстальщик забыл добавить css-файл, NGINX отдает страницу с 404-й ошибкой через Apache средствами PHP (ошибка администратора). В итоге все слоты Apache заняты обработкой 404-й ошибки, попутно еще загружая сам сайт - получился типичный DDOS сайта. Решение этой проблемы - отдавать легкую статичную страницу с 404-й ошибкой сразу средствами NGINX.