Держите perl XSUB SharedObject загруженным под mod_perl

Я написал оболочку Perl XSUB для очень простого C API (для которого у меня нет исходного кода).

C API состоит из 4 функций. Одна из них возвращает «дескриптор» (просто int), и это значение должно быть передано обратно в любую из трех других функций, чтобы получить правильный внутренний «объект» для вызова. Предполагается, что C API хранит список этих объектов и выдает нужный для предоставленного дескриптора.

При запуске в автономном скрипте все работает отлично.

Теперь я пытаюсь запустить этот API под apache2 с помощью mod_perl. Сначала все работает нормально - я возвращаю «дескриптор» обратно клиенту, а затем клиент выполняет последующие вызовы с тем же значением дескриптора. Но после (очень короткого) периода бездействия C API решает, что он потерял свои списки «объектов», и начинает заново.

Я предполагаю, что это связано с тем, что основной файл .so выгружается.

Итак, мой вопрос:

Могу ли я что-нибудь сделать, чтобы предотвратить выгрузку этого .SO из apache / perl? Единственное, что кажется работающим, - это запуск apache в режиме отладки с параметром -X.

Спасибо


perl mod-perl
person didster    schedule 10.11.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я предполагаю, что проблема в том, что SO должен выполнить большую инициализацию для первого запроса, и вы хотите избежать повторения этого.

Это может помочь, если вы измените настройки MPM.

Согласно документации MPM, вы можете избежать остановки и перезапуска дочерних процессов, установив соответствующие директивы.

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

  • установить значение MaxRequestsPerChild на ноль

  • установите значение MaxSpareThreads на то же значение, что и MaxClients

Это означает, что два механизма регулирования времени жизни дочерних процессов отключены. Во-первых, процессы завершаются и автоматически перезапускаются после MaxRequestsPerChild. Установка его в ноль отключает это. Во-вторых, если простаивающих больше, чем MaxSpareThread, дочерние процессы могут быть отброшены для экономии ресурсов сервера. Вторая директива отключает этот процесс.

person Ben    schedule 10.02.2012

arrow_upward

arrow_downward

person    schedule
comment
Спасибо. Я надеялся избежать этой проблемы, используя mpm рабочего потока apache, а не fork, но, похоже, это то же самое? - person didster; 11.11.2011