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