Читать «Разгони свой сайт» онлайн - страница 63
Николай Мациевский
На этом графике хорошо видно, что для musicstore.ajaxperformance.com открыто только 2 соединения (данная диаграмма является модельной и справедлива только для IE; во всех остальных браузерах по умолчанию открывается большие соединений): C0 и C2. Мы используем протокол HTTP 1.1, поэтому нам не нужно открывать отдельное соединение для каждой картинки, но мы по-прежнему теряем кучу времени на обслуживание индивидуальных запросов к объектам. Время на установление соединения (время до получения первого байта, голубая полоска на диаграмме) явно доминирует над временем загрузки данных, которое не так велико (красная полоска на диаграмме).
Лучше, больше, быстрее
Стоит обратить внимание, что при проектировании масштабируемых приложений, которые будут распределять объекты по различным хостам, нужно использовать хэш-функцию. Она установит однозначное соответствие между названием изображения и хостом, с которого оно должно загружаться. В качестве простых примеров можно привести остаток от деления md5-суммы или длины строки адреса изображения на число хостов. Также можно рассмотреть использование контрольной суммы CRC32, которую проще посчитать на JavaScript.
При первой загрузке производительность будет значительно лучше. Как можно видеть из нижеприведенного графика, сейчас используется уже 6 соединений для загрузки наших картинок (рис. 5.2).
Реальный выигрыш
Время загрузки страницы при использовании уменьшилось больше чем на 40%. И эта техника будет работать во всех случаях, когда у вас большой пул запросов к объектам, которые расположены на одном сервере.
Существует масса примеров применения этого метода в реальных AJAX-приложениях. Чтобы утилизировать параллельность соединений, на Google Maps ( http://maps.google.com/ ) картинки поставляются с нескольких хостов, начиная с mt0.google.com и заканчивая mt3.google.com. На Virtual Earth ( http://local.live.com/ ) также используется эта техника.
Этот подход можно также применить, чтобы изолировать отдельные части вашего приложения друг от друга. Если некоторые его элементы требуют доступа к базе данных и их загрузка задерживается больше, чем для статичных объектов, стоит устранить их из числа тех двух соединений, которые будут использоваться для загрузки картинок на вашем сайте, например, разместив их на поддомене.
В данном случае, наверное, наиболее практичным решением будет размещение всей статики (кроме, пожалуй, CSS- и JavaScript-файлов, которые влияют на стадию предзагрузки — чтобы максимально избежать на этой стадии задержек на дополнительные DNS-запросы) на отдельном домене, например, static.example.com, а загрузка HTML-страниц, которые требовательны к базе, будет вестись с основного хоста. При этом static.example.com может иметь даже другой IP-адрес и обслуживаться любым «легким» сервером. Этот прием может быть и не сильно ускорит загрузку нашей страницы, но определенно улучшит ощущаемую производительность, позволяя пользователю загружать все статические файлы без дополнительных задержек.
