Собственно
модуль
http://drupal.org/project/parallel
О модуле
Allows for parallel downloading of the various resources inside your html document
Вопрос, кто пользовался?, какие впечатления
По описанию вроде ничего сложного, а ускорение должно быть заметным
Комментарии
Надо посмотреть как там сделано это расподдоменивание, а то может и плюсов никаких не остаётся
да, просто увидел в шоукейсе последнем на орге - что используют этот модуль
гм, по моему тупо воткнуть nginx перед апачем - эффект будет тот же самый, не? то есть исходя из заголовка - чтобы статика отдавалась другим сервером/сервисом
Попробую, но думаю будут траблы со всякими imagecache-ми
orangeudav
Вы несколько не правы, имхо
Смысл в том, что скрипты отдаются с одного субдомена, картинки с другого, стили с третьего
1. Паралельная загрузка
2. Отстуствия влияния всяких куки
Хотел присмотреться к этому модулю, и даже скачал. Но почитал про него и понял, что это не мое.
Он не может использоваться с реальными CDN-ами.
Ну, а нафига в таком случае?
Нагрузку и трафик с сервака он не снимет.
Ну и мы же в 21 веке живем. Сейчас все нормальные браузеры и так могут в 6 - 8 потоков скачивать.
странно, видел на нескольких сайтах, распределение по судбоменам
даже кажется на хабре
много где рекомендуют подобную схему, но плюс к поддоменам еще советуют статический контент отдавать не апачем, а чем-нибудь скорострельным, nginx-ом, например.
на хабре куча статики, у вконтакта куча статики. воозможно тут не в скорости загрузки речь а о баланисировке нагрузки.
так вышеприведённый модуль как раз и пытается решить этот вопрос
мне показалось, что авторы модуля имели ввиду что браузер в рамках одного TCP-соединения может получать объекты только последовательно. А если объекты будут на разных серверах, то загрузка будет по параллельным TCP-соединениям параллельно
подобного рода оптимизации играют какую то роль только в случае
1. неверной работы с кешем браузера или
2. первой загрузки страницы.
в 1 случае с администратором и так все ясно. никакие модули типа паралелс не помогут
в 2 случае слабое место в загрузке сайта будет не в последовательной или параллельном методе загрузки скриптов а в загрузке вообще. Стилей скриптов и прочих внешних ресурсов.
кроме того, сама стратегия в модуле не такая однозначная. часто бывают ситуации когда на установку нового соединения с фейковым сервером уйдет больше времени чем на загрузку самого скрипта.
почему тогда все высоконагруженные сайты отдают статику по отдельным субдоменам?
ну у нормальных людей эти сервера ни разу ни фейковые, а очень даже настоящие
А написано что этот модуль поддерживает нормальные сервера?
Всё-таки распараллеливание данных это тебе не в тапки гадить
Он ещё и всю страницу регулярками обрабатывает. Как-то это некошерно - похоже на костыли какие-то.
Обалдеть. Это же прямой путь к потере производительности.
Теперь уж точно "в сад".
странная картина http://drupal.org/node/801580
чуваки пользуются сборкой друпала (прессфлоу), буттс, мэмкэш и при этом юзают плохой модуль
Посмотрел я этот сайтик.
Мне показалась странным то, что постоянно пробиваются DNS на статике, а в заголовках ответа стоит "Connection: close"
Не настроено? Или так и должно быть?