Comments 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… При должном внимании к возможностям выбранного протокола возможно кеширование мультимедиа на стороне клиента (это если канал все таки не на столько широк как хотелось бы).
UFO just landed and posted this here
UFO just landed and posted this here
Теперь ясно, почему у меня админка адворда так тормозит.
Извините за мысли в слух и может быть не совсем по теме топика.
Клиент-серверная архитектура с запросами от клиента в данном случае будет в любом случае иметь задержки. У нас обязательно будет один файл с разметкой, один css и один js, как минимум. Картинки еще. Пускай первый будет загружен сразу, а последующие все вместе. Задержек не избежать.
А если в запрос клиента включать идентификаторы кэшированных файлов, а серверу отсылать все необходимое для отображения страницы одним пакетом, без ожидания запросов со стороны клиента? Да, часть клиентов не загружает картинки, часть не загружает js. Все это можно предусмотреть в запросе. Клиент, который просто запрашивает страницу, без дополнительных ухищрений получит все скопом, без последующих запросов.
Помимо идеальных задержек есть еще и всякие пока что не очень быстрые в этом отношении беспроводные технологии.
Клиент-серверная архитектура с запросами от клиента в данном случае будет в любом случае иметь задержки. У нас обязательно будет один файл с разметкой, один css и один js, как минимум. Картинки еще. Пускай первый будет загружен сразу, а последующие все вместе. Задержек не избежать.
А если в запрос клиента включать идентификаторы кэшированных файлов, а серверу отсылать все необходимое для отображения страницы одним пакетом, без ожидания запросов со стороны клиента? Да, часть клиентов не загружает картинки, часть не загружает js. Все это можно предусмотреть в запросе. Клиент, который просто запрашивает страницу, без дополнительных ухищрений получит все скопом, без последующих запросов.
Помимо идеальных задержек есть еще и всякие пока что не очень быстрые в этом отношении беспроводные технологии.
Если сильно захотеть (или сильно не хотеть), то разметка, css и js вполне могут помещаться в одном файле. По хорошему надо смотреть конкретные случаи, конкретную ЦА.
Не, запихнуть в один файл все можно, но потом это будет при каждом запросе передаваться клиенту. А в предлагаемом мной варианте кэширование все так же работает, как и должно, не гоняем туда-сюда лишние запросы и имеющиеся файлы.
Можно обойтись двумя файлами: HTML и CSS+JS.
А картинки? Два файла это все равно удвоение задержки.
Там даже на транспортном уровне есть о чего поговорить, но там движение есть.
Там даже на транспортном уровне есть о чего поговорить, но там движение есть.
UFO just landed and posted this here
В чём именно бяка будет, что-то не соображу?
При отключении посетителем js он не увидит и css?
А его кто-то отключает?
Почему не увидит-то? Я вот про эту технику: http://bolknote.ru/2011/04/19/~3185/.
UFO just landed and posted this here
UFO just landed and posted this here
Не останется. Я вот про это: http://bolknote.ru/2011/04/19/~3185/.
UFO just landed and posted this here
Не знаю, не изучал. А чего в нём костыльного? «Сжатие» CSS и JS перед выкладкой на продакшн многие используют. Отчего бы ещё одну строчку в этот скрипт не добавить?
UFO just landed and posted this here
Ну а что такого в этом ограничении? Ещё одна строка в скрипте, можно заменить обычным sed'ом.
Насчёт быстрее спорить не буду, детально исследовать надо в разных браузерах и условиях, у меня времени на это нет.
Насчёт быстрее спорить не буду, детально исследовать надо в разных браузерах и условиях, у меня времени на это нет.
UFO just landed and posted this here
Он надёжный. Синтаксически «*/» может встретиться в правильном 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.
Кстати, если нужно именно постоянно что-то передавать между клиентом и сервером, да ещё и в обе стороны (то есть сервер может отправлять информацию клиенту, а не только клиент может делать запросы на сервер), то может оказаться эффективным использователь веб-сокеты (я про них писал недавно).
Кстати, если нужно именно постоянно что-то передавать между клиентом и сервером, да ещё и в обе стороны (то есть сервер может отправлять информацию клиенту, а не только клиент может делать запросы на сервер), то может оказаться эффективным использователь веб-сокеты (я про них писал недавно).
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 обещанных не останется.
В Linux можно попробовать поиграться с алгоритмами congestion window: linuxgazette.net/135/pfeiffer.html
Насчет достижения скорости света в вакууме — это уже сделано.
Есть оптоволокно для мажоров, с пустой сердцевиной.
Окупает себя на высокочастотной торговле :-)
Есть оптоволокно для мажоров, с пустой сердцевиной.
Окупает себя на высокочастотной торговле :-)
UFO just landed and posted this here
Скорость света при движении по нему всё равно ниже, чем в вакууме.
UFO just landed and posted this here
Вы посчитали или с потолка эту цифру взяли?
UFO just landed and posted this here
Пустотелое волокно? Воздухом? А свет по изогнутому волокну как движется-то? Мне кажется, оно пустотелое в сердцевине, а по краям у него что-то ещё, какая-то среда, которая позволяет свету преломляться и свет в ней тоже движется, нет? А потери скорости в этой среде вы считаете?
плюс учтём всякие мелочи, типа движения по криволинейной траектории, время на переотражения и всё равно получится мизерЧто-то я не вижу почему там мизер получится.
В одномодовом оптоволокне нет никакого криволинейного движения, там диаметр сердцевины сравним с длиной волны света.
UFO just landed and posted this here
Скажите, почему Вы не перевели термин «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>
Когда считают время передачи по сети, то считают время от выхода из сетевухи сервера до сетевухи клиента, чтобы аннигилировать время обработки запроса на сервере/клиенте.
Sign up to leave a comment.
Латентность при загрузке веб-страниц