Слагаемые скорости

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

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

— разрешение IP-адреса веб-узла по его доменному имени;
— преодоление очереди пользовательских запросов;
— обработка запроса сервером;
— передача запрошенных данных по каналу связи клиенту;
— отображение объектов страницы браузером.

URL той или иной страницы в подавляющем большинстве случаев содержит в себе имя домена. А это неизбежно приводит к ощутимым временным задержкам — ведь фактически обращение к веб-серверу все равно производится по IP-адресу, который предварительно выясняется при помощи службы DNS.

Ясное дело, я не призываю указывать на визитках и в веб-обзорах IP-адреса узлов вместо их красивых и понятных доменных имен, заботливо оберегаемых от киберсквоттеров. Но в теории загрузку ряда связанных со страницами объектов и открытие некоторых ссылок можно ускорить, используя в атрибутах href, src и им подобных IP-адреса ресурсов вместо соответствующих им доменных имен.

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

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

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

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

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

На означенный параметр влияет огромное количество разнообразных факторов. Большинство из них, по правде говоря, относится скорее к компетенции провайдера и в идеале должно занимать непосредственного разработчика сайта лишь из соображений спортивного интереса (если, конечно, речь идет о виртуальном хостинге, а не о собственном или арендованном выделенном сервере, чего мы, пожалуй, пока касаться не будем). Что это за факторы? Ну, например: каково аппаратное обеспечение машины, на которой «крутится» веб-сервер; что, помимо собственно веб-сервера, на ней еще «крутится»; сколько всего виртуальных хостов обслуживается; насколько оптимальна программная конфигурация операционной системы и непосредственно веб-сервера с точки зрения производительности — скажем, разрешены ли постоянные (keep-alive) соединения и используется ли динамическое сжатие исходящего трафика…

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

Так, очевидно, что статические HTML-документы при прочих равных условиях возвращаются сервером почти мнговенно. Страницы, построенные на основе SSI — чуть медленнее. «Настоящие» динамические страницы, использующие различные серверные технологии, к примеру, CGI/Perl или PHP, формируются еще немного дольше. Наконец, медленнее всего генерируются ответы, требующие многочисленных обращений к базе данных для получения той или иной информации.

Конечно, здесь все не так уж однозначно. Скажем, CGI-скрипты, написанные на C или С++, опять же, при прочих равных работают быстрее, чем приложения, написанные на Perl. А прилежно доведенная до третьей нормальной формы база данных, для каждой из таблиц которой тщательно и с пониманием сути дела определены все необходимые индексы, создаст явно меньше проблем, чем база, где все данные свалены в одну большую таблицу (так и хочется сказать — кучу) с индексами, заданными от балды, или вовсе без оных.

Тем не менее, вполне ясно, что статическому сайту и «навороченному» интернет-магазину, и в хвост и в гриву эксплуатирующему MySQL, при одинаковом трафике потребуются совершенно различные условия хостинга.

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

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