Здравствуйте, любой, Вы писали:

CF>>Не совсем понял: из какого файла?

Л>        my $data;
Л>        open(FILE, '/home/user/public_html/test.html');
Л>        read(FILE, $data, -s FILE);
Л>        close(FILE);

Это однократный запрос, он ни на что не влияет. В моей последней девелопмент-версии веб-сервера все мелкие статические файлы вообще обрабатываются в главном процессе, без форков. Меня интересует динамическая часть, которая в моём примере из первого поста для простоты заменена статическим XML-содержимым, и которую я не могу оставить обрабатываться в главном процессе, тормозя реакцию на новые входящие коннекты.

CF>>У меня чтение идёт из сокета, и его я уже перенёс в до-форковую часть,
Л>Интересно, как же оно тогда работает.

В смысле? Работает так же, как и раньше, только чтение и парсинг HTTP-запроса выполняется не после форка, а до него, в главном процессе.

Здравствуйте, dilmah, Вы писали:


CF>>Почему я считаю, что подсчёт ссылок здесь ни при чём: если мы сделали копию всей памяти (неважно, реальную или "ссылочную"), то у нас все переменные, все хэши, все массивы — всё раздвоилось. Как в старом процессе была переменная A со счётчиком ссылок, пусть, 5, так и в новом процессе будет такая же переменная A с точно таким же (уже своим) счётчиком ссылок 5. Переменные нового процесса не ссылаются на переменные старого, и наоборот, поэтому значения счётчиков в результате самого форка поменяться не могут (не считая переменных, затронутых самим форком, таких как возвращаемое им значение, но таких переменных очень мало по сравнению с общим объёмом памяти). Поменяться счётчики могут лишь позже, когда начнутся присвоения переменных в процессе дальнейшего выполнения программы, но это уже другой вопрос.

D>да, но перл производит запись даже тогда, когда кажется что он только читает. Когда перловые данные просто используются на чтение, то в них меняются счетчики ссылок => происходит запись => происходит page fault и копирование данных, которого в идеале можно было бы избежать.

А перловая реализация форка вызывает это чтение или нет? Просто пример цикла в стресс-тесте от meandr работает только с двумя переменными. Весь балласт, который я добавляю в начале, висит мёртвым грузом, и ни единого обращения к нему в процессе работы цикла не происходит, даже на чтение. Тем не менее, время вырастает в 20 раз. Одними лишь затратами на копирование большего объёма памяти это объяснить сложно. Даже если учесть постраничность копирования памяти — ну на пять процентов оно будет медленнее, ну двадцать, ну пусть даже в два раза это будет медленнее, но не на порядок же!

Re[4]: [perl] Тормознутые fork'и?
Ну очевидно что дело не в fork, с этим я думаю вы не будете спорить. Нужно посмотреть в каких состояниях сидят ваши созданные процессы, смотреть по top или ps. Ну и поглядеть что выдает strace

CF>Mem: 762148k total, 661060k used, 101088k free, 23424k buffers


В определённых случаях форк() сначала копирует всю память процесса, у тебя её 661Мб, может тут собака порылась?

http://en.wikipedia.org/wiki/Fork_(operating_system)#Fork_and_page_sharing

Здравствуйте, CaptainFlint, Вы писали:

1)Ставишь http://www.lighttpd.net/
2)Переделываешь свой "веб сервер" под FastCGI.
Статику раздаешь при помощи lighttpd остальное заворачиваешь в свой "сервер".
Если мне не изменяет склероз lighttpd может запустить несколько экземпляров FastCGI демона.

Здравствуйте, avpavlov, Вы писали:

CF>>Mem: 762148k total, 661060k used, 101088k free, 23424k buffers

A>В определённых случаях форк() сначала копирует всю память процесса, у тебя её 661Мб, может тут собака порылась?

Это строчка из глобального состояния системы. 661 метр — это всего занято, а не каким-то процессом.

Здравствуйте, CaptainFlint, Вы писали:

D>>при copy on write, копирование выполняется постранично (4 кб) по мере того как наступают page faults. Разумеется, это медленнее обычного копирования.

CF>А насколько медленнее? Есть какие-нибудь данные на этот счёт?

В общем, провёл я несколько экспериментов, набросав сишную прожку, которая выделяет 16 метров памяти, делает форк и бежит по этой памяти с 4-килобайтным шагом, меняя по одному байтику. Скорость прогона программы сразу уменьшилась на порядок. (На всякий случай я заменил цикл на пробежку с тем же количеством шагов, но с периодом в 1 байт, чтобы убедиться, что замедление не вызвано самим циклом: действительно, на скорости исходного варианта это практически не сказалось.) Так что спасибо за наводку, похоже, действительно, проблема именно в этом.

В результате я решил остановиться на достигнутом и оставить вариант сервера, о котором я упоминал в первом посте (однопоточная обработка статики, многопоточная — динамики). Результирующая производительность вполне удовлетворительная.

Спасибо всем за помощь и участие.

Здравствуйте, WolfHound, Вы писали:

WH>1)Ставишь http://www.lighttpd.net/
WH>2)Переделываешь свой "веб сервер" под FastCGI.
WH>Статику раздаешь при помощи lighttpd остальное заворачиваешь в свой "сервер".
WH>Если мне не изменяет склероз lighttpd может запустить несколько экземпляров FastCGI демона.

Дело в том, что изначально сервер писался как раз для того, чтобы избавить пользователей от необходимости устанавливать и/или настраивать дополнительное ПО, а также чтобы можно было запускать приложение, не имея рутовых прав.