Pull to refresh
85
0
Игорь Олемской @olemskoi

CEO в Southbridge

Send message
Баннеры глаза режут. :-)
Кто ничего не делает — тот не допускает ошибок ;-)

Тем не менее, мы постоянно учимся и обучаем нашу команду.
На данный момент — да. Это вопрос времени, не только руками админов запросы распределяются к мастер-слейвам.
Нет конечно, об этом надо думать и как можно заранее. В рамках проекта WebConsult, в частности, выполняются работы, направленные на большой рост, но об этом лучше расскажут разработчики — это вопрос отдельной статьи.
Когда над проектом работает много людей, всегда будет столько же и мнений — это нормально.

В нашей компании текучка клиентов — меньше 1% и мы делаем технически все, чтобы клиенты были довольны и думали о своих бизнес процессах, а не о серверной составляющей.
Почему сразу выгнали? Сейчас администрированием занимается команда Evil Martians ( www.siliconrus.com/2013/01/centos-admin-ru-ili-kak-startapu-spravitsya-s-rastushhey-nagruzkoy-bez-administratora-v-shtate/#comment-775537840 ) — у них появился собственный ресурс, а учитывая, что они же занимаются и разработкой, так было удобнее обеим сторонам.
Зато NFS интереснее поднимать после аварии, иначе скучно. ;)
Исторически сложилось, что на данный момент работает не через websockets.

Я полностью поддерживаю их необходимость и, как указано в статье, в ближайшее время все будет :-)
Ровно с таким набором ПО, который указал в комментарии NickyX3.
Как говорят, чем проще конфигурация, тем стабильнее работает. При работе с nginx все получилось максимально прозрачно и стабильно.

NFS можно заставить работать хорошо. Но стоит ли это того? Зависит от проекта.
Код проекта хранится в GIT. По нажатию на ссылку deploy в Redmine запускается скрипт, который делает «git pull» на заданных вебах.
Подобная задача так же красиво решается с помощью capistrano — это добавляет возможность делать быстрый rollback, а так же делать деплой как из командной строки разработчика, так и через Redmine плагин, если деплой делает менеджер проекта после согласования и тестирования.
olemskoi.ru — блог системного администратора Linux, репосты интересных статей.
Согласен. У нас много нагруженных проектов и все они стабильно работают под OpenVZ.
Спасибо, очень приятно :-)
Посоветуйте дешевле :-)
Так не советуют делать конфиг.
Во-первых нет proxy_cache_lock.

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

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

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

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

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

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

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


Да и баннеры можно аналогично организовать, почему нет?
hardworm, а лучше использовать оба варианта. :-)

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity