Веб-сервер за рубежом + статика в России = ускорение скорости загрузки страницы

[andreypaa]

По идее сработает с любым провайдером (хостером), не обязательно Hetzner

[olemskoi]

Сработает конечно же с любым зарубежным хостером.

[JustLuckyGuy]

Причем тут Hetzner вообще не понятно. Обычный проксируещий конфиг с кешем в nginx.

[vsespb]

Вероятно, это обосновывает всю идею с двумя хостерами. Hetzner дешёвый, а российских хост можно взять меньшей мощности.

[Denysh]

а где посоветуете взять в россии сервера для кэширования?

[olemskoi]

а где посоветуете взять в россии сервера для кэширования?

Это уже «на вкус и цвет» ;-) Попробуйте посмотреть разные варианты на ресурсах типа ispreview.

[olemskoi]

hardworm, а лучше использовать оба варианта. :-)

[Kastrulya]

С Варнишем не сравнивали?

[saharchuk]

И сколько времени пройдет, после замены на сервере основном сервере /favicon.ico до его обновления в кеше?
Я не нашел в приведенном примере настройки или описания, что позволить обновить изображение, только аргументы для css.
Исходя из того, что после обновления сайта мы меняете хеш для всех css и возможно js, для медиа контента такой вариант не имеет смысла, хотя по вашему конфигу можно, иначе браузер заново загружает все изображения, а кеш заново наполняется.
Так, что я думаю 30 дней ждать обновления баннера или иконки это не совсем верный вариант. Как вы решаете эту задачу?

[olemskoi]

Для замены favicon можно пойти аналогичным путем с сериалами. Достаточно добавить tag:

<link href="/favicon.ico?123" rel="shortcut icon" type="image/x-icon" />

Да и баннеры можно аналогично организовать, почему нет?

[saharchuk]

Я не имел ввиду, что нельзя подменить путь к favicon. Я не отрицал возможности добавление хеша и к изображением.
Я не нахожу ответа на самый обычный вопрос, который часто возникает вообще при кешировании.
У меня >80 Гб статики. Ваше предложение? Держать для каждой ссылки свой хеш?
Если, да, то если строить его по данным файла прибавить не мало i/o нагрузки. Не говоря о дополнительной части в изменении кода.
Есть второй 1 хеш для обновления сайта, как часто делают для css & js. Но если взять один хеш для всех изображений, то все что я хотел донести, при замене пару Кб простого favicon, у вас весь кеш станет не валидным и будет заново наполнятся заливая все 80 Гб.
Все это я описал сразу. И хочу услышать общее решение в этом случае, как управлять обновлением контента.

[olemskoi]

Можно удалить конкретный объект из кэша, но вряд ли это сделать автоматически намного проще, чем организовать сериалы со стороны программирования.
По-поводу io нагрузки — это уже зависит от алгоритма, на мой взгляд.

[saharchuk]

В следующем примере статика будет прозрачно проксироваться с сервера в Hetzner и кэшироваться на российском сервере, таким образом повторная загрузка будет происходить только при изменениях на сервере в Hetzner.

К сожалению, вы не показали решение. Так что я не могу согласится с вашим конфигом. Не смотря на имеющееся дополнение про css. Максимум это «конфиг для проксирования статитики, а для обновления нужно обновить алгоритм построенние ссылок, для внесение хеша к измененным элементам». А это не малое упущение, иначе действительно еще один пример обычного конфига, с добавлением хеша, даже не через location, а через аргументы с добавлением IfIsEvil.

[saharchuk]

Этот вариантов я указывал как один из возможных. Хотел услышать как решает проблему автор, или хотя бы его мнение на нее.

[olemskoi]

Я эту задачу решаю на уровне программирования, ruby on rails.

Вряд ли есть более простое решение. Разве что указывать меньший интервал кэширования proxy_cache_valid, но тогда и от expires придется отказаться.

[drakmail]

Этот способ идеально подходит для rails приложений. В остальных случаях его использовать без дополнительной подготовки скорее всего не получится.

[L3n1n]

Так не советуют делать конфиг.
Во-первых нет proxy_cache_lock. Если найти файл который все еще не сохранился на вашем кэш сервере то забить ваш сервер можно даже утилитой ab (хотя при вашем proxy_cache_key "$uri$is_args$args"; и так забить ваш диск не составит проблем).

Во-вторых вы сами тестировали нормально ваш пример? debug nginx включали? Файлы берутся из кэша или проксируются при каждом запросе?

[olemskoi]

Так не советуют делать конфиг.
Во-первых нет proxy_cache_lock.

Согласен, исправился.

(хотя при вашем proxy_cache_key "$uri$is_args$args"; и так забить ваш диск не составит проблем).

L3n1n, может быть у Вас есть идеи, как обойти этот момент при работе с сериалами?

Во-вторых вы сами тестировали нормально ваш пример? debug nginx включали? Файлы берутся из кэша или проксируются при каждом запросе?

Тестировал раньше и специально проверил с использованием debug еще раз — файлы берутся из кэша. А почему вопрос, есть какие-то опасения?