Комментарии 91
Интересная сторона вопроса, действительно такая, казалось бы, «бесконечно быстрая» величина как скорость света при современной ширине канала становится уже заметной.
Вывод напрашивается очевидный — размещать сервер поближе к своей аудитории :)
Не редко, кстати, встречаю решение, когда основной сервер «мозг» русского сайта стоит за границей (ну не все любят в России размещаться и не без причин) а сервера со статикой (картиночки, медия, документы, файлы) — размещены ближе к пользователю, в каком-то местном дата-центре. «Про запас» есть копия всего того же в европе с возможностью быстрого переключения — (вся адресация на поддоменах типа files.site.ru, img.site.ru, static.site.ru и т.д.)
Вывод напрашивается очевидный — размещать сервер поближе к своей аудитории :)
Не редко, кстати, встречаю решение, когда основной сервер «мозг» русского сайта стоит за границей (ну не все любят в России размещаться и не без причин) а сервера со статикой (картиночки, медия, документы, файлы) — размещены ближе к пользователю, в каком-то местном дата-центре. «Про запас» есть копия всего того же в европе с возможностью быстрого переключения — (вся адресация на поддоменах типа files.site.ru, img.site.ru, static.site.ru и т.д.)
Вывод напрашивается очевидный — делать меньше запросов, т.к. всегда будут пользователи с другой стороны планеты.
А у меня иной вывод напрашивается, для меня очевидный.
При неограниченном/значимым росте ширины каналов вместо технологии толстый клиент (коей на текущий момент является месиво технологий в современных вебсайтах) разработчики снова вспомнят про тонкие клиенты.
Примером такой технологии, хоть и не завершенной а значит не оптимальной по отзывчивости, может являться opera mini (страница загружается на сервере opera, там формируется снимок страницы в своем формате, и отсылается на клиент), если такой прокси-сервер будет находиться рядом с веб-сервером, то таймауты загрузок станут минимальными.
Ну и самым быстрым (по отзывчивости при толстых каналах) на текущий момент может являться следующая схема — на веб-сервере устанавливается сервер vnc/rdp/иной аналог, хоть те же полу аппаратные видеокодеки у серверов onlive, а клиент подключается по этому протоколу к браузеру, запущенному на этом же веб-сервере, открывающим страницу по localhost… При должном внимании к возможностям выбранного протокола возможно кеширование мультимедиа на стороне клиента (это если канал все таки не на столько широк как хотелось бы).
При неограниченном/значимым росте ширины каналов вместо технологии толстый клиент (коей на текущий момент является месиво технологий в современных вебсайтах) разработчики снова вспомнят про тонкие клиенты.
Примером такой технологии, хоть и не завершенной а значит не оптимальной по отзывчивости, может являться opera mini (страница загружается на сервере opera, там формируется снимок страницы в своем формате, и отсылается на клиент), если такой прокси-сервер будет находиться рядом с веб-сервером, то таймауты загрузок станут минимальными.
Ну и самым быстрым (по отзывчивости при толстых каналах) на текущий момент может являться следующая схема — на веб-сервере устанавливается сервер vnc/rdp/иной аналог, хоть те же полу аппаратные видеокодеки у серверов onlive, а клиент подключается по этому протоколу к браузеру, запущенному на этом же веб-сервере, открывающим страницу по localhost… При должном внимании к возможностям выбранного протокола возможно кеширование мультимедиа на стороне клиента (это если канал все таки не на столько широк как хотелось бы).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Теперь ясно, почему у меня админка адворда так тормозит.
Извините за мысли в слух и может быть не совсем по теме топика.
Клиент-серверная архитектура с запросами от клиента в данном случае будет в любом случае иметь задержки. У нас обязательно будет один файл с разметкой, один css и один js, как минимум. Картинки еще. Пускай первый будет загружен сразу, а последующие все вместе. Задержек не избежать.
А если в запрос клиента включать идентификаторы кэшированных файлов, а серверу отсылать все необходимое для отображения страницы одним пакетом, без ожидания запросов со стороны клиента? Да, часть клиентов не загружает картинки, часть не загружает js. Все это можно предусмотреть в запросе. Клиент, который просто запрашивает страницу, без дополнительных ухищрений получит все скопом, без последующих запросов.
Помимо идеальных задержек есть еще и всякие пока что не очень быстрые в этом отношении беспроводные технологии.
Клиент-серверная архитектура с запросами от клиента в данном случае будет в любом случае иметь задержки. У нас обязательно будет один файл с разметкой, один css и один js, как минимум. Картинки еще. Пускай первый будет загружен сразу, а последующие все вместе. Задержек не избежать.
А если в запрос клиента включать идентификаторы кэшированных файлов, а серверу отсылать все необходимое для отображения страницы одним пакетом, без ожидания запросов со стороны клиента? Да, часть клиентов не загружает картинки, часть не загружает js. Все это можно предусмотреть в запросе. Клиент, который просто запрашивает страницу, без дополнительных ухищрений получит все скопом, без последующих запросов.
Помимо идеальных задержек есть еще и всякие пока что не очень быстрые в этом отношении беспроводные технологии.
Если сильно захотеть (или сильно не хотеть), то разметка, css и js вполне могут помещаться в одном файле. По хорошему надо смотреть конкретные случаи, конкретную ЦА.
Не, запихнуть в один файл все можно, но потом это будет при каждом запросе передаваться клиенту. А в предлагаемом мной варианте кэширование все так же работает, как и должно, не гоняем туда-сюда лишние запросы и имеющиеся файлы.
Можно обойтись двумя файлами: HTML и CSS+JS.
А картинки? Два файла это все равно удвоение задержки.
Там даже на транспортном уровне есть о чего поговорить, но там движение есть.
Там даже на транспортном уровне есть о чего поговорить, но там движение есть.
НЛО прилетело и опубликовало эту надпись здесь
В чём именно бяка будет, что-то не соображу?
При отключении посетителем js он не увидит и css?
А его кто-то отключает?
Почему не увидит-то? Я вот про эту технику: http://bolknote.ru/2011/04/19/~3185/.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Не останется. Я вот про это: http://bolknote.ru/2011/04/19/~3185/.
НЛО прилетело и опубликовало эту надпись здесь
Не знаю, не изучал. А чего в нём костыльного? «Сжатие» CSS и JS перед выкладкой на продакшн многие используют. Отчего бы ещё одну строчку в этот скрипт не добавить?
НЛО прилетело и опубликовало эту надпись здесь
Ну а что такого в этом ограничении? Ещё одна строка в скрипте, можно заменить обычным sed'ом.
Насчёт быстрее спорить не буду, детально исследовать надо в разных браузерах и условиях, у меня времени на это нет.
Насчёт быстрее спорить не буду, детально исследовать надо в разных браузерах и условиях, у меня времени на это нет.
НЛО прилетело и опубликовало эту надпись здесь
Он надёжный. Синтаксически «*/» может встретиться в правильном JS только в определённых местах, правится это тоже единообразно.
Если я не ошибаюсь, то это не совсем то. Я говорю о передаче пользователю содержащихся на странице ресурсов вместе с самой страницей. До запроса этих элементов браузером. Браузер понятия не имеет о том, что там будет на странице до того, как распарсит html. Я говорю о том, что можно передавать при запросе страницы, при первом запросе — требующиеся для отображения страницы css, js и картинки. Один запрос — одна страница. Это если грубо.
А про SPDY, Server-Push не читали?
Ха! 500мс? Да я на этих ваших ТриДжи (нет кабельного пока) уже привык в ГуглоРидере новости с хабра колёсиком нажимать (открытие в фоновой странице). Пока ленту глазами пробежишь (кликнув 2-3 интересующие новости), переключаешься на уже загрузившуюся первую вкладку.
И после этого ненавидишь мобильные версии сайтов, которые норовят показать 5 комментов и подгружают дальше при скролле…
Спасибо за клик колесиком, не знал о такой возможности. Век живи — век учись!
Реально помогает и не только при 3G. Чтобы десять раз не переключаться между той же лентой и новостями, например.
Реально помогает и не только при 3G. Чтобы десять раз не переключаться между той же лентой и новостями, например.
Да Вы что!?
Хотите сказать что не пользуетесь ежедневно 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 в системе?
Спасибо за F6, не знал. А вот Ctrl + F4 как-то неожиданно сработало.
А я как дурак который год Ctrl+L жму вместо F6 >_<
А что у нормальных людей делает Ctrl+F4? А то у меня, как и у любого не сильно заморачивающегося переделками линуксоида, это комбо переключает на четвёртый рабочий стол.
А что у нормальных людей делает Ctrl+F4? А то у меня, как и у любого не сильно заморачивающегося переделками линуксоида, это комбо переключает на четвёртый рабочий стол.
Ctrl+D Ctrl+C Ctrl+V — это уж совсем простые сочетания :) хотя и их некоторые не знают до сих пор
Из всего перечисленного не пользовался только F6, аналогично комментарию ниже, нажимал Ctrl+L
Из всего перечисленного не пользовался только F6, аналогично комментарию ниже, нажимал Ctrl+L
Еще Ctrl+K, а вместо Ctrl+F4 использую Ctrl+W
Ctrl + W, кстати, очень много где работает для закрытия вкладки или окна (а в терминале, как известно, стирает последнее набранное слово). Ещё часто можно выйти из программы, нажав Ctrl + Q.
А ещё оконные менеджеры в Linux позволяют нажать на Alt и перетаскивать окно за любое место. :)
А если нажать среднюю кнопку (колёсико), то можно менять размер окна без длительной охоты за краешком (но это не работает в XFwm, например).
А если нажать среднюю кнопку (колёсико), то можно менять размер окна без длительной охоты за краешком (но это не работает в XFwm, например).
При гонянии инфы по HTTP туды сюды забыли о том, что всё это не начнётся пока TCP не установит сессию, а это ещё несколько запросов. Есть способы всё это ускорить, тот же TCP Fast Open.
keep alive почти полностью решает проблему: используется уже установленное соединение для десятков других запросов
Это не keep alive, а related соединения. Да они спасают сильно, но я в основном о первом запросе страницы.
Первый запрос — 5-10% от общего времени загрузки. Тогда уж DNS нужно ускорять, это сильнее поможет.
Ну там время всё же более-менее предсказуемо, у меня, например, DNS запрос идёт в пределах 400ms. Но DNS меня меньше коробит, т.к. везде где я обитаю используется BIND на шлюзе, посему все запросы кэшируются и последующие ответы идут за 1ms, вместо 300ms. И время кэширования DNS ответа, явно больше чем время жизни TCP соединения.
А вот и про ускорение DNS.
Кстати, если нужно именно постоянно что-то передавать между клиентом и сервером, да ещё и в обе стороны (то есть сервер может отправлять информацию клиенту, а не только клиент может делать запросы на сервер), то может оказаться эффективным использователь веб-сокеты (я про них писал недавно).
Кстати, если нужно именно постоянно что-то передавать между клиентом и сервером, да ещё и в обе стороны (то есть сервер может отправлять информацию клиенту, а не только клиент может делать запросы на сервер), то может оказаться эффективным использователь веб-сокеты (я про них писал недавно).
НЛО прилетело и опубликовало эту надпись здесь
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 обещанных не останется.
В Linux можно попробовать поиграться с алгоритмами congestion window: linuxgazette.net/135/pfeiffer.html
Насчет достижения скорости света в вакууме — это уже сделано.
Есть оптоволокно для мажоров, с пустой сердцевиной.
Окупает себя на высокочастотной торговле :-)
Есть оптоволокно для мажоров, с пустой сердцевиной.
Окупает себя на высокочастотной торговле :-)
НЛО прилетело и опубликовало эту надпись здесь
Скорость света при движении по нему всё равно ниже, чем в вакууме.
НЛО прилетело и опубликовало эту надпись здесь
Вы посчитали или с потолка эту цифру взяли?
НЛО прилетело и опубликовало эту надпись здесь
Пустотелое волокно? Воздухом? А свет по изогнутому волокну как движется-то? Мне кажется, оно пустотелое в сердцевине, а по краям у него что-то ещё, какая-то среда, которая позволяет свету преломляться и свет в ней тоже движется, нет? А потери скорости в этой среде вы считаете?
плюс учтём всякие мелочи, типа движения по криволинейной траектории, время на переотражения и всё равно получится мизерЧто-то я не вижу почему там мизер получится.
В одномодовом оптоволокне нет никакого криволинейного движения, там диаметр сердцевины сравним с длиной волны света.
НЛО прилетело и опубликовало эту надпись здесь
Скажите, почему Вы не перевели термин «latency» на русский язык словом «задержка» или словосочетанием «время ожидания»? Что заставило Вас выбрать слово «латентность»?
Это не переводная статья, и я не переводил. Я воспользовался общеупотребительным термином. Вариант «задержка» упоминается в первом же абзаце статьи для тех, кому вдруг слово «латентность» непонятно.
Ваши дефиниции пролонгируют тайминги чтения вашего эссе.
И добро бы только пролонгировали; дык они ж ещё провоцируют и другие речи на пиджин-инглише или аналогичном дикарском жаргоне.
Например, вон там у одного из комментаторов «ассеты бандлятся»да «финальный профит».
Например, вон там у одного из комментаторов «ассеты бандлятся»
Если мои основные клиенты в Бразилии, а сервера стоят в Японии, то это повод задумать «а перенести ли сервера в Бразилию?».
Если мои основные клиенты в Японии и раз в месяц заходят клиенты из Бразилии, то стоит посчитать о целесообразности открытия узла в Бразилии. Если не целесообразно, то можно забить на клиента (как бы грустно это не звучало).
Если же мои клиенты по всему миру, то нужно использовать глобальный CDN.
Если мои основные клиенты в Японии и раз в месяц заходят клиенты из Бразилии, то стоит посчитать о целесообразности открытия узла в Бразилии. Если не целесообразно, то можно забить на клиента (как бы грустно это не звучало).
Если же мои клиенты по всему миру, то нужно использовать глобальный CDN.
Если говорить о временах с безграничной шириной канала, первым же запросом можно загрузить все содержимое сервера, а дальше все работает локально. Так сказать, скачать весь интернет :)
<зануда mode>
Тут надо сделать два замечания. Wolfram Alpha показывает самое короткое расстояния с учетом шарообразности Земли. Такой путь из Рио в Токио действительно используется в авиации (с небольшими корректировками). Но сигнал пойдет по магистральным каналам примерно так: Rio->Los Angeles->Tokyo, то есть фактическое расстояние будет больше, чем 86.7 ms + задержка на IX (она минимальная, но все-таки есть).
</зануда mode>
Когда считают время передачи по сети, то считают время от выхода из сетевухи сервера до сетевухи клиента, чтобы аннигилировать время обработки запроса на сервере/клиенте.
Тут надо сделать два замечания. Wolfram Alpha показывает самое короткое расстояния с учетом шарообразности Земли. Такой путь из Рио в Токио действительно используется в авиации (с небольшими корректировками). Но сигнал пойдет по магистральным каналам примерно так: Rio->Los Angeles->Tokyo, то есть фактическое расстояние будет больше, чем 86.7 ms + задержка на IX (она минимальная, но все-таки есть).
</зануда mode>
Когда считают время передачи по сети, то считают время от выхода из сетевухи сервера до сетевухи клиента, чтобы аннигилировать время обработки запроса на сервере/клиенте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Латентность при загрузке веб-страниц