Источники нагрузки на сайт

0

Автор: SatoMaker | Рубрика: Полезное рядом, Посещаемость блога | 19-04-2012 |

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

От владельцев сайтов часто можно услышать: «Понаставили ссылок на мой сайт — и он упал от трафика». Речь при этом обычно идет о следующей ситуации: небольшой сайт чем-то привлек внимание аудитории, и к нему (например, по ссылке с какого-то популярного ресурса) в течение минимального промежутка времени обратилось очень много посетителей. Как известно, сервер может обработать лишь какое-то конечное число запросов в единицу времени. Если число запросов превысило порог, то для новых посетителей веб-сайт оказывается недоступен (а иногда отключается совсем).

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

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

 

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

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

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

Примечание

А еще нужно учитывать, что за запросы измеряются. Обычно речь идет о запросах GET протокола HTTP, на которых основана львиная доля работы веба. Мы более подробно рассмотрим этот протокол в следующих статьях.

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

Совсем другое дело, если 1000 посетителей зашла на сайт в течение 10 минут, даже с тем же «равномерным распределением»: 100 посетителей в минуту — это более одного посетителя в секунду.

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

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

Рассмотрим типичную ошибку разработчика: получая второй запрос, программное обеспечение (ПО) веб-сайта начинает обрабатывать его, откладывая уже обрабатываемый (первый запрос) в очередь, или отбрасывая его (такое неверное решение встречается в реальности). Очевидно, что за время, которое требуется для обработки любого из запросов (две секунды), гарантированно придет новый: по условию наших испытаний запросы следуют один за другим с интервалом примерно в 1,67 секунды (1000 запр. / 600 с) . Таким образом, 1000 запросов окажутся в очереди, и 10 минут сайт будет только ставить запросы в очередь, не выводя ни одной страницы.

Более элегантным было бы следующее решение этой проблемы с тысячей посетителей: при получении новых запросов во время обработки первого ПО веб-сайта просто отбрасывает их до тех пор, пока не завершит обработку. Завершив обработку одного запроса, ПО ожидает следующего и т. д. В этом случае будет отброшена лишь часть запросов, а поэтому многие пользователи смогут увидеть страницы сайта. Если запросы не отбрасывать, а ставить в очередь, ситуацию можно еще улучшить, особенно учитывая тот факт, что пользователи готовы ожидать появления страницы в течение довольно длительных, по компьютерным меркам, интервалов времени (например, 15-20 секунд). Даже наш гипотетический суперзамедленный веб-сайт может за 20 секунд обработать запросы от 10 пользователей.

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

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

Мой блог находят по следующим фразам

Записи по данной теме:

Понравилась статья? У Вас есть возможность получать ежедневные обновления блога удобным для Вас способом:
Подписаться на блог 'Сатомейкер' по email

Ваш электронный адрес:

 

 

Подписаться на блог 'Сатомейкер' по email

Подпишитесь через RSS:

 

Добавить в Google

 

Читать в Яндекс.Ленте


Follow Satomaker on Twitter






Ваш отзыв