Эта статья была спонсирована New Relic . Спасибо за поддержку спонсоров, которые делают возможным SitePoint!
Невозможно сказать, когда ваше приложение может привлечь множество посетителей одновременно — возможно, это сообщение Hacker News, которое отправляется в определенную секунду в определенное время суток (поскольку сообщения там, как правило, работают), может быть, это был особенно хорошо размещенный Reddit пост, и, возможно, это на самом деле хорошо, и люди заметили это, распространяя это вирусно. Независимо от причины, массовый наплыв посетителей является обоюдоострым мечом: они дают вам то, что вы всегда хотели — шанс доказать свою ценность для большой части населения Интернета — но также часто приносят с собой то, чего вы всегда боялись: абсолютное время простоя.
Есть несколько способов предотвратить это — одним из наиболее распространенных является развертывание приложения в сервисе, таком как Amazon, Google App Engine или Heroku, который способен не только быстро и быстро масштабироваться по вашей команде, но также поддерживает автоматическое масштабирование. , если вы не боитесь DDoS-атак, также увеличивайте свои счета, пока вы спите. Эти платформы обычно предлагают плагины, которые могут оптимизировать ваше приложение, пока оно работает, так что вы можете точно настроить его по ходу работы, но почему бы не попытаться предсказать проблемы, продолжая локальную разработку, и сэкономить время, деньги и усилия в долгосрочной перспективе?
Apache Benchmark
ApacheBench (также известный как «ab», команда, с которой вы его запускаете) — это инструмент, предназначенный для уничтожения конечной точки с помощью запросов и веб-серверов для нагрузочного тестирования. Он поддерживает широкий спектр параметров и опций, которые можно настроить для имитации различных нагрузок, таких как количество запросов, количество одновременных запросов, дополнительные заголовки, фальсифицированные файлы cookie и многое другое.
ab часто включается в каждую установку Apache, но если нет, вы можете легко установить ее, запустив sudo apt-get install apache2-utils . В текущей версии Laravel Homestead ее нет, поэтому, если вы следите за ней, пожалуйста, установите ее на эту виртуальную vagrant up когда вы vagrant up и подключаетесь через SSH.
Вы можете проверить, что он установлен, просто запустив ab , который должен создать список поддерживаемых опций:
Для нашей демонстрации я создал подпапку Laravel в разделе «Код в ВМ», добавил подпапку «public» и поместил в нее файл index.php со следующим содержимым:
<? php echo "Hello Test" ;
В homestead.yaml я назвал этот сайт «homestead.app», и в своем файле hosts на моей хост-машине я добавил 127.0.0.1 homestead.app . Это позволяет мне запускать сайты, размещенные на Homestead VM, из браузера хост-машины через http://homestead.app:8000 , все стандартные вещи, которые мы рассмотрели ранее . Тем не менее, это также позволяет вам скручивать homestead.app изнутри виртуальной машины — то, чем мы можем воспользоваться, бомбардируя наше приложение с помощью ab .
Тестовый забег
Для начала давайте попробуем взорвать наш homestead.app с помощью образца гранаты — просто запустите ab на URL, без каких-либо опций. Обратите внимание, что вы должны следовать за URL через косую черту, в противном случае вы получите ошибку неверного URL из ab.
ab homestead . app /
Мы видим, что тест завершается практически мгновенно — количество запросов в секунду и загрузка параллелизма слишком нереальны и просты, чтобы дать полезные результаты. Фактически, многократный запуск стенда даст результаты от 50 до 200 возможных запросов в секунду. Чтобы получить более ощутимые результаты, нам нужно улучшить нашу игру.
Демо приложение
Выйдите из папки Laravel и полностью удалите ее с помощью команды rm -rf Laravel . Далее мы создадим пример приложения Laravel по умолчанию со всеми зависимостями. Если у вас еще нет Composer, установленного глобально, сделайте это легко и быстро. Затем выполните следующую команду:
composer create - project laravel / laravel Laravel -- prefer - dist
Это загрузит скелет Laravel, все зависимости, и сгенерирует необходимые файлы автозагрузки и блокировки. Вы можете убедиться, что это работает, зайдя на ваш хост http://homestead.app:8000 , или свернув homestead.app внутри виртуальной машины:
Давайте настроим основную команду скамейки и правильно наступим на наши приложения. Запустите ab -n 500 -c 100 homestead.app/ чтобы сделать более реалистичный тест. Параметр n означает «количество запросов», а c — одновременность, то есть, сколько запросов одновременно. Таким образом, эта команда выполнит 5 пакетов по 100 одновременных запросов.
Формат результата по умолчанию, который вы получите в конце выходных данных, сообщит вам, сколько запросов (в процентах) было выполнено в течение определенного периода времени, 10 на 10 процентов, от 50% до 100%. Другими словами, если первая строка равна 50% 3200, это означает, что половина всех запросов была выполнена в течение 3,2 секунды. Для 250 запросов это неплохо, особенно на такой слабой машине.
Давайте попробуем и замедлить вещи нарочно. Перейдите в app/controllers/HomeController.php и измените функцию showWelcome следующим образом:
public function showWelcome ()
{
if ( isset ( $_GET [ 'slower' ]) && $_GET [ 'slower' ] == 'true' ) { sleep ( 1 );
} else { usleep ( 1 );
}
return View :: make ( 'hello' );
}
Если вы хотите получить более последовательные результаты, не стесняйтесь удалить вызов Google Fonts из hello.php , поскольку это устраняет задержку загрузки при извлечении шрифта и оставляет все в руках виртуальной машины локально. Кроме того, в файле routes.php замените текущий маршрут на основе замыкания следующим:
Route :: get ( '/' , 'HomeController@showWelcome' );
Теперь попробуйте выделить два разных URL-адреса: homestead.app и homestead.app?slower=true . Как и ожидалось, вы заметите, что результаты сильно отличаются. Это был совершенно нелепый пример, но этого достаточно, чтобы продемонстрировать эффект, который длительный скрипт может оказать на ваших посетителей, когда они собираются в массовом порядке. Если у вас есть такие долго выполняемые сценарии, гораздо лучше делегировать их в фоновый режим с помощью очередей сообщений или другими средствами, а также убедиться, что ваш сценарий, работающий с клиентом, работает настолько быстро, насколько это возможно.
Вывод
В этом введении к ApacheBench мы увидели, как эффективность скрипта влияет на огромные скачки трафика. Мы будем добавлять больше обучающих уроков в дальнейшем, но в то же время все, что вам следует от этого извлечь, — не стоит недооценивать небольшие оптимизации. Существует вероятность преждевременной оптимизации, но если вы сможете обнаружить и удалить валуны с пути раньше, дорога в конечном итоге станет более гладкой. Поиграйте с ab, протестируйте его, переключите параметры и параметры, добавьте соединения с базой данных в пример приложения Laravel, с которым мы играли — сломайте его, исправьте его, сломайте его снова. Дайте нам знать, что вы найдете — мы будем рады опубликовать ваши расширенные варианты использования!