Re: Маленький patch для nginx реализующий request/sec

On Thu, May 01, 2008 at 02:01:27AM +0400, Kirill A. Korinskiy wrote:

> Maxim Dounin -> nginx-ru@...  @ Wed, 30 Apr 2008 22:30:11 +0400:
> 
>  MD> не делается никаких блокировок, меж тем операции -
ни разу не
>  MD> атомарные.  Т.е. на выходе вообще говоря - цена на дрова.
> 
> Во время написания этого всего я думал о блокировках.
Основная проблема
> возникла в том, что в nginx нет четких блокировок для shared
memory. Т.е. в
> случае если используется sys/shm.h понятно как и что
делать, а вот в случае
> если нет его в системе и используется nginx'овская shared
memory не понятно
> что и как делать.

ngx_shmtx_create()
ngx_shmtx_lock()
ngx_shmtx_unlock()

--

-- 
Игорь Сысоев
http://sysoev.ru

Re: Маленький patch для nginx реализующий request/sec

Igor Sysoev -> nginx-ru@...  @ Thu, 1 May 2008 08:37:17 +0400:

 IS> ngx_shmtx_create()
 IS> ngx_shmtx_lock()
 IS> ngx_shmtx_unlock()

Спасибо.

Свой patch поправил.

--

-- 
| |*| |  Kirill A. Korinskiy <catap@...>
| | |*|  proud (maniac)? (developer|hacker)
|*|*|*|  http://catap.ru/ - +7 (916) 3-604-704 - xmpp:catap@...

Re: изменить текст в html на лету :)

+1 за модуль парсинга

Очень помогло бы решить некоторые задачи, сейчас приходится
использовать каскадно sub и addition.

2008/4/9 dewil <dewil.ru <at> gmail.com>:
> расширю вопрос.
>  нужно пройти по всему телу html документа и сделать
замену регексом.
>  (а бывает и не одним)
>
>  какие могут быть пути решения?
>  nginx может отдать все тело (если это html) на какой нить
внешний парсер?
>
>  sub_module
>  addition_module
>  не решают такую задачу.
>

--

-- 
Regards,
Oleg

Вопрос по будущему кэшированию.

Здравствуйте.

Просматриваю выступление Игоря
http://rutube.ru/tracks/620185.html?v=6b2f565cd57460216cf99deec521c7e6
и никак не пойму, как предполагается удалять
страничку из кэша.

X-Accel-New   выходит   очень  удобным  при  кэширование  генерящегося
контента  и  чертовски неудобным при кэшировании
статики. Выходит, что
если  мне  нужно  какую-то  картинку удалить из кэша, то
нужно сделать
запрос  к  nginx-у,  чтобы  он проксировал ответ к апачу, а
апач выдал
X-Accel-New с нужным ключём, который надо удалить. Ну или
вместо апача
может быть сам nginx с перловым хэндлером.

Как удалять из будущего кэша статику?

--

С уважением,
Михаил Монашёв, SoftSearch.ru
mailto:postmaster@...
ICQ# 166233339
http://michael.mindmix.ru/
Без бэкапа по жизни.

Re: Вопрос по будущему кэшированию.

Добрый вечер.
А зачем кешировать статику?
Как я понял, кеширование - способ не заставлять бекенд
много раз
генерировать динамический редкоизменяющийся ответ.
А для статики - rsync.

03.05.08, Михаил Монашёв<postmaster <at> softsearch.ru> написал(а):
> Здравствуйте.
>
>  Просматриваю выступление Игоря
>  http://rutube.ru/tracks/620185.html?v=6b2f565cd57460216cf99deec521c7e6
>  и никак не пойму, как предполагается удалять
страничку из кэша.
>
>  X-Accel-New   выходит   очень  удобным  при  кэширование  генерящегося
>  контента  и  чертовски неудобным при кэшировании
статики. Выходит, что
>  если  мне  нужно  какую-то  картинку удалить из кэша, то
нужно сделать
>  запрос  к  nginx-у,  чтобы  он проксировал ответ к апачу, а
апач выдал
>  X-Accel-New с нужным ключём, который надо удалить. Ну или
вместо апача
>  может быть сам nginx с перловым хэндлером.
>
>  Как удалять из будущего кэша статику?
>
>
>  --

Re: Вопрос по будущему кэшированию.

Re[2]: Вопрос по будущему кэшированию.

Здравствуйте, Борис.

БД> А зачем кешировать статику?

Хранение  и  раздача  статики  - две совершенно разные
задачи. Поэтому
хочется часто запрашиваемые картинки кэшировать на
быстрых sas-дисках,
а редко запрашиваемые хранить на медленных и дешёвых sata-дисках.

--

С уважением,
Михаил Монашёв, SoftSearch.ru
mailto:postmaster@...
ICQ# 166233339
http://michael.mindmix.ru/
Без бэкапа по жизни.

Re: Вопрос по будущему кэшированию.

Михаил Монашёв пишет:
> Здравствуйте, Борис.
>
> БД> А зачем кешировать статику?
>
> Хранение  и  раздача  статики  - две совершенно разные
задачи. Поэтому
> хочется часто запрашиваемые картинки кэшировать
на быстрых sas-дисках,
> а редко запрашиваемые хранить на медленных и
дешёвых sata-дисках.
>   

Кешируй через proxy_store, где хочешь и что хочешь. И
физически удаляй 
когда нужно инвалидировать.

> --
>
> С уважением,
> Михаил Монашёв, SoftSearch.ru
> mailto:postmaster@...
> ICQ# 166233339
> http://michael.mindmix.ru/
> Без бэкапа по жизни.
>
>
>
>
>   

--

-- 
С уважением, Дмитрий Лоханский.

ООО "Z-Решения"
http://www.zsupport.ru

Re: Re[2]: Вопрос по будущему кэшированию.

Но ведь мы будем изначально знать, какая статика
будет запрашиваться чаще?
И заранее часто запрашиваемую поместить на быстрый
диск, а редко - на медленный.
А хранить это все равно можно на бекенде, и тем же rsync'ом
синхронизировать с быстрым и медленным сервером.

03.05.08, Михаил Монашёв<postmaster <at> softsearch.ru> написал(а):
> Здравствуйте, Борис.
>
>  БД> А зачем кешировать статику?
>
>  Хранение  и  раздача  статики  - две совершенно разные
задачи. Поэтому
>  хочется часто запрашиваемые картинки кэшировать
на быстрых sas-дисках,
>  а редко запрашиваемые хранить на медленных и
дешёвых sata-дисках.
>
>
>  --
>
>  С уважением,
>  Михаил Монашёв, SoftSearch.ru
>  mailto:postmaster <at> softsearch.ru
>  ICQ# 166233339
>  http://michael.mindmix.ru/
>  Без бэкапа по жизни.
>
>
>

Re[4]: Вопрос по будущему кэшированию.

Здравствуйте, Борис.

БД> Но ведь мы будем изначально знать, какая статика
будет запрашиваться чаще?

Откуда мы это будем знать заранее? Особенно если
постоянно что-то
новое закачивают...

БД> И заранее часто запрашиваемую поместить на
быстрый диск, а редко - на медленный.
БД> А хранить это все равно можно на бекенде, и тем же rsync'ом
БД> синхронизировать с быстрым и медленным сервером.

--

С уважением,
Михаил Монашёв, SoftSearch.ru
mailto:postmaster@...
ICQ# 166233339
http://michael.mindmix.ru/
Без бэкапа по жизни.