Comments 91
Интересная сторона вопроса, действительно такая, казалось бы, «бесконечно быстрая» величина как скорость света при современной ширине канала становится уже заметной.
Вывод напрашивается очевидный — размещать сервер поближе к своей аудитории :)
Не редко, кстати, встречаю решение, когда основной сервер «мозг» русского сайта стоит за границей (ну не все любят в России размещаться и не без причин) а сервера со статикой (картиночки, медия, документы, файлы) — размещены ближе к пользователю, в каком-то местном дата-центре. «Про запас» есть копия всего того же в европе с возможностью быстрого переключения — (вся адресация на поддоменах типа files.site.ru, img.site.ru, static.site.ru и т.д.)
Вывод напрашивается очевидный — размещать сервер поближе к своей аудитории :)
Не редко, кстати, встречаю решение, когда основной сервер «мозг» русского сайта стоит за границей (ну не все любят в России размещаться и не без причин) а сервера со статикой (картиночки, медия, документы, файлы) — размещены ближе к пользователю, в каком-то местном дата-центре. «Про запас» есть копия всего того же в европе с возможностью быстрого переключения — (вся адресация на поддоменах типа files.site.ru, img.site.ru, static.site.ru и т.д.)
+5
Вывод напрашивается очевидный — делать меньше запросов, т.к. всегда будут пользователи с другой стороны планеты.
+3
А у меня иной вывод напрашивается, для меня очевидный.
При неограниченном/значимым росте ширины каналов вместо технологии толстый клиент (коей на текущий момент является месиво технологий в современных вебсайтах) разработчики снова вспомнят про тонкие клиенты.
Примером такой технологии, хоть и не завершенной а значит не оптимальной по отзывчивости, может являться opera mini (страница загружается на сервере opera, там формируется снимок страницы в своем формате, и отсылается на клиент), если такой прокси-сервер будет находиться рядом с веб-сервером, то таймауты загрузок станут минимальными.
Ну и самым быстрым (по отзывчивости при толстых каналах) на текущий момент может являться следующая схема — на веб-сервере устанавливается сервер vnc/rdp/иной аналог, хоть те же полу аппаратные видеокодеки у серверов onlive, а клиент подключается по этому протоколу к браузеру, запущенному на этом же веб-сервере, открывающим страницу по localhost… При должном внимании к возможностям выбранного протокола возможно кеширование мультимедиа на стороне клиента (это если канал все таки не на столько широк как хотелось бы).
При неограниченном/значимым росте ширины каналов вместо технологии толстый клиент (коей на текущий момент является месиво технологий в современных вебсайтах) разработчики снова вспомнят про тонкие клиенты.
Примером такой технологии, хоть и не завершенной а значит не оптимальной по отзывчивости, может являться opera mini (страница загружается на сервере opera, там формируется снимок страницы в своем формате, и отсылается на клиент), если такой прокси-сервер будет находиться рядом с веб-сервером, то таймауты загрузок станут минимальными.
Ну и самым быстрым (по отзывчивости при толстых каналах) на текущий момент может являться следующая схема — на веб-сервере устанавливается сервер vnc/rdp/иной аналог, хоть те же полу аппаратные видеокодеки у серверов onlive, а клиент подключается по этому протоколу к браузеру, запущенному на этом же веб-сервере, открывающим страницу по localhost… При должном внимании к возможностям выбранного протокола возможно кеширование мультимедиа на стороне клиента (это если канал все таки не на столько широк как хотелось бы).
0
UFO just landed and posted this here
UFO just landed and posted this here
Теперь ясно, почему у меня админка адворда так тормозит.
+3
Извините за мысли в слух и может быть не совсем по теме топика.
Клиент-серверная архитектура с запросами от клиента в данном случае будет в любом случае иметь задержки. У нас обязательно будет один файл с разметкой, один css и один js, как минимум. Картинки еще. Пускай первый будет загружен сразу, а последующие все вместе. Задержек не избежать.
А если в запрос клиента включать идентификаторы кэшированных файлов, а серверу отсылать все необходимое для отображения страницы одним пакетом, без ожидания запросов со стороны клиента? Да, часть клиентов не загружает картинки, часть не загружает js. Все это можно предусмотреть в запросе. Клиент, который просто запрашивает страницу, без дополнительных ухищрений получит все скопом, без последующих запросов.
Помимо идеальных задержек есть еще и всякие пока что не очень быстрые в этом отношении беспроводные технологии.
Клиент-серверная архитектура с запросами от клиента в данном случае будет в любом случае иметь задержки. У нас обязательно будет один файл с разметкой, один css и один js, как минимум. Картинки еще. Пускай первый будет загружен сразу, а последующие все вместе. Задержек не избежать.
А если в запрос клиента включать идентификаторы кэшированных файлов, а серверу отсылать все необходимое для отображения страницы одним пакетом, без ожидания запросов со стороны клиента? Да, часть клиентов не загружает картинки, часть не загружает js. Все это можно предусмотреть в запросе. Клиент, который просто запрашивает страницу, без дополнительных ухищрений получит все скопом, без последующих запросов.
Помимо идеальных задержек есть еще и всякие пока что не очень быстрые в этом отношении беспроводные технологии.
0
Если сильно захотеть (или сильно не хотеть), то разметка, css и js вполне могут помещаться в одном файле. По хорошему надо смотреть конкретные случаи, конкретную ЦА.
0
Не, запихнуть в один файл все можно, но потом это будет при каждом запросе передаваться клиенту. А в предлагаемом мной варианте кэширование все так же работает, как и должно, не гоняем туда-сюда лишние запросы и имеющиеся файлы.
0
Можно обойтись двумя файлами: HTML и CSS+JS.
0
А картинки? Два файла это все равно удвоение задержки.
Там даже на транспортном уровне есть о чего поговорить, но там движение есть.
Там даже на транспортном уровне есть о чего поговорить, но там движение есть.
0
UFO just landed and posted this here
В чём именно бяка будет, что-то не соображу?
0
При отключении посетителем js он не увидит и css?
0
А его кто-то отключает?
0
Почему не увидит-то? Я вот про эту технику: http://bolknote.ru/2011/04/19/~3185/.
+2
UFO just landed and posted this here
UFO just landed and posted this here
Не останется. Я вот про это: http://bolknote.ru/2011/04/19/~3185/.
+1
UFO just landed and posted this here
Не знаю, не изучал. А чего в нём костыльного? «Сжатие» CSS и JS перед выкладкой на продакшн многие используют. Отчего бы ещё одну строчку в этот скрипт не добавить?
0
UFO just landed and posted this here
Ну а что такого в этом ограничении? Ещё одна строка в скрипте, можно заменить обычным sed'ом.
Насчёт быстрее спорить не буду, детально исследовать надо в разных браузерах и условиях, у меня времени на это нет.
Насчёт быстрее спорить не буду, детально исследовать надо в разных браузерах и условиях, у меня времени на это нет.
0
UFO just landed and posted this here
Он надёжный. Синтаксически «*/» может встретиться в правильном JS только в определённых местах, правится это тоже единообразно.
0
Если я не ошибаюсь, то это не совсем то. Я говорю о передаче пользователю содержащихся на странице ресурсов вместе с самой страницей. До запроса этих элементов браузером. Браузер понятия не имеет о том, что там будет на странице до того, как распарсит html. Я говорю о том, что можно передавать при запросе страницы, при первом запросе — требующиеся для отображения страницы css, js и картинки. Один запрос — одна страница. Это если грубо.
0
В SPDY есть механизм push — сервер может сразу заслать ресурсы, если уверен что они потребуются. Т.е. HTML, CSS, JS и даже результаты каких-нибудь AJAX-ов, можно засунуть клиенту в один присест.
0
А про SPDY, Server-Push не читали?
0
Ха! 500мс? Да я на этих ваших ТриДжи (нет кабельного пока) уже привык в ГуглоРидере новости с хабра колёсиком нажимать (открытие в фоновой странице). Пока ленту глазами пробежишь (кликнув 2-3 интересующие новости), переключаешься на уже загрузившуюся первую вкладку.
+3
И после этого ненавидишь мобильные версии сайтов, которые норовят показать 5 комментов и подгружают дальше при скролле…
+2
Странно, что вконтактик и на 3джи работает сносно — сразу видна мотивация разрботчиков сайта — ведь хомячкам не объяснишь про латентность и особенности радиосвязи — приходится напрягаться и оптимизировать. Не то что разработчики корпоративного софта…
+2
Спасибо за клик колесиком, не знал о такой возможности. Век живи — век учись!
Реально помогает и не только при 3G. Чтобы десять раз не переключаться между той же лентой и новостями, например.
Реально помогает и не только при 3G. Чтобы десять раз не переключаться между той же лентой и новостями, например.
+1
Да Вы что!?
Хотите сказать что не пользуетесь ежедневно Ctrl+T F6 Ctrl+F4 в браузере и Ctrl+D Ctrl+C Ctrl+V Ctrl+Shift+ESC Winkey в системе?
Хотите сказать что не пользуетесь ежедневно Ctrl+T F6 Ctrl+F4 в браузере и Ctrl+D Ctrl+C Ctrl+V Ctrl+Shift+ESC Winkey в системе?
+3
Спасибо за F6, не знал. А вот Ctrl + F4 как-то неожиданно сработало.
+3
А я как дурак который год Ctrl+L жму вместо F6 >_<
А что у нормальных людей делает Ctrl+F4? А то у меня, как и у любого не сильно заморачивающегося переделками линуксоида, это комбо переключает на четвёртый рабочий стол.
А что у нормальных людей делает Ctrl+F4? А то у меня, как и у любого не сильно заморачивающегося переделками линуксоида, это комбо переключает на четвёртый рабочий стол.
0
Ctrl+D Ctrl+C Ctrl+V — это уж совсем простые сочетания :) хотя и их некоторые не знают до сих пор
Из всего перечисленного не пользовался только F6, аналогично комментарию ниже, нажимал Ctrl+L
Из всего перечисленного не пользовался только F6, аналогично комментарию ниже, нажимал Ctrl+L
0
Еще Ctrl+K, а вместо Ctrl+F4 использую Ctrl+W
+1
Ctrl + W, кстати, очень много где работает для закрытия вкладки или окна (а в терминале, как известно, стирает последнее набранное слово). Ещё часто можно выйти из программы, нажав Ctrl + Q.
+1
А ещё оконные менеджеры в Linux позволяют нажать на Alt и перетаскивать окно за любое место. :)
А если нажать среднюю кнопку (колёсико), то можно менять размер окна без длительной охоты за краешком (но это не работает в XFwm, например).
А если нажать среднюю кнопку (колёсико), то можно менять размер окна без длительной охоты за краешком (но это не работает в XFwm, например).
+1
При гонянии инфы по HTTP туды сюды забыли о том, что всё это не начнётся пока TCP не установит сессию, а это ещё несколько запросов. Есть способы всё это ускорить, тот же TCP Fast Open.
+1
keep alive почти полностью решает проблему: используется уже установленное соединение для десятков других запросов
0
Это не keep alive, а related соединения. Да они спасают сильно, но я в основном о первом запросе страницы.
0
Первый запрос — 5-10% от общего времени загрузки. Тогда уж DNS нужно ускорять, это сильнее поможет.
0
Ну там время всё же более-менее предсказуемо, у меня, например, DNS запрос идёт в пределах 400ms. Но DNS меня меньше коробит, т.к. везде где я обитаю используется BIND на шлюзе, посему все запросы кэшируются и последующие ответы идут за 1ms, вместо 300ms. И время кэширования DNS ответа, явно больше чем время жизни TCP соединения.
0
Интернет только для Вас? Мы говорим про миллионы случайных пользователей, для которых делаем сайты быстрее, а не про настройку сервера, чтобы конкретно у Вас сайт загружался быстрее молнии
0
А вот и про ускорение DNS.
Кстати, если нужно именно постоянно что-то передавать между клиентом и сервером, да ещё и в обе стороны (то есть сервер может отправлять информацию клиенту, а не только клиент может делать запросы на сервер), то может оказаться эффективным использователь веб-сокеты (я про них писал недавно).
Кстати, если нужно именно постоянно что-то передавать между клиентом и сервером, да ещё и в обе стороны (то есть сервер может отправлять информацию клиенту, а не только клиент может делать запросы на сервер), то может оказаться эффективным использователь веб-сокеты (я про них писал недавно).
0
UFO just landed and posted this here
Long Fat Network.
en.m.wikipedia.org/wiki/Bandwidth-delay_product
itperformancemanagement.blogspot.ru/2010/04/tcp-throughput-over-long-fat-networks.html?m=1
— особенности TCP не позволят получить 100% отдачи от скорости канала при высоких задержках.
Недавно наблюдали, как 100Мбит (теоретических) при пинге 60мс превращаются в 35 реальных (goodput) Мбит.
И это происходит только из-за одного аналога «запроса» с веб-странички — ожидания подтверждения клиента, что пакеты дошли без ошибок.
Если же поверх приторможенного TCP мы будем ждать 9 последовательных AJAX запросов, то все «тормоза» перемножаются… И 1 мегабита из 100 обещанных не останется.
en.m.wikipedia.org/wiki/Bandwidth-delay_product
itperformancemanagement.blogspot.ru/2010/04/tcp-throughput-over-long-fat-networks.html?m=1
— особенности TCP не позволят получить 100% отдачи от скорости канала при высоких задержках.
Недавно наблюдали, как 100Мбит (теоретических) при пинге 60мс превращаются в 35 реальных (goodput) Мбит.
И это происходит только из-за одного аналога «запроса» с веб-странички — ожидания подтверждения клиента, что пакеты дошли без ошибок.
Если же поверх приторможенного TCP мы будем ждать 9 последовательных AJAX запросов, то все «тормоза» перемножаются… И 1 мегабита из 100 обещанных не останется.
+2
В Linux можно попробовать поиграться с алгоритмами congestion window: linuxgazette.net/135/pfeiffer.html
0
Насчет достижения скорости света в вакууме — это уже сделано.
Есть оптоволокно для мажоров, с пустой сердцевиной.
Окупает себя на высокочастотной торговле :-)
Есть оптоволокно для мажоров, с пустой сердцевиной.
Окупает себя на высокочастотной торговле :-)
0
UFO just landed and posted this here
Скорость света при движении по нему всё равно ниже, чем в вакууме.
0
UFO just landed and posted this here
Вы посчитали или с потолка эту цифру взяли?
0
UFO just landed and posted this here
Пустотелое волокно? Воздухом? А свет по изогнутому волокну как движется-то? Мне кажется, оно пустотелое в сердцевине, а по краям у него что-то ещё, какая-то среда, которая позволяет свету преломляться и свет в ней тоже движется, нет? А потери скорости в этой среде вы считаете?
0
плюс учтём всякие мелочи, типа движения по криволинейной траектории, время на переотражения и всё равно получится мизерЧто-то я не вижу почему там мизер получится.
0
В одномодовом оптоволокне нет никакого криволинейного движения, там диаметр сердцевины сравним с длиной волны света.
0
UFO just landed and posted this here
Скажите, почему Вы не перевели термин «latency» на русский язык словом «задержка» или словосочетанием «время ожидания»? Что заставило Вас выбрать слово «латентность»?
+1
Если мои основные клиенты в Бразилии, а сервера стоят в Японии, то это повод задумать «а перенести ли сервера в Бразилию?».
Если мои основные клиенты в Японии и раз в месяц заходят клиенты из Бразилии, то стоит посчитать о целесообразности открытия узла в Бразилии. Если не целесообразно, то можно забить на клиента (как бы грустно это не звучало).
Если же мои клиенты по всему миру, то нужно использовать глобальный CDN.
Если мои основные клиенты в Японии и раз в месяц заходят клиенты из Бразилии, то стоит посчитать о целесообразности открытия узла в Бразилии. Если не целесообразно, то можно забить на клиента (как бы грустно это не звучало).
Если же мои клиенты по всему миру, то нужно использовать глобальный CDN.
0
Если говорить о временах с безграничной шириной канала, первым же запросом можно загрузить все содержимое сервера, а дальше все работает локально. Так сказать, скачать весь интернет :)
0
<зануда mode>
Тут надо сделать два замечания. Wolfram Alpha показывает самое короткое расстояния с учетом шарообразности Земли. Такой путь из Рио в Токио действительно используется в авиации (с небольшими корректировками). Но сигнал пойдет по магистральным каналам примерно так: Rio->Los Angeles->Tokyo, то есть фактическое расстояние будет больше, чем 86.7 ms + задержка на IX (она минимальная, но все-таки есть).
</зануда mode>
Когда считают время передачи по сети, то считают время от выхода из сетевухи сервера до сетевухи клиента, чтобы аннигилировать время обработки запроса на сервере/клиенте.
Тут надо сделать два замечания. Wolfram Alpha показывает самое короткое расстояния с учетом шарообразности Земли. Такой путь из Рио в Токио действительно используется в авиации (с небольшими корректировками). Но сигнал пойдет по магистральным каналам примерно так: Rio->Los Angeles->Tokyo, то есть фактическое расстояние будет больше, чем 86.7 ms + задержка на IX (она минимальная, но все-таки есть).
</зануда mode>
Когда считают время передачи по сети, то считают время от выхода из сетевухи сервера до сетевухи клиента, чтобы аннигилировать время обработки запроса на сервере/клиенте.
+1
Sign up to leave a comment.
Латентность при загрузке веб-страниц