Как стать автором
Обновить

Комментарии 11

Есть статистика сколько сейчас в среднем страницы потребляют цпу и озу на устройствах пользователей?

Во всех этих CDN бесит то, что приходится в NoScript постоянно указывать очередной поддомен, которые постоянно меняются.

Почему постоянно меняется? Вы сами делаете поддомен для вашего CDN-ресурса и он остается неизменным.
НЛО прилетело и опубликовало эту надпись здесь
Почему Вы считаете, что «нагрузкой» может быть только CPU или RAM. Разве NET безлимитный и каждый хостинг на каждый сервер заводит сотни и тысячи гигабитов (да я знаю, что это не реализуемо, я спец. преувеличиваю). И тогда надо смотреть не со стороны 1 пользователя сайта на WP «о котором ни кто не знает» (и видимо ни кто не пользуется как следствие), а в первую очередь со стороны сервера. Потом со стороны пользователя. Потом со стороны перспективы (какая сейчас посещаемость? растет ли она? как быстро растёт? как скоро ресурсов текущего сервера станет не хватать? Какого ресурса будет не хватать? Можно ли увеличить ресурс и сколько это будет стоит?). И только рассмотрев вопрос со всех сторон и поняв, что через 2-3 месяца посещаемость вырастет на столько, что кеш NGINX'а (пусть и очень отличный кеш) начнёт не справляться с отдачей статики так как упрётся в пропускную способность канала. Тут сравниваем, сколько будет стоит арендовать ещё один сервер (пусть даже слабее) для раздачи статики и стоимость использования CDN — и делаем выводы.

Делаем или первое или второе — снижаем нагрузку на канал, а так же чутка на CPU (NGINX же должен принимать решение, что отдавать из кеша). И живём дальше пока не упрёмся в ресурсы опять.

Но раз Вы не способны понять: для чего, для кого и в каких целях нужен CDN — может быть не стоило такой глупый комментарий оставлять?
какая то очень быстрая скорость для вордпресса. это голая тема без ничего?
обычно вордпресс без плагинов, изображений около секунды грузится.
если это диви какой нибудь — то и 1.5

Вы слишком критичны в своем комментарии. Возможно, внедрение CDN и не изменит картину координально, однако, все же может вносить ощутимый профит. Существует достаточно много проектов с тяжелыми ассетами и порой сервер, находящийся в твоей стране гораздо быстрее сможет отдать его вам, вместо того, чтобы тянуть из другого конца света.


Берем тестовый сайт на Вордпрессе, о котором никто кроме нас не знает.

А теперь берем проект, на котором чуть больше, чем 1 пользователь. И каждая загрузка страницы влечет за собой с десяток обращений веб-сервера к файловой системе (без учета браузерного кеша). Когда таких запросов становится 100/1000/10000rps, то не так уже и весело тратить на ресурсы сервера на отдачу статического контента.


Да, оптимизация одного часто используемого SQL запроса может привнести куда заметнее эффект, но и CDN никто не отменяет. Особенно там, где пользователи регионально разбросаны.

На заре Рунета, в самом начале 2000-х, жители Южно-Сахалинска или Петропавловска-Камчатского могли дожидаться полной загрузки простой веб-страницы полновесные 5, а то и все 10, минут.

У вас это личный опыт или фантазии на тему? Может быть дело было в плохой древней АТС и модеме на 14400? Или тощих магистральных каналах через спутник, потому что кабелей ещё не завезли? По моему опыту в конце 90-х американские сайты вполне себе быстро загружались на европейской части этой страны и на тощем модемном соединении.

IP-пакетам по большей части всё равно, на какие расстояния они будут передаваться, планета у нас не такая большая. Задержки в основном набираются в очередях маршрутизаторов, и чем их количество меньше, тем быстрее пакеты доезжают.
При передаче больших файлов задержка передачи IP-пакетов HTTP-запроса практически исчезает на фоне времени передачи всего файла, которая напрямую коррелирует только с быстродействием файловой системы сервера и толщиной самого узкого канала на пути к клиенту. При больших нагрузках на промежуточные маршрутизаторы и каналы пакеты могут отбрасываться (сейчас можно считать, что у нас практически идеальные каналы и в них нет ошибок передачи) и тогда добавится время на TCP-таймауты и перепосылку IP-пакетов.

Поэтому не стоит приплетать взаимное географическое расположение CDN-серверов и клиентов. CDN-это всего лишь один из видов горизонтального шардинга дисковых и сетевых ресурсов с минимизацией хопов до клиента. Перенос файлов в географическом пространстве нужен не для уменьшения временных задержек из-за конечной скорости света в оптоволокне, а уменьшения количества хопов и нагрузки на магистральные каналы с распределением удельной нагрузки на диски серверов.
IP-пакетам по большей части всё равно, на какие расстояния они будут передаваться, планета у нас не такая большая. Задержки в основном набираются в очередях маршрутизаторов, и чем их количество меньше, тем быстрее пакеты доезжают.

не могу с вами согласиться.
смотрю в гугле расстояние до NY, делю на скорость света в оптоволокне, умножаю на два — получаю идеальный RTT 80мс. пингую — получаю 120мс.
до москвы получаю идеальный RTT 7мс, реальный — 13мс.
нужно учесть, что реальная длина оптоволокна заметно больше, чем расстояние от точки до точки по прямой, так что основной вклад в RTT вносят «временные задержки из-за конечной скорости света в оптоволокне», а не маршрутизаторы (конечно, бывают и исключения, спорить глупо).

При передаче больших файлов

CDN — это не только многогигабайтные файлы, картинки на сайте или фоточки в условном инстаграмме на телефоне вполне могут тянуться с CDN. установка https-соединения при RTT 100мс уже вносит вполне ощутимую задержку.

P.S. работу CDN осложняет то, что «географически близко» ещё не гарантирует малых задержек. трафик между провайдерами в нашем городе бегает через Москву, а раньше, помнится, зачастую и через европу бегал.
По большей части всё так и есть, но если прикинуть (грубо округляя) время передачи файла в 1 Мбайт на скорости в 100 Мбит/с будет того же порядка, что и задержка передачи первого бита этого файла через Атлантику ~ 80 мс. Здесь есть табличка с задержками в трансатлантических кабелях. Ещё раз повторю свою мысль: приближение контента не так сильно влияет на скорость его получения клиентом, как снятие нагрузки с основного сервера сайта и распределение этой нагрузки на несколько серверов CDN.

А уж если говорить о стриминговом медиаконтенте, на который так упирают в статье, то ему эти задержки передачи по кабелю вообще не ощутимы из-за предварительной буферизации контента в плеерах.

PS. Работу сайтов осложняет в основном слабо технически обученные генераторы контента, которые вместо 50 кБайт картинки заливают её оригинал на пару-тройку метров ;) Если я глазами вижу, как картинка загружается, то это именно такой клинический случай. Из-за больших дисков и толстых каналов многим стало наплевать, что у них на сайте за контент и какого он там размера. Ну а мода на длинные бэкграунды да с видео помогает CDN-провайдерам успешно зарабатывать.

ИМХО, хорошая общая обзорная статья. Хотелось бы попросить дополнительно осветить темы:

  1. потоковый CDN

  2. синхронизация (в итоге, я понимаю) содержимого между оригинальным сервером и точками распространения

Считаю это важными темами, т.к. размеры нашей страны требуют CDN даже внутри страны (т.е. их придётся создавать самим, руками. Мы же, вроде как, программисты?..). Спасибо!

Зарегистрируйтесь на Хабре , чтобы оставить комментарий