Mod_perl - това С Apache модул, който изпълнява Perl интерпретатора + набор от Perl модули, които осигуряват следните интересни характеристики: 1. кеширане събраните CGI скриптове (Apache :: Registry.pm) 2. Perl интерфейс за разработчиците на C API Apache Повечето използват mod_perl да се увеличи производителността на техния скриптове - Apache не започне нов процес за всяка заявка за script.pl, тъй като вече има своя Perl преводач, и събират script.pl с всяка заявка, тъй като магазини Apache :: Registry.pm компилирания скриптовете си в кеш паметта. Perl интерфейс към C API Apache се използва от разработчиците не толкова често.
Как изглежда - типично използване mod_perl.
Съставили сме Apache с поддръжка mod_perl, ние имаме script.pl:
и ние искаме сценария изпълнен от mod_perl на преводач и кеширана. За да направите това, ние променяме httpd.conf:
Рестартирайте Apache и се уверете, че всичко работи.
Конфигуриране mod_perl.
Ние ще разберем, че сме написали в httpd.conf.
Mod_perl определя Apache манипулатор име "Perl скрипт". Следващ пост: означава, че искания към / CGI-бен ще се справят mod_perl код.
Mod_perl също така определя няколко директиви: - Директива за товар определен Perl модули. Скриптове, които се изпълняват под mod_perl, могат да ги използват, без да се включва функцията за ползване (). От гледна точка на скриптове, използвайте PerlModule различава от използването () факта, че имената на скрипт модул не са внесени. Модули заредени PerlModule, тя може да се използва и като свързано с манипулатор работа фаза см. По-долу. - Apache обработва заявката на няколко етапа - (Post-Read-Искане, URI Превод, Header разбор, Контрол на достъпа, Authentication, разрешаването, MIME тип проверка, FixUp, Response (), Дърводобив, почистване!). Perl * Хендлър директива моля да стане клиент модул манипулатор за всяка от тези фази. Директивата най-често се използва за създаване на PerlHandler манипулатор за реагиране фаза. Останалата част от директивата за Perl * Хендлър (PerlPostReadRequestHandler, PerlTransHandler, PerlHeaderParserHandler, PerlAccessHandler, PerlAuthenHandler, ...) се използват по-рядко.
В нашия httpd.conf посочихме Apache :: Registry.pm като манипулатор фаза отговор. Когато питаме script.pl сървъра, Apache :: Registry.pm заема компилиран вариант на сценария от кеша си и писти. Apache :: Registry.pm script.pl проследява промените на диска и да го възстанови, ако е необходимо. Въпреки това, промените в модулите включени script.pl не проследяват - това е дълъг. Така че, ако сте променили някой от модулите, след което рестартирайте сървъра.
Характеристики на сценария под Apache :: Registry
Двете основни характеристики на кеширани скриптове, които могат да развалят много нерви разработчик, ако той не знае за тях:
1. глобални скрипт променливи запазват стойностите си между заявките: исканията на скрипт няколко пъти и получаваме: 1 2 3 4 5 ...
без Apache :: Registry картина ще бъде това, разбира се: 1 1 1 1 1 ...
Не се изненадвайте, ако чрез отваряне на нов прозорец на IE и процесът се повтаря отново, вие ще получите: 1 2 3 4 5 ... вместо 6 7 8 9 10 .... Обикновено на сървър с множествена дете обработва уеб-, всеки от тях има своя собствена копие на вашия сценарий и по този начин им копие от $ аз.
HTTPD -x команда стартира сървъра с едно дете процес - полезна за отстраняване на грешки.
Следното е пример за това как не трябва да се напише: само един потребител посочили правилния вход-парола, както и всички останали, може да отиде :).
2. Някои от скрипта ви функции са вградени във външната функция. Това е, което прави Apache :: Registry script1.pl на: нашата show_var () се определя в рамките на манипулатор (). т.е. Прикачените файлове. Какво губим? show_var () вече не може да работи правилно с външния ми () променливи, в този случай с моя $ Var. Изпълнете скрипта няколко пъти, които получаваме: Var беше и сега е б. Var е б и в момента е в. Var е в и сега е г и т.н.
show_var функция () "вижда" копието на моя $ Var. който е "видял" в първия манипулатор изпълнение ().
Подробности проблема, описан тук: с обхват на променливата в NestedSubroutines. Ние също се интересуват от неговите възможни решения:
1. определяне на функцията не е в сценария, както и в модула. кода на модула не obarachivaetsya във всяка функция, както и този проблем няма да възникне.
2. или просто не obraschatsya на функциите на външния ми () променливи.
Да предположим, че сте сменили вашите скриптове mod_perl, те не работят правилно от кеша поради описаните по-горе проблеми, а вие сте прекалено мързеливи, за да ги адаптира. Използвайте Apache :: PerlRun вместо Apache :: вписванията. Скриптове не се кешират, но все пак ще се изпълняват вграден Perl преводач.
продуктивност
На моите 300Celeron резултати са както следва: 774, 1039, 768 милисекунди, съответно. Т.е. под mod_perl Script екзекутиран през 6ms (774-768), без да се mod_perl - за 71ms (1039-768). В 12 пъти се увеличиха prozvoditelnost, все пак! За недвижими сценарий, тази цифра ще бъде по-малко, разбира се.
Това е време, за да го наричат на ден
Свързани статии