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