Pull to refresh

Comments 18

Не совсем понятна тогда необходимость размещения сайта в amazon'е. Если есть стабильная посещаемость, и отсутствует нужда в CDN, так почему бы не переехать целиком на VPS или даже dedicated?
Конгениально, Киса! Воистину в ограничениях рождаются прекрасные решения.

Вот только вопрос по производительности/доступности Хетцнера.

Плюс что мы делать в случае отвала Хетцнера? Или это тупо решается одной константой на уровне приложения?
ИМХО, амазон совершенно не выгоден если проект запихивается на пару виртуалок. Проще использовать какой-нить Linode или другой простой VPS сервис
Амазон дает больше гибкости в плане управления ресурсами — как мощностями (можно изменить тип виртуалки с небольшим даунтаймом), так и дисками — можно подключать EBS тома по необходимости. Под каждый проект надо выбирать, Амазон это не универсальная серебрянная пуля, конечно)
Амазон дает гибкость и берет за это деньги. Смысл отказываться от части гибкости, для экономии части денег..? Если выбирать компромиссный вариант, то уж комплексный. Например своё облако развернуть.
А почему просто не хранить статику не в амазон, а сразу заливать на тот отдельный сервер. Зачем все эти синхронизации?
Это чтобы новый контент, который появляется на амазоновском сервере (например картинка в посте в блоге), сразу же появлялся и на сервере статики.
Это я понял, по этому и написал:

А почему просто не хранить статику не в амазон
Т.е. сразу заливать ее на сервер статики да и все.
В случае недоступности сервера статики в момент публикации фотографии, картинка безвозвратно пропадет.
UFO just landed and posted this here
Вообще странно, что S3 выходит дорогим, ведь он для статики и сделан.

S3 выходит дешевым, это траффик выходит дорогим. Предлагают такой вариант работы с ним.
Если фотогрфии редко перезаливаются, либо удаляются, можно поставить на дешевый хостинг nginx и настроить его таким образом, чтобы он при 404 дергал файл с бэкэнда и сохранял у себя. Таким образом избавляемся от синхронизации.

Либо как альтернатива, можно поставить на сервер статики какой нибудь суровый кэш. Новые страницы в случае с новостным сайтом запрашиваются чаще, чем старые. Таким образом большинство самого востребованного контента будет в кэше.

Правда тогда наверное правильнее брать два хетзнерообразных хостинга т.к. при падении сервера статики сайт будет совсем не презентабелен :)
1. HTML жмется в ~десять раз;
2. Среди 30,000 посетителей наверняка львиная доля — это не новые посетители. Особенно если это сайт с ежедневной лояльной аудиторией, такой, как новостной. Следовательно, статика даже близко не будет отдаваться в количестве 30,000 * 2MB;
3. При этих условиях на 30,000 дневных просмотров там получится счет в несколько раз меньше чем вы предположили.
На хороших новостных сайтах контент (вместе с фотографиями, основными трафикоедами) обновляется ежедневно, да и новостной сайт это просто для примера, на его месте может быть промо сайт с рекламной кампанией и тяжелыми флеш-роликами. Получается в своем роде master-slave архитектура, с надежным мастером на амазоне (с дублированием между зонами, автоматическими снэпшотами, сложной логикой приложения) и слейвами на дешевом хостинге, которых не жалко потерять.

К суровым nginx кэшем нормальный вариант, но придется сильно заморочиться с Expires и временем жизни кэша, чтобы и hit rate был хороший и контент всегда отдавался актуальный.
Не, ну amazon силен же своим CDN. Брать вместо него шарик на хецнере я не вижу никакого смысла. Тогда в самом деле, проще и дешевле целиком захоститься там.
UFO just landed and posted this here
inotify + *sync не дают же гарантий, что файл, который изменился, будет валидно синхронизирован.
Если сервисы нестабильны, а в амазоне так и будет, через пару месяцев такая каша начнется со статикой. Надо еще какой-то механизм инвалидации контента писать.

Не проще поставить монгу, например, и запихать туда статику, пусть она сама разбирается с консистентностью?
Sign up to leave a comment.

Articles

Change theme settings