LINUX.ORG.RU

Как эстетически решить проблему долгой загрузки WEB-страницы?

 ,


1

1

Проблема в следующем, есть WEB-страница управления контроллером. Ресурсов контроллера хватает на отдачу страницы в течение 3 секунд. Эстетически прорисовка всех элементов по мере загрузки выглядит не очень привлекательно. Попытался решить проблему путем показа спинера на время заргузки страницы, визуально все красиво, но спинер также показывается не сразу, т.к. сначала грузится head-блок, в котором относительно увесистый блок стилей.

<html>
  <head>
    <style>
      <!-- блок стилей-->
    </style>
  </head>
  <script>
   <!--код показа спинера, пока не загрузится полностью страница-->
  </script>
  <body>
    <div id="spinner"/>
    <div id="content">
      <!-- сожержание страницы-->
    </div>
  </body>
</html>

Какие есть варианты решения проблемы?

★★★

Ответ на: комментарий от byko3y

ну вот получается то все наоборот, на старом хттп ваш браузер создаст 6 соединений и если среди них есть ощутимые по времени выполнения забьет ему половину пула(если сервер настоящий, а не однопотоковый), а если придет много клиентов как вы планировали сервер будет справляться с n8 одновременных запросов, а на хттп2 создаст одно и будет эффективно со сжатием гонять через него все запросы, хоть их там 150.

У всех компонентов современного сервера есть оптимальная параллеизация находится где-то на уровне десятков потоков — это касается как вычислений на CPU, так и доступа к SSD накопителю.

однопотоковые серверы рассчитаны как-будто, на то, что вместо 10и потоков одного сервера будет 10 докер-инстансов по которым запросы распределять будет балансировщик. Ну я надеюсь, что смысл заключается именно в этом, а не «пиу-пиу, рякт-рякт, быстрый хомяк плохого не посоветует». Хотя правда скорее в том, что чем меньше ваше ПО переиспользует общие ресурсы, тем больше денжищь с вас будет сдирать облачный провайдер, поэтому наврать телепузикам, что так быстрее и надежнее экономически целесообразно.

Syncro ★★★★★
()
Последнее исправление: Syncro (всего исправлений: 1)
Ответ на: комментарий от Syncro

ваш браузер создаст 6 соединений и если среди них есть ощутимые по времени выполнения забьет ему половину пула(если сервер настоящий, а не однопотоковый)

Какого «пула»? Если мы отбросим новомодные приблуды плана «сервер, который только перебрасывает запросы на другой сервер», то в плане выполнения вычислений в ответ на запрос поток HTTP/2 не отличается от соединения HTTP/1.1, то есть, будут выделяться те же ресурсы после установленяи соединений. Если не используется TLS, то даже фактор стоимости TLS handshake-а перестает влиять, и тогда 6 потоков HTTP/2 по тяжести обработки не отличаются от 6 соединений HTTP/1.1. (и в том числе потому HTTP/2 без TLS многими реализациями просто не поддерживается)

Другое дело, что по RFC 7540 клиент и сервер должны поддерживать ОТ 100 потоков, а это уже другая весовая категория.

хттп2 создаст одно и будет эффективно со сжатием гонять через него все запросы

Во-первых, HTTP/2 жмет только заголовки, payload может быть любым и не входит в протокол HTTP. Во-вторых, сжатие заголовков HTTP/2 затрачивает время CPU в обмен на экономию полосы канала, это не бесплатная штука.

$ head -c 1G </dev/urandom | /usr/bin/time gzip >/dev/null
21.69user 0.19system 0:21.95elapsed 99%CPU (0avgtext+0avgdata 1904maxresident)k
$ head -c 1G </dev/urandom | /usr/bin/time lz4 -c >/dev/null
0.35user 0.65system 0:03.28elapsed 30%CPU (0avgtext+0avgdata 9756maxresident)k
$ head -c 1G </dev/urandom | /usr/bin/time cat >/dev/null
0.02user 0.40system 0:02.95elapsed 14%CPU (0avgtext+0avgdata 2100maxresident)k
Как видишь, 50 Мбайт в секунду — это очень медленно при современных каналах. Да, HTTP/2 использует не совсем gzip, но тоже huffman-based алгоритм, главным недостатком которого является нарушение границы байтов.

По этой причине HTTP/2 может приводить к замедлению обработки на сервере по сравнению с нешифрованным и нежатым HTTP/1.1 даже при равенстве числа потоков.

вместо 10и потоков одного сервера будет 10 докер-инстансов по которым запросы распределять будет балансировщик. Ну я надеюсь, что смысл заключается именно в этом, а не «пиу-пиу, рякт-рякт, быстрый хомяк плохого не посоветует». Хотя правда скорее в том, что чем меньше ваше ПО переиспользует общие ресурсы, тем больше денжищь с вас будет сдирать облачный провайдер, поэтому наврать телепузикам, что так быстрее и надежнее экономически целесообразно.

Вот здесь я пытался понять, что ты пишешь, но не смог. Слова по отдельности ясны, предложения в целом — нет.

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от byko3y

возможно 6 потоков хттп1 создадут такую же нагрузку как 6 потоков хттп2, но штука в том, что с хттп2 браузеру нужен только 1 поток.

Какого «пула»?

обычно сервер имеет некоторое количество готовых потоков/воркеров, которым делегируется обработка запросов, т.к. порождать и закрывать их по требованию дороговато, это называется пулом и размер его на дефолтах около 10и. Если свободные потоки у сервера закончились запрос от клиента начнет ждать или получи отказ. Поэтому клиент делающий много параллельных соединений для сервера всегда хуже прокачивающего свои запросы в одном соединении.

Syncro ★★★★★
()

Какие есть варианты решения проблемы?

Можно попробовать создать раздел диска в ОЗУ и положить скриптом все файлы, необходимые вэб-серверу, туда при загрузке операционной системы. Возможно, что чтение с флэш-памяти или что там у тебя в контроллере установлено в качестве хранилища данных идёт медленно и поэтому общая цепь передачи данных из энергонезависимого хранилища данных в ОЗУ, а затем в сеть медленно отрабатывает. Напрямую из ОЗУ файлы начнут вычитываться вэб-сервером гораздо быстрее и сетевой пользователь начнёт получать интернет-страницу с твоего контроллера заметно отзывчивее.

Enthusiast ★★
()
Ответ на: комментарий от Syncro

Если свободные потоки у сервера закончились запрос от клиента начнет ждать или получи отказ

Молодец, ты описал алгоритм, как HTTP/2 клиенты ложат сервер. О чём мы тогда продолжаем разговор?

Поэтому клиент делающий много параллельных соединений для сервера всегда хуже прокачивающего свои запросы в одном соединении.

Если мы не говорим про что-то вроде prefork режима Apache, которым уже никто не пользуется (и который всё равно не поддерживает HTTP/2), то потоки воркеров нагружаются ЗАПРОСОМ, а не соединением. Как эти запросы поступят на сервер — воркера не волнует. Та же история с любыми режимами работы Nginx.

byko3y ★★★★
()