>> Ну и вот отсюда и возникли "странные желания": взять и приделать к
>> inetd prefork с pre-exec.
DVI> У меня наивный вопрос: кто ест максимум времени - fork, memmap внутри
DVI> exec или динамическая линковка (спровоцировали perl-ом и его
DVI> трансляцией)?
насколько я понимаю, то fork и exec едя
On Tue, 2010-10-19 at 17:56 +0400, Dmitry E. Oboukhov wrote:
> тут получается некоторый оверхед.
>
> то есть
> 1. процесс принимает соединение
> 2. процесс его обрабатывает
>
> в случае pre-fork/pre-exec 1 исключить нельзя.
[snip]
> Ну и вот отсюда и возникли "странные желания": взять и приделать
Tdrldo> package ModuleName;
...
Tdrldo> теперь кладем его в inetd
Tdrldo> 128 stream tcp nowait username /usr/bin/perl /usr/bin/perl
/path/to/script.pl
сорри, прямо тут писал
строка будет примерно такой:
128 stream tcp nowait username /usr/bin/perl /usr/bin/perl -MModuleName -e
process_re
>> хочется некоторых фич от inetd, однако не знаю реализовывал ли их
>> кто-нибудь.
>>
>> в частности хочется опции prefork=n (вернее даже preexec), чтобы
>> сократить время отклика на время форка и старта/инициализации
>> приложения.
PP> Хмм, а что прикажете на file descriptor 0 новому процессу
>> хочется некоторых фич от inetd, однако не знаю реализовывал ли их
>> кто-нибудь.
>>
>> в частности хочется опции prefork=n (вернее даже preexec),
SM> А зачем тогда этому сервису inetd?
ну как промежуточная стадия, когда производительность системы хочется
повысить (вернее время отклика понизит
5 matches
Mail list logo
