Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. C++. Мастер-класс в задачах и примерах. Авторы: Кузнецов М.В., Симдянов И.В. Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В. MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Разное

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Сколько одновременных соединений рекомендуется для браузера?
 
 автор: Саня   (01.03.2011 в 09:39)   письмо автору
 
 

Cheops немного не прав по поводу первого пункта.

> Под отдельный домен много проще выделить отдельный сервер или кластер.
> В таких проектах используются сотни и тысячи серверов...
На одном домене вполне могут уместиться эти сотни и тысячи серверов.
Причина в другом.

Протокол HTTP 1.1 имеет ограничение: не более двух одновременных соединений на один домен. Все браузеры реализуют это ограничение. Современные сайты, с сотнями картинок и скриптов на одну страницу, страдают от этого ограничения. Если быть точным, то страдают посетители таких сайтов. Грузятся все эти элементы по два за раз и в целом получается очень медленно. Есть несколько способов обойти это ограничение и одно из них — разнести загружаемые элементы по разным доменам (или поддоменам). Это один из аспектов клиентской оптимизации.

А ещё статику могут выносить на отдельный домен из-за cookies. Зачем статике куки? Они только занимают лишнее место в запросе.

  Ответить  
 
 автор: cheops   (01.03.2011 в 10:57)   письмо автору
 
   для: Саня   (01.03.2011 в 09:39)
 

>Протокол HTTP 1.1 имеет ограничение: не более двух одновременных соединений на один домен.
Это рекомендация (так как протокол HTTP 1.1 поддерживает keep-alive соединения, когда клиенту не обязательно устанавливать каждый раз новое соединение за каждой картинкой, теряя время на установку соединения), а не строгое правило, кто-то действительно из-за этого использует отдельные домены, но в огромных проектах - это не основная проблема - им бы себя масштабировать, а скорость загрузки клиента они прекрасно вычислят по модели сети. Новые браузеры вроде FF 3 используют по 6 соединений, Opera - 8, более того, вам никто не мешает залезть в реестр/настройки браузера и выставить столько соединений, сколько душа пожелает и сервер позволит.

  Ответить  
 
 автор: Саня   (01.03.2011 в 11:30)   письмо автору
 
   для: cheops   (01.03.2011 в 10:57)
 

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

keep-alive — хорошая идея, но она всё равно не решает проблему, описанную выше.

> более того, вам никто не мешает залезть в реестр/настройки браузера и выставить столько соединений
Ага. Даже я, узнав про эту проблему, всё равно не полез в настройки. А вы полезли? Кто даст гарантию, что все юзеры пойдут настраивать настройки, даже если требования будут написаны красными буквами огромным кеглем на главной странице?

> ...но в огромных проектах - это не основная проблема...
В огромных проектах каждый лишний байт выливается в терабайт. За траффик платить всё равно приходится. Тут и применяется клиентская оптимизация.
http://webo.in/articles/habrahabr/54-psychology-web-performance/
Особенно присмотритесь к разделу "Эффекты медленной скорости загрузки".

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

  Ответить  
 
 автор: cheops   (01.03.2011 в 11:50)   письмо автору
 
   для: Саня   (01.03.2011 в 11:30)
 

>Особенно присмотритесь к разделу "Эффекты медленной скорости загрузки".
Про это я сам порассказать могу.

>Когда дело касается денег, то огромные проекты жопу порвут, но уменьшат издержки
Я тоже самое и говорил, в рамках многофункционального сервера/кластера эффективность будет ниже, чем в рамках специализированного. Такой специализированный сервер/кластер проще вынести на отдельный домен - в рамках одного домен эту задачу решить сложнее. О клиентах, конечно тоже думают, но им ничто не поможет, если скорость отдачи с серверов будет не достаточно большая.

  Ответить  
 
 автор: Саня   (01.03.2011 в 12:29)   письмо автору
 
   для: cheops   (01.03.2011 в 11:50)
 

> Такой специализированный сервер/кластер проще вынести на отдельный домен - в
> рамках одного домен эту задачу решить сложнее.
Чем же проще или сложнее? Какая разница, что один домен указывает на много серверов или каждый отдельный домен/поддомен указывает на свой сервер?
Разумеется, в задачах администрирования проще, когда каждый сервер имеет своё "имя".

> Про это я сам порассказать могу.
Расскажите.

  Ответить  
 
 автор: cheops   (01.03.2011 в 13:34)   письмо автору
 
   для: Саня   (01.03.2011 в 12:29)
 

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

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

>> Про это я сам порассказать могу.
>Расскажите.
Недавно схожую проблему обсуждали.

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования