Привет, так как я являюсь автором этой цитаты, я отвечу: -)
На больших сайтах есть две большие проблемы: одновременные соединения и задержка.Одновременное соединение вызывается медленными клиентами, которые загружают контент в течение многих лет, и состояниями неактивного соединения.Эти состояния простоя соединения вызваны повторным использованием соединения для выборки нескольких объектов, известных как 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 на лицевой стороне, и которые должны поддерживать большое количество клиентов, обычно отключаютв живых.И чтобы заставить браузеры увеличивать количество подключений, они используют несколько доменных имен, чтобы загрузки могли быть распараллелены.Это особенно проблематично на сайтах, интенсивно использующих SSL, потому что настройка соединения еще выше, так как существует еще один прием в оба конца.
В настоящее время чаще всего наблюдается, что такие сайты предпочитают устанавливать легкие интерфейсы, такие как haproxy или nginx, которые без проблем обрабатывают от десятков до сотен тысяч одновременных соединений, они поддерживают поддержку активности на стороне клиента и отключают это на стороне Apache. С этой стороны, стоимость установления соединения практически равна нулю с точки зрения процессора, и совсем не заметна с точки зрения времени. Таким образом, это обеспечивает лучшее из обоих миров: низкую задержку из-за поддержания активности с очень малым временем ожидания на стороне клиента и малым количеством соединений на стороне сервера. Все счастливы: -)
Некоторые коммерческие продукты дополнительно улучшают это, повторно используя соединения между балансировщиком нагрузки на передней панели и сервером и мультиплексируя все клиентские соединения через них. Когда серверы находятся близко к LB, усиление не намного выше, чем в предыдущем решении, но часто требуется адаптация приложения, чтобы гарантировать отсутствие риска пересечения сеансов между пользователями из-за неожиданного совместного использования соединения между несколькими пользователями. , В теории это никогда не должно происходить. Реальность сильно отличается: -)