Mod_perl - l cu modul Apache, care implementează interpretul Perl + set de module Perl care oferă următoarele caracteristici interesante: 1. punerea în cache script cgi compilate (Apache :: Registry.pm) 2. interfață Perl pentru dezvoltatorii C API Apache Majoritatea folosesc mod_perl pentru a crește performanța lor script-uri - Apache nu începe un nou proces cu fiecare cerere de script.pl, deoarece are acum interpretul său Perl și nu compilează script.pl cu fiecare cerere, deoarece Apache :: Registry.pm stochează scripturile dvs. compilate în memoria cache. Interfața Perl cu Apache C API este folosită de dezvoltatori nu atât de des.
Ce pare a fi folosirea tipică a mod_perl.
Am compilat Apache cu suport pentru mod_perl, avem script.pl:
și vrem ca scriptul să fie executat de interpretorul mod_perl și să fie stocat în cache. Pentru aceasta, schimbăm httpd.conf:
Reporniți Apache și asigurați-vă că totul funcționează.
Configurarea mod_perl.
Vom afla ce am scris în httpd.conf.
Mod_perl definește un handler Apache numit "perl-script". Intrarea următoare: înseamnă că cererile pentru / cgi-bin se vor ocupa de codul mod_perl.
Mod_perl definește, de asemenea, mai multe directive: - directiva încarcă modulele Perl specificate. Scripturile executate sub mod_perl pot să le utilizeze, fără a include funcția use (). Din punct de vedere al scenariului, utilizarea PerlModule diferă de utilizarea () prin faptul că numele de module nu sunt importate în scenariu. Un modul încărcat de PerlModule poate fi, de asemenea, utilizat ca manipulator pentru orice fază a procesării cererii, a se vedea mai jos. - Apache procesează cererea în mai multe etape - (post-Read-Cerere, URI de traducere, Antet Parsing, Access Control, autentificare, autorizare, verificare tip MIME, FixUp, Response (), Logging, Cleanup!). Directiva Perl * Handler înregistrează modulul handler pentru oricare dintre aceste faze. Cea mai frecvent folosită este directiva PerlHandler, care stabilește modulul handler pentru faza de răspuns. Restul directivei Perl * Handler (PerlPostReadRequestHandler, PerlTransHandler, PerlHeaderParserHandler, PerlAccessHandler, PerlAuthenHandler, ...) sunt utilizate mai puțin frecvent.
În httpd.conf, am specificat Apache :: Registry.pm ca manipulator pentru faza de răspuns. Când întrebăm script.pl server, Apache :: Registry.pm ia versiunea compilată a script-ul din memoria cache și rulează sale. Apache :: Registry.pm urmărește modificările la script.pl pe disc și, dacă este necesar, o recompilează. Cu toate acestea, modificările din modulele incluse în script.pl nu sunt urmărite - este o perioadă lungă de timp. Deci, dacă ați schimbat oricare dintre modulele dvs., reporniți serverul.
Caracteristicile scripturilor din Apache :: Registrul
Două caracteristici principale ale scripturilor stocate în cache funcționează, capabile să strică o mulțime de nervi pentru dezvoltator, dacă nu știe despre ele:
1. Variabilele globale de script stochează valorile lor între cereri: întrebați acest script de mai multe ori la rând și obțineți: 1 2 3 4 5 ...
fără Apache :: Registrul de imagini ar fi astfel, desigur: 1 1 1 1 1 ...
Nu fi surprins dacă deschideți o nouă fereastră IE și repetați procedura pe care o veți primi: 1 2 3 4 5 ... în loc de 6 7 8 9 10 .... În mod obișnuit, există mai multe procese copil care rulează httpd pe server, fiecare dintre ele având o copie proprie a scriptului dvs. și, în consecință, copia lui de $ i.
Comanda httpd -x va porni un server cu un proces copil - convenabil pentru depanare.
Mai jos este un exemplu despre cum să scrieți NOT: un utilizator trebuie să specifice parola de conectare corectă și toate celelalte vor putea să se conecteze la fel :).
2. Funcțiile definite în scriptul dvs. devin imbricate în funcția externă. Asta este ceea ce Apache :: Registrul se transformă script1.pl: show_var () a fost definit în interiorul handlerului (). și anume Atașamente. De ce ne amenință? show_var () nu poate funcționa corect cu variabilele externe my (), în cazul nostru cu $ var. Rulează scenariul de câteva ori, obținem: Var a fost a și acum este b. Var a fost b și acum este c. Var a fost c și acum este d etc.
Funcția show_var () "vede" acea instanță a lui $ var. pe care a văzut-o "prima dată când a alergat pe mâner ().
Această problemă este descrisă în detaliu aici: Variabilă scop în NestedSubroutines. Suntem de asemenea interesați de soluțiile posibile:
1. Definirea funcțiilor nu în scenariu, ci în modul. Codul modulelor dvs. nu este înfășurat în nici o funcție și această problemă nu apare.
2. Sau pur și simplu nu întoarce funcțiile la variabilele externe my ().
Să presupunem că ați înlocuit scripturile la mod_perl, acestea nu funcționează corect din cache-ul din cauza problemelor descrise mai sus, și ești prea leneș pentru a le adapta. Utilizați Apache :: PerlRun în loc de Apache :: Registrul. Scripturile nu vor fi stocate în memoria cache, dar vor fi executate în continuare de către interpretul Perl încorporat.
productivitate
Pe 300Celeron rezultatele mele sunt următoarele: 774, 1039, 768 milisecunde. Ie sub scriptul mod_perl rulat pentru 6ms (774-768), fără mod_perl - pentru 71ms (1039-768). Totuși, în 12 ori mai mare de transfer! Pentru scripturi reale, acest număr va fi mai mic, bineînțeles.
E timpul să închidem
Articole similare
Trimiteți-le prietenilor: