Розуміння стану журналу мережевих мереж Chrome "Затримано"

У мене такий хронологічний журнал:

Я нічого не розумію в цьому: у чому різниця між заповненими сірими смугами та прозорими сірими смугами.

Google дає розбиття цих полів у розділі Оцінка продуктивності мережі документації щодо DevTools.

Витяг з часових ресурсів мережі ресурсів :

Заглухли / заблокували

Час, який запит витратив на очікування, перш ніж його можна було надіслати. Цей час враховує будь-який час, витрачений на переговори про проксі. Крім того, цей час буде включати, коли браузер чекає, коли вже встановлене з'єднання стане доступним для повторного використання, дотримуючись максимально шість TCP-з'єднань Chrome за правило початку.

(Якщо ви забудете, Chrome має посилання "Пояснення" у підказці наведення курсора та на панелі "Час".)

По суті, основна причина, яку ви побачите в цьому, полягає в тому, що Chrome одночасно завантажує лише 6 файлів на сервер, а інші запити будуть зупинені, поки не з'явиться слот для з'єднання.

Це не обов’язково щось, що потребує виправлення, але одним із способів уникнути затримки стану є розподіл файлів на декілька доменних імен та / або серверів, маючи на увазі CORS , якщо застосовний до ваших потреб, проте HTTP2, мабуть, кращий варіант йти вперед. Пакет ресурсів (наприклад, JS та CSS конкатенація) також може допомогти зменшити кількість зупинених з'єднань.

DevTools: [мережа] пояснює порожні рядки перед запитом

Далі досліджено та встановлено, що немає суттєвої різниці між нашими діапазонами стійла та черги. Обидві обчислюються з дельти інших часових позначок, а не надаються від netstack або візуалізації.

---

Наразі, якщо ми чекаємо, коли розетка стане доступною:

• ми будемо називати це застопором, якщо відбудуться деякі проксі-переговори
• ми будемо називати це чергою, якщо не потрібно було працювати проксі / ssl.

https://developers.google.com/web/tools/chrome-devtools/network-performance/understanding-resource-timing

Це походить з офіційного сайту Chome-devtools і це допомагає. Ось я цитую:

• Черга Якщо запит у черзі, він вказував, що:
  • Запит був відкладений механізмом візуалізації, оскільки він вважається нижчим пріоритетом, ніж критичні ресурси (наприклад, сценарії / стилі). Це часто трапляється із зображеннями.
  • Цей запит було призупинено, щоб чекати появи недоступного сокета TCP, який збирається звільнити.
  • Запит був затриманий, оскільки браузер дозволяє лише шість TCP-з'єднань за походженням на HTTP 1. Затрачений час на створення записів кеш-диска (як правило, дуже швидкий.)
• Затримка / блокування часу, який запит витрачав на очікування, перш ніж його можна було надіслати. Він може чекати з будь-якої з причин, описаних для черги. Крім того, цей час включає будь-який час, витрачений на переговори про проксі.

У моєму випадку сторінка надсилає кілька запитів з різними параметрами, коли вона була відкрита. Тож більшість «затримуються». Після відправлених запитів негайно "затримується". Уникати зайвих запитів було б краще (лінуватися ...).

Оскільки багато людей приїжджають сюди, налагоджуючи свій повільний веб-сайт, я хотів би повідомити вас про мій випадок, який жодне з пояснень Google не допомогло вирішити. Мої величезні затримки (іноді 1 хв) були спричинені тим, що Apache, що працює на Windows, мав занадто мало робочих ниток для обробки з'єднань, тому вони ставали в чергу.

Це може стосуватися вас, якщо у журналі apache є така примітка:

Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

Ця проблема вирішена в Apache httpd.conf. Відмітка: Включіть conf / extra / httpd-mpm.conf

І відредагуйте httpd-mpm.conf

<IfModule mpm_winnt_module>
   ThreadLimit              2000
   ThreadsPerChild          2000
   MaxConnectionsPerChild   0
</IfModule>

Зауважте, що вам може не знадобитися 2000 ниток або може знадобитися більше. 2000 рік був нормальним для моєї справи.