>метрики, мониторинг и агрегацию логов
Это все делаем вручную, к сожалению, то есть надо что-то проанализировать, лог например, пишем свой парсер, мониторинг примерно так же устроен.
Проблема в том, что стандартные решения, при наших нагрузках, например мониторинг Tomcat-а, уронят нам всю систему =)
Сейчас поводов для беспокойства пока нет, база растет примерно на 2-3Гб в месяц, так что пока только выбираем правильное решение. Склоняемся к разработке своего функционала.
Посмотрел proxy_cache_lock, это не много не то, вернее вообще не то =)
Как я понимаю, данная опция просто блокирует остальных, кто ждет кеша, пока первый кто-то его не заполнит.
Думаю в нашем случае это ухудшит производительность сделав заметным небольшие «замирания» системы, а так все асинхронно, никто ни от кого не зависит.
Спасибо!
Ну это проблема на скорости ни как не сказывается, просто размер растет, соответственно дешевле будет разбить на несколько кусков, чем хранить все в одном месте.
В таких сайтах плохо то, что слишком много функционала.
Например я даже не понял как отредактировать изображение после загрузки. Ну а обычный юзер, возможно даже не пойме как его загрузить.
ИМХО
+1
Сейчас это через bit.ly сделано, но редирект идет все равно на длинный URL (у нас имя файла как md5 хеш).
Так же очень нужна поддержка crop-а, то есть сохранения только выделенной области изображения, если кто знает библиотеку для canvas буду рад ссылке.
Это здорово.
У нас в среднем 70-85К постоянных соединений (subscribers) и параллелить их приходится в ручную (просто раскидываем разные ренжы). Так что 0.4 ждем именно из-за балансинга out of the box.
Сверху Cackle, снизу Hypercomments — найдите хотя бы 1 преимущество последних ;)
>метрики, мониторинг и агрегацию логов
Это все делаем вручную, к сожалению, то есть надо что-то проанализировать, лог например, пишем свой парсер, мониторинг примерно так же устроен.
Проблема в том, что стандартные решения, при наших нагрузках, например мониторинг Tomcat-а, уронят нам всю систему =)
Вот на одни из серверов:
malta2020:/var/cache/nginx# du. -h
…
122M.
malta2020:/var/cache/nginx# find. -type f | wc -l
17223
То есть 122мб кеш и всего 17223 файла.
Как я понимаю, данная опция просто блокирует остальных, кто ждет кеша, пока первый кто-то его не заполнит.
Думаю в нашем случае это ухудшит производительность сделав заметным небольшие «замирания» системы, а так все асинхронно, никто ни от кого не зависит.
DNS round-robin — рассматривали, но он в разы менее гибок (если надо что-то срочно менять), чем round-robin на JS.
Все идет именно к этому =)
PS: спасибо за proxy_cache_lock, посмотрю!
Ну это проблема на скорости ни как не сказывается, просто размер растет, соответственно дешевле будет разбить на несколько кусков, чем хранить все в одном месте.
Например я даже не понял как отредактировать изображение после загрузки. Ну а обычный юзер, возможно даже не пойме как его загрузить.
ИМХО
Сейчас это через bit.ly сделано, но редирект идет все равно на длинный URL (у нас имя файла как md5 хеш).
Так же очень нужна поддержка crop-а, то есть сохранения только выделенной области изображения, если кто знает библиотеку для canvas буду рад ссылке.
У нас в среднем 70-85К постоянных соединений (subscribers) и параллелить их приходится в ручную (просто раскидываем разные ренжы). Так что 0.4 ждем именно из-за балансинга out of the box.
А вообще 0.4.х очень ждем из-за встроенной поддержки балансера.