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