Nu am făcut nimic prost de ceva timp.
Astăzi, vom efectua teste cu toate posibilele încălcări ale purității lor și vom manipula imprumuta statisticile.
Întrebarea este: cum să conectați corect clasele în proiectul dvs., economisind astfel timp pentru conectarea lor.
- Vechi bun autoload (). ca toți oamenii normali.
- Luați și colectați toate clasele într-un fișier, așa cum mulți învață.
- Pentru a conecta clasele necesare în mod explicit prin requ_once ().
- Și noul lucru: arhiva Phar.
- Phar-arhiva poate fi făcută nu simplu, dar cu compresie (GZ sau BZ2).
- Ei bine și phar ', de asemenea, două variante: autoload () sau conexiunea directă a fișierelor închise.
- Și peste asta este posibil să cumpărați un accelerator.
instrumente
Instrumentele pentru teste sunt aici: pe githaba.
Rularea ./create.php creează un director numit test. dar în ea următoarele lucruri.
Lista de cursuri
Structura clasei noastre testate. Toate în conformitate cu standardul PSR-0.
Există 5 spații de nume cu nume aleatoare. În fiecare, 5 clase aleatoare sunt create cu un set aleatoriu de metode.
Și în fiecare dintre spațiile globale se creează încă 5 nivele și în ele există încă 5 clase.
Total 150 de clase. Standardul este un cadru mijlociu.
Fișierul full.php
Întregul "cadru" dintr-un fișier.
Fișierul are o dimensiune de 85K, iar greutatea totală a directorului (datorită numărului mare de fișiere mici) este 725K (sistem de fișiere ext4).
Mai multe meciuri au fost deja salvate.
Fișierul Exec.php
Acesta este un script executabil care solicită clasele necesare.
Pentru a realiza un fel de asemănare cu scenariile obișnuite: într-un scenariu nu sunt implicate toate clasele cadrului, ci doar 50 (a treia). Dar pentru fiecare clasă pot exista mai multe apeluri.
Lucrul cu fiecare clasă este simplu: se numește o metodă statică, care efectuează cea mai simplă operație aritmetică. Astfel, timpul petrecut în timpul orelor de lucru cu clasele nu ar trebui să depășească cu mult timpul petrecut la conectarea lor (pe care îl testează).
Phar-arhive
Se creează trei clase din directorul de clase: phar-none.phar. Phar-gz.phar. phar-bz.phar (fără compresie, gz, bz).
Dimensiunea phar-node.phar. 99 K. Mai mult decât full.php din cauza informațiilor suplimentare.
Fișiere comprimate: 51 K (gz) și 61 K (bz). Normal, arhiverele compresează și mai bine.
(Aveți nevoie de extensia Phar și setarea phar.readonly în php.ini trebuie resetată)
Fișierele req.php și phar-req.php
În req.php toate fișierele folosite în execu.php sunt conectate (50 bucăți).
În phar-req.php același lucru, numai aceștia nu se conectează din director, ci din far-arhivă.
După crearea directorului de testare, executați testele din consola. /run.php [test].
Argumentul [test] poate fi:
autoload. conectați fișierele din director utilizând autoload.
Autoload este simplu: înlocuiește NS1 \ NS2 \ Class cu DIR / NS1 / NS2 / Class.php. verifică un fișier și îl conectează.
plin. conectarea unui fișier mare.
req. conectarea fișierelor cerute prin requ_once
Phar-auto. conectare de la phar prin autoload.
Phar-req. Conectarea fișierelor necesare din phar prin requ_once.
phar-gz și phar-bz. conectarea prin intermediul unui autoload din arhive comprimate.
Întrucât într-un ciclu pentru a rula astfel de teste este lipsit de sens și, în general, puritatea testelor nu mirosă, pur și simplu sunăm de mai multe ori din consola (rezultatele sunt întotdeauna aceleași oricum).
rezultate
Am primit acest lucru (P. Dual Core 2.8Hz, ubuntu, php 5.5.1):
Psevdoanalitika
Avtoload vs asamblare într-un fișier
Nu numai că ansamblul dintr-un fișier a mâncat de 3 ori mai multă memorie (conectăm toate clasele, când este necesară doar o treime), așa că a pierdut autoloada cu care a fost chemată să lupte.
Testele suplimentare au arătat că, în timp, ansamblul se apropie de autoload atunci când conectează aproximativ 50% din numărul total de clase și apoi începe să o ocolească.
Autoload vs requre
necesită autoload de by-pass așteptat.
Este logic, deoarece cu autoload, există multe mișcări diferite care se termină cu aceleași cerințe.
Cu toate acestea, diferența este de numai 10%.
Și aceasta în ciuda faptului că require_once test pentru fiecare clasă este numit doar o singură dată (într-un proiect real, în cazul în care se verifică dacă deja conectat fișierul înainte de fiecare clasă de a conecta inițial avea nevoie de una și aceeași clasă va cere în mod repetat și require_once de fiecare dată sau nu ).
În plus, fișierele noastre de testare sunt mici. Pe un fișier mare, conexiunea și parsarea acestuia ar lua mult mai mult.
Aceasta este pentru subiectul optimizării căutării în clasă: puteți să eliminați file_exists din fișierul autoload, puteți să scana directoarele și să colectați harta de clasă într-o matrice și să o utilizați, puteți face mult mai mult. Dar toate aceste optimizări vor fi doar în limitele acestor 10%. O cerință simplă explicită pentru a nu depăși viteza.
Phar e destul de periculos.
Puțin mai încet și mai puțin nevoie de memorie.
Dar pe consumul de memorie la o variantă cu o ansamblu într-un fișier pentru ea este departe.
Deși există și un fișier.
Comprimare: gzip a depășit oarecum bz2 și aici (mai sus sa dovedit a fi o dimensiune mai mică a fișierului).
Cu toate acestea, prin compresie, viteza de acces este redusă semnificativ.
Da, și raportul de compresie, așa cum se vede mai sus, într-un fel nu foarte (mai mult, atunci când este comprimat de un arhivator obișnuit rezultatul comprimat este mai mult decât compresia necomprimată).
Deci nu aș recomanda utilizarea farurilor comprimate.
Deși, probabil, operele ar rezolva această situație.
Zend Opcache
Ei bine, este de dorit să testați toate acestea cu toate opacurile, acceleratoarele și altele asemenea.
Dar pentru a le pune toate leneș, așa că am verificat doar pe opcache.
Atunci când rulați testele din consola, nu uitați să includeți opțiunea opcache.enable_cli în php.ini.
Includerea opacahce a dus la o scădere dublă a consumului de memorie.
Despre viteza numerelor exacte, nu, deoarece rezultatele au început să fluctueze puternic, iar metodele noastre nu ne permit să le mediamăm pe un număr mare de teste.
Cu toate acestea, rezultatele variază aproximativ în aceleași proporții. Maxim: corespunde timpului fără opacahce, minim: de două până la trei ori mai mic.
Atunci când este sunat de la consola poate depăși uneori în mod semnificativ apelurile de timp prin browser.
1. Nu este nimic de abur din cauza prostiilor. Optimizarea este încă nesemnificativă în comparație cu timpul obișnuit de execuție a scenariului.
2. autoload () este soluția cea mai bună și cea mai convenabilă. În plus, toate standardele tipului PSR sunt acum legate de acesta.
3. Asamblați mai multe fișiere într-una, construiți hărți de clasă etc. Este posibil numai la fabricație la deplе.
Atunci când tot mai mult esențial este deja optimizat.
Când se dezvoltă același lucru: hemoroizii sunt mulți, dar nu este foarte util.
4. Asamblarea mai multor fișiere într-una produce rezultatul numai dacă cel puțin jumătate din fișierele atașate sunt utilizate de fiecare dată.
5. phar - good (pentru bibliotecile furnizate, care nu trebuie schimbate).
6. Phar comprimat - nu atât de bun.
7. Opcahce este destul de un taxi.
Negarea obligațiilor
Trimiteți-le prietenilor: