Re: Re[4]: Как считать количество попаданий в кэш

[Михаил Панфилов]

Здравствуйте Михаил,

Конкретно у нас не так всё просто:
Во-первых там ssi, и лога получается больше, во-вторых в эти самые 8к
запросов/сек свободных ресурсов становиться меньше. Ну в третьих когда
очень нужно так и делаем, но это всё равно не удобно.

Касаемо статистики хотелось бы ещё много чего, хотя бы статистику по
каждому location подробную :) с счётчиками и прочее. Типа включения debug
по локейшену.

4 октября 2012 г., 15:47 пользователь Михаил Монашёв <
postmaster at softsearch.ru> написал:

> Здравствуйте, Михаил.
>
> > А  вот  если  строить  график  процентного попадания в кэш (полезная
> > штука  бывает), то парсить приходиться постоянно. У меня бывают пики
> > с 8к запросами в секунду на сервер. Парсить такое в реальном времени
> > я  не решаюсь. Парсить за прошлый день - вариант, но не удобный. Вот
> > если  можно было снимать такую статистику через nginx_status было бы
> > удобно :))
>
> Можно  для  подобного  писать  отдельный  лог в который будет писаться
> только $upstream_cache_status.
>
> Также можно настроить logrotate так, чтобы он часто ротировал этот лог
> и   после   ротации   дёргал   Ваш   скрипт,  который  бы  обрабатывал
> отротированный лог. 8000 запросов в секунду с $upstream_cache_status в
> логе  -  это  в худшем случаем 100-400 килобайт лога в минуту. Но даже
> если  бы  лог  был  огромным,  то для более-менее точной картины можно
> через  head  или tail брать только 10000 строчек лога. Так Вы получите
> статистику  кэширования  с  отставанием  от реальности не более, чем в
> одну  минуту  (если  logrotate  запускать  по  cron-у каждую минуту) и
> создающую минимальную нагрузку на систему.
>
> --
> С уважением,
>  Михаил                          mailto:postmaster at softsearch.ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
Панфилов Михаил
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20121004/0f1e4b74/attachment.html>