Ответ 1
Эй, так как я автор этой цитаты, я отвечу: -)
На больших сайтах есть две большие проблемы: параллельные соединения и латентность. Параллельное подключение вызвано медленными клиентами, которые занимают возраст для загрузки содержимого и состояния незанятых соединений. Эти состояния незанятого соединения вызваны повторным использованием соединения для извлечения нескольких объектов, которые называются keep-alive, что дополнительно увеличивается за счет латентности. Когда клиент находится очень близко к серверу, он может интенсивно использовать соединение и гарантировать, что он почти никогда не работает. Однако, когда последовательность заканчивается, никто не заботится о том, чтобы быстро закрыть канал, и соединение остается открытым и неиспользуемым в течение длительного времени. Это причина, по которой многие люди предлагают использовать очень низкий тайм-аут в режиме ожидания. На некоторых серверах, таких как Apache, самый низкий тайм-аут, который вы можете установить, составляет одну секунду, и часто слишком много для поддержания высоких нагрузок: если у вас есть 20000 клиентов перед вами, и они извлекают в среднем по одному объекту каждую секунду, вы будете эти 20000 подключений установлены постоянно. 20000 одновременных подключений на сервере общего назначения, таком как Apache, огромны, потребуется от 32 до 64 ГБ ОЗУ в зависимости от того, какие модули загружены, и вы, вероятно, не можете надеяться на гораздо большее увеличение даже путем добавления ОЗУ. На практике для 20000 клиентов вы можете видеть даже 40000-60000 одновременных подключений на сервере, потому что браузеры будут пытаться настроить от 2 до 3 соединений, если у них есть много объектов для извлечения.
Если вы закроете соединение после каждого объекта, количество одновременных соединений резко снизится. Действительно, он снизится на коэффициент, соответствующий среднему времени для загрузки объекта на время между объектами. Если вам нужно 50 мс для загрузки объекта (миниатюрная фотография, кнопка и т.д.), И вы загружаете в среднем 1 объект в секунду, как указано выше, тогда у вас будет только 0,05 соединения на каждого клиента, что составляет всего 1000 одновременные подключения для 20000 клиентов.
Теперь настало время установить новые подключения. Удаленные клиенты будут испытывать неприятные задержки. Раньше браузеры использовали большое количество одновременных подключений, когда keep-alive был отключен. Я помню цифры 4 на MSIE и 8 на Netscape. Это действительно разделило бы среднюю задержку на один объект на столько. Теперь, когда keep-alive присутствует повсюду, мы больше не видим таких высоких чисел, потому что это еще больше увеличивает нагрузку на удаленные серверы, а браузеры заботятся о защите интернет-инфраструктуры.
Это означает, что с сегодняшними браузерами сложнее получить услуги, не поддерживающие связь, столь же отзывчивыми, как и поддерживаемые. Кроме того, некоторые браузеры (например, Opera) используют эвристику, чтобы попытаться использовать конвейерную обработку. Конвейеризация - эффективный способ использования keep-alive, поскольку он почти устраняет задержку, отправляя несколько запросов, не дожидаясь ответа. Я попробовал это на странице со 100 маленькими фотографиями, и первый доступ примерно в два раза быстрее, чем без сохранения, но следующий доступ примерно в 8 раз быстрее, потому что ответы настолько малы, что только латентность подсчитывается (только "304" ответов).
Я бы сказал, что в идеале у нас должны быть некоторые настройки в браузерах, чтобы они поддерживали соединения между выбранными объектами и сразу же бросали их, когда страница завершена. Но мы этого не видим.
По этой причине некоторым сайтам, которым необходимо установить серверы общего назначения, такие как Apache на лицевой стороне и которым приходится поддерживать большое количество клиентов, обычно приходится отключать keep-alive. И чтобы заставить браузеры увеличить количество подключений, они используют несколько доменных имен, чтобы загрузки можно было распараллелить. Это особенно проблематично на сайтах, интенсивно использующих SSL, потому что настройка соединения еще выше, поскольку есть еще один раунд.
В настоящее время чаще наблюдается то, что такие сайты предпочитают устанавливать такие легкие интерфейсы, как haproxy или nginx, у которых нет проблем с обработкой от десятков до сотен тысяч одновременных подключений, они позволяют поддерживать работоспособность на стороне клиента и отключать это на стороне Apache. С этой стороны затраты на установление соединения почти нулевые с точки зрения ЦП и не заметны вообще с точки зрения времени. Таким образом, это обеспечивает лучшее из обоих миров: низкая латентность из-за сохранения активности с очень малыми тайм-аутами на стороне клиента и низким количеством подключений на стороне сервера. Все счастливы: -)
Некоторые коммерческие продукты дополнительно улучшают это за счет повторного использования соединений между фронтальным балансиром нагрузки и сервером и мультиплексирования всех клиентских подключений по ним. Когда серверы близки к LB, коэффициент усиления не намного выше, чем предыдущее решение, но часто требуется адаптация к приложению для обеспечения отсутствия риска пересечения сеанса между пользователями из-за неожиданного совместного использования соединения между несколькими пользователями, Теоретически этого никогда не должно быть. Реальность сильно отличается: -)