Идея модуля для nginx - счетчик

[Eugene]

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

Евгений

>Да бессмысленно гадать, что будет тормозить, а что нет.
>Такие вещи мерить надо. То есть сначала сделать версию, которая
>работает, а потом, когда тормозить начнет - мерить что конкретно
>потребляет ресурсы, сколько, и думать, как это обойти.
>
>Бекэнд с хранением всех данных в MySQL при несложной структуре и
>правильном написании без проблем будет 100 загрузок в секунду делать,
>на средненьком железе (1-ядерном П4). Хоть на PHP, хоть на perl...
>
>On 3/13/06, Eugene <my-subscr at mail.ru> wrote:
>  
>
>>Я думаю, проблема не столько в размере данных, сколько в скорости
>>обработки. Если для этого подключить "тяжелую артиллерию" ввиде mysql,
>>больших скриптов и т.п., то тормоза гарантированы. Пока данные идут в
>>одну сторону, там что-то запускается, обрабатывает, выгружается - ждать
>>устанешь.
>>Последняя идея - сделать счетчик на встроенном перле.
>>Вот интересно, сколько соединений смогут обрабатываться перлом? Если я
>>правильно понял, то обработка блокирующая - то есть другие процессы
>>будут ждать первого, прежде чем смогут передать ему запрос?
>>
>>Евгений
>>
>>    
>>
>>>Делать счёт именно в nginx'е большого смысла нет. Ответ, отдаваемый
>>>счётчиком настолько мал (килобайты), что он целиком помещается в
>>>ядерный TCP буфер, после чего сервер просто закрывает сокет.
>>>Остаётся только проблема чтения запроса. Если переложить её на
>>>FreeBSD'шный httpready accept фильтр, то тогда счётчик может вообще
>>>держать одноврменно только одно соедиение.
>>>
>>>
>>>Игорь Сысоев
>>>http://sysoev.ru
>>>
>>>
>>>      
>>>
>>
>>    
>>
>
>
>--
>Alexey Polyakov
>  
>