Нестабильные системы 
Любой аппаратный комплекс, программа или сетевые системы создаются в расчете на определенные нагрузки. Нас не удивляет, когда покрышки автомобилей испытываются на максимально допустимую скорость и продаются с четким указанием допустимых величин. Но крайне редко приходится встречать подобное отношение к программно-аппаратным комплексам.
Очень редко компании перед запуском проекта в эксплуатацию проводят нагрузочное тестирование сервера и определяют максимально допустимую посещаемость. Кстати, в рамках тестирования легко выявляются наиболее частые ошибки и слабые места, и в результате производительность сервера увеличивается в несколько раз.
Но мы поговорим о причинах, по которым обычный веб-сервер в результате нагрузочного тестирования или реальных пиковых нагрузкок прекращает нормальное функционирование.
При больших нагрузках проект может прекратить нормальное функционирование по следующим причинам:
1. Нехватка оперативной памяти для нормальной одновременной работы процессов веб-сервера и базы данных. В большинстве систем на каждый запрос к сайту открывается отдельный процесс веб-сервера. Обычный размер процесса Apache с подключенным PHP-модулем и работающим приложением может составить порядка 20-30 мегабайт. В результате пиковых нагрузок происходит одновременный запуск очень большого числа процессов (иногда больше нескольких сотен процессов). И как следствие, начинается свопирование процессов, а это неизбежно сказывается на производительности базы данных, и производительность всей системы в целом резко снижается.
2. Нехватка процессорных ресурсов для одновременного выполнения процессов и обеспечения адекватного для пользователя времени реакции. Данная ситуация может возникнуть в том случае, если в результате большого числа запросов к вашему серверу число одновременно выполняемых запросов превысит процессорные мощности сервера. И даже если у вас достаточно оперативной памяти и первая проблема не проявила себя, вы можете обнаружить, что система перестала адекватно отвечать на запросы, время выполнения страниц увеличилось в несколько раз, база данных перегружена очень большим числом запросов. Все это может привести к тому, что все без исключения пользователи не смогут работать с сервером.
3.Недостаточная производительность базы данных при одновременных конкурентных запросах, невозможность полностью использовать ресурсы сервера. Данная ситуация очень часто возникает при работе с MySQL. Надо отметить, что обычно MySQL использует формат таблиц MyISAM. Это очень простой и эффективный вариант работы, но, к сожалению, при большом числе одновременных запросов такая база данных становится критически узким местом в производительности системы в целом. Во время вставки данных, обновления и некоторых других запросах, происходит эксклюзивное локирование таблиц и, как следствие, все запросы выполняются только последовательно, а не одновременно. В результате, при росте нагрузки, время генерации страниц возрастает необоснованно резко и в итоге становится неприемлемо большим. Менее всего подвержены подобным проблемам проекты, использующие Oracle или MSSQL, MySQL с форматом таблиц InnoDB.
4.Общая несбалансированность веб-системы при пиковых нагрузках и быстрая регрессия производительности даже при незначительных стрессах. При пиковых нагрузках вся система испытывает перегрузки. В дополнение к перечисленным проблемам возможно возникновение проблем в дисковой подсистеме. В итоге, если под одной из составляющих начинается потеря производительности, то существенно падает производительность всей системы, начинается падение производительности в других частях и, в итоге, еще больше снижается работоспособность, производительность системы регрессирует и иногда наступает полная остановка в работе.
Оперативная память: большие процессы Остановимся чуть подробнее на вопросе использования веб-сервером оперативной памяти.
Как мы уже упоминали, в большинстве конфигураций на каждый запрос пользователя к сайту веб-сервер запускает отдельный процесс-обработчик. Вместе с загруженными модулями, интерпретатором PHP и исполняемым приложением каждый процесс может занимать 20-30 мегабайт, а иногда и более.
10 запущенных процессов будeт потреблять уже 200-300М, а запущенные 100 процессов приведут к сильнейшему свопингу системы с объемом оперативной памяти в 1Г, так как для работы всех процессов потребуется порядка 2-3Г памяти.
Как показывает практика, именно нехватка оперативной памяти для всех процессов может стать ключевым фактором нестабильности при пиковых нагрузках.
Также стоит отметить, что в обычной конфигурации веб-сервер обрабатывает все запросы к PHP-страницам, к графическим файлам, бинарным файлам, таблицам стилей и другим составным частям сайта.
На одну страницу сайта может приходиться от нескольких десятков до нескольких сотен графических элементов. Загрузка бинарных файлов, XML-файлов, таблиц стилей также выполняется веб-сервером в обычных конфигурациях.
Теперь, если вспомнить, что обычный процесс веб-сервера занимает 20-30М, то получается, что для выдачи статических элементов сайта полностью не используется функциональность по обработке PHP, а память при этом используется, и процесс занят обработкой запросов. Получается, что до 90% времени процесс, находящийся в памяти, будет обрабатывать именно статические документы, неэффективно используя ресурсы.
Проблема выдачи статического контента настолько существенна, что одной из важнейших задач является минимизация числа статических запросов, обрабатываемых веб-сервером.
Оперативная память: медленные каналы Еще один аспект проблемы – это медленные каналы пользователей вашего сайта по меркам веб-сервера. Казалось бы, какое отношение эта проблема может иметь к владельцу сайта? Оказывается, не просто имеет отношение, но и может стать причиной больших проблем.
Например, время генерации страницы может составлять 0.01 секунды, а время передачи страницы клиенту даже с компрессией может занимать от 5 до 50 секунд и более.
В течение всего времени передачи страницы клиенту веб-сервер будет держать в памяти практически бездействующий процесс Apache, который будет только дожидаться завершения передачи данных, но не сможет высвободить память и высвободиться сам, чтобы обработать другой запрос.
Очень часто администраторы не отдают себе отчет в том, насколько данный фактор влияет на стабильность системы и эффективное использование оперативной памяти.
Давайте сделаем простой расчет. Рассмотрим две системы: А и Б.
В системе А время генерации страниц составит 0.1 секунды, а время передачи страницы клиенту в среднем будет составлять всего 5 секунд (в реальной жизни среднее значение окажется еще больше). В системе Б мы будем считать время генерации страниц равным 0.1, а время передачи страницы пользователю равным нулю.
Предположим, что на каждый сайт поступает по 100 запросов в секунду.
Система А: обработка 100 запросов в секунду потребует одновременной работы 100 самостоятельных процессов веб-сервера! "Почему?" - спросите вы. А как же иначе, если даже обработав запрос за 0.1 с., наши процессы, получается, еще не способны обрабатывать другие запросы, а будут висеть в памяти и просто дожидаться, пока пользователи в течение 5 секунд будут получать страницу. На четвертой секунде веб-сервер получит еще 100 запросов и должен будет запустить еще 100 процессов. Соответственно, на пятой секунде в памяти должно находиться 500 процессов и только с этого момента процессы первой секунды начнут высвобождаться и обрабатывать новые запросы. Таким образом, система А для нормальной работы будет запускать порядка 500 процессов, что потребует от нас в лучшем случае 10Г оперативной памяти. Обратите внимание, что даже если бы время генерации страниц было равно 0.001 секунды, это бы не увеличило производительность системы, так как процессы ожидают передачи данных пользователям на медленных каналах, а не времени генерации страниц.
Т.е. производительность системы А никак не связана с производительностью PHP и продукта. Система Б: за первую секунду на сервер поступит 100 запросов. Для обработки 100 запросов нам потребуется всего 10 процессов. Один процесс обрабатывает один запрос за 0.1 секунды. Как мы договорились для системы Б, время передачи страницы пользователю будет равно нулю. Т.е. за 1 секунду, один процесс веб-сервера способен обработать 10 запросов пользователей! К завершению первой секунды, все запросы будут обработаны всего 10 процессами и ко второй секунде все эти процессы будут свободны и готовы обрабатывать следующие запросы. Так же случится и на третьей секунде, и через час. Таким образом, система Б для нормальной работы будет запускать всего 10 процессов, что потребует от нас порядка 200М оперативной памяти. И очень важно отметить, что уменьшение времени генерации страниц до 0.01 секунды позволит реально увеличить производительность системы в 10 раз, и нам будет достаточно уже только 1 процесса для обработки всех 100 запросов в секунду.
Производительность системы Б зависит только от производительности PHP и продукта и не зависит от медленных каналов. Очень наглядный пример, который демонстрирует, насколько велико влияние медленных каналов пользователей на общую производительность веб-системы. Веб-сервер очень неэффективно расходует оперативную память на медленных каналах.
