Një nga kriteret kryesore për suksesin e çdo burimi të internetit është shpejtësia e funksionimit të tij dhe çdo vit përdoruesit po bëhen gjithnjë e më kërkues për sa i përket këtij kriteri. Optimizimi i funksionimit të skripteve PHP është një nga metodat për të siguruar shpejtësinë e sistemit.

Në këtë artikull, unë do të doja të paraqes para publikut koleksionin tim të këshillave dhe fakteve mbi optimizimin e skenarit. Përmbledhja më mori mjaft kohë për t'u përpiluar dhe bazohet në disa burime dhe eksperimente personale.

Pse një koleksion këshillash dhe faktesh, në vend të rregullave strikte? Sepse, siç e kam parë, nuk ka "optimizimi absolutisht i saktë". Shumë teknika dhe rregulla janë kontradiktore dhe është e pamundur t'i zbatosh të gjitha. Ju duhet të zgjidhni një grup metodash që janë të pranueshme për t'u përdorur pa kompromentuar sigurinë dhe komoditetin. Unë kam marrë një pozicion rekomandues dhe për këtë arsye kam këshilla dhe fakte që mund t'i ndiqni ose jo.

Për të shmangur konfuzionin, i ndava të gjitha këshillat dhe faktet në 3 grupe:

• Optimizimi në nivelin e logjikës dhe organizimit të aplikimit
• Optimizimi i kodit
• Optimizimi i padobishëm

Grupet janë caktuar me kusht dhe disa artikuj mund t'u atribuohen disa prej tyre menjëherë. Numrat janë për një server mesatar (LAMP). Artikulli nuk diskuton çështje që lidhen me efektivitetin e teknologjive dhe kornizave të ndryshme të palëve të treta, pasi kjo është një temë për diskutime të veçanta.

Optimizimi në nivelin e logjikës dhe organizimit të aplikimit

Shumë nga këshillat dhe faktet që lidhen me këtë grup optimizimi janë shumë domethënëse dhe ofrojnë një fitim shumë të madh në kohë.

• Profilizoni vazhdimisht kodin tuaj në server (xdebug) dhe klient (firebug) për të identifikuar pengesat e kodit
  Duhet të theksohet se të dy pjesët e serverit dhe të klientit duhet të profilizohen, pasi jo të gjitha gabimet e serverit mund të zbulohen në vetë serverin.
• Numri i funksioneve të përdoruesit të përdorura në program nuk ndikon në shpejtësinë në asnjë mënyrë
  Kjo i lejon programit të përdorë funksione të panumërta të personalizuara.
• Përdorni në mënyrë aktive veçoritë e personalizuara
  Efekti pozitiv arrihet për faktin se operacionet brenda funksioneve kryhen vetëm me variabla lokale. Efekti i kësaj është më i madh se kostoja e thirrjeve të funksioneve me porosi.
• Është e këshillueshme që të zbatohen funksione "kritikisht të rënda" në një gjuhë programimi të palëve të treta në formën e një zgjerimi PHP
  Kjo kërkon aftësi programimi në një gjuhë të palës së tretë, e cila rrit ndjeshëm kohën e zhvillimit, por në të njëjtën kohë lejon përdorimin e teknikave përtej aftësive të PHP.
• Përpunimi i një skedari statik html është më i shpejtë se një skedar i interpretuar php
  Diferenca në kohë në klient mund të jetë rreth 1 sekondë, kështu që ka kuptim që të ndahen qartë faqet statike nga faqet e krijuara nga mjetet PHP.
• Madhësia e skedarit të përpunuar (të lidhur) ndikon në shpejtësinë
  Përafërsisht 0,001 sekonda shpenzohen për përpunim çdo 2 KB. Ky fakt na shtyn të minimizojmë kodin e skriptit kur e transferojmë atë në serverin e prodhimit.
• Përpiquni të mos përdorni "require_once" ose "include_once" gjatë gjithë kohës
  Këto funksione duhet të përdoren kur është e mundur të lexohet përsëri skedari në raste të tjera, është e këshillueshme që të përdoren dhe përfshijnë .
• Kur degëzoni një algoritëm, nëse ka ndërtime që mund të mos përpunohen dhe vëllimi i tyre është rreth 4 KB ose më shumë, atëherë është më optimale t'i përfshini ato duke përdorur përfshirjen.
• Këshillohet që të përdorni verifikimin e të dhënave të dërguara te klienti
  Kjo për faktin se kur kontrolloni të dhënat në anën e klientit, numri i kërkesave me të dhëna të pasakta zvogëlohet ndjeshëm. Sistemet e vlefshmërisë së të dhënave nga ana e klientit janë ndërtuar kryesisht duke përdorur JS dhe elementë të formës së ngurtë (përzgjedh).
• Është e këshillueshme që të ndërtohen struktura të mëdha DOM për grupe të dhënash në klient
  Kjo është një metodë shumë efektive optimizimi kur punoni me sasi të mëdha të të dhënave të shfaqura. Thelbi i tij zbret në sa vijon: një grup të dhënash përgatitet në server dhe transferohet te klienti, dhe ndërtimi i strukturave DOM u ofrohet funksioneve JS. Si rezultat, ngarkesa rishpërndahet pjesërisht nga serveri te klienti.
• Sistemet e ndërtuara në teknologjinë AJAX janë dukshëm më të shpejta se sistemet që nuk e përdorin këtë teknologji
  Kjo është shkaktuar nga një rënie në vëllimet e prodhimit dhe rishpërndarja e ngarkesës në klient. Në praktikë, shpejtësia e sistemeve me AJAX është 2-3 herë më e lartë. Koment: AJAX, nga ana tjetër, krijon një numër kufizimesh në përdorimin e metodave të tjera të optimizimit, për shembull, duke punuar me një tampon.
• Kur merrni një kërkesë postimi, ktheni gjithmonë diçka, ndoshta edhe një hapësirë
  Përndryshe, klientit do t'i dërgohet një faqe gabimi që peshon disa kilobajt. Ky gabim është shumë i zakonshëm në sistemet që përdorin teknologjinë AJAX.
• Marrja e të dhënave nga një skedar është më e shpejtë sesa nga një bazë të dhënash
  Kjo është kryesisht për shkak të kostos së lidhjes me bazën e të dhënave. Për habinë time, një përqindje e madhe e programuesve ruan në mënyrë maniake të gjitha të dhënat në bazën e të dhënave, edhe kur përdorimi i skedarëve është më i shpejtë dhe më i përshtatshëm. Koment: Ju mund të ruani të dhëna në skedarë që nuk kërkohen, përndryshe duhet të përdorni një bazë të dhënash.
• Mos u lidhni me bazën e të dhënave nëse nuk është e nevojshme
  Për një arsye të panjohur për mua, shumë programues lidhen me bazën e të dhënave në fazën e leximit të cilësimeve, megjithëse mund të mos bëjnë pyetje në bazën e të dhënave më vonë. Ky është një zakon i keq që kushton mesatarisht 0.002 sekonda.
• Përdorni një lidhje të vazhdueshme me bazën e të dhënave kur ka një numër të vogël klientësh aktivë në të njëjtën kohë
  Përfitimi kohor është për shkak të mungesës së kostove për lidhjen me bazën e të dhënave. Diferenca kohore është afërsisht 0,002 sekonda. Koment: Nëse ka një numër të madh përdoruesish, nuk këshillohet përdorimi i lidhjeve të vazhdueshme. Kur punoni me lidhje të vazhdueshme, duhet të ketë një mekanizëm për përfundimin e lidhjeve.
• Përdorimi i pyetjeve komplekse të bazës së të dhënave është më i shpejtë sesa përdorimi i disa pyetjeve të thjeshta
  Diferenca kohore varet nga shumë faktorë (vëllimi i të dhënave, cilësimet e bazës së të dhënave, etj.) dhe matet në të mijtët, e ndonjëherë edhe në të qindtat e sekondës.
• Përdorimi i llogaritjeve në anën DBMS është më i shpejtë se llogaritjet në anën PHP për të dhënat e ruajtura në bazën e të dhënave
  Kjo për faktin se llogaritjet e tilla në anën PHP kërkojnë dy pyetje në bazën e të dhënave (marrja dhe ndryshimi i të dhënave). Diferenca kohore varet nga shumë faktorë (vëllimi i të dhënave, cilësimet e bazës së të dhënave, etj.) dhe matet në të mijtët dhe të qindtat e sekondës.
• Nëse të dhënat e mostrës nga baza e të dhënave ndryshojnë rrallë dhe shumë përdorues i qasen këtyre të dhënave, atëherë ka kuptim të ruani të dhënat e mostrës në një skedar
  Për shembull, mund të përdorni qasjen e mëposhtme të thjeshtë: ne marrim të dhëna të mostrës nga baza e të dhënave dhe i ruajmë ato si një grup i serializuar në një skedar, pastaj çdo përdorues përdor të dhënat nga skedari. Në praktikë, kjo metodë optimizimi mund të sigurojë një rritje të shumëfishtë në shpejtësinë e ekzekutimit të skriptit. Koment: Kur përdorni këtë metodë, ju duhet të shkruani mjete për të gjeneruar dhe ndryshuar të dhënat e ruajtura në skedar.
• Të dhënat e memories që ndryshojnë rrallë me memcached
  Fitimi i kohës mund të jetë mjaft i rëndësishëm. Koment: Caching është efektiv për të dhënat statike, efekti është i reduktuar dhe mund të jetë negativ.
• Puna pa objekte (pa OOP) është rreth tre herë më shpejt se puna me objekte
  Gjithashtu konsumohet më shumë memorie. Fatkeqësisht, përkthyesi PHP nuk mund të punojë me OOP aq shpejt sa me funksionet e rregullta.
• Sa më i madh të jetë dimensioni i grupit, aq më ngadalë funksionojnë
  Humbja e kohës ndodh për shkak të trajtimit të strukturave të mbivendosura.

Optimizimi i kodit

Këto këshilla dhe fakte japin një rritje të parëndësishme të shpejtësisë në krahasim me grupin e mëparshëm, por të marra së bashku këto teknika mund të japin një fitim të mirë të kohës.

• jehona dhe printimi janë dukshëm më të shpejtë se printf
  Diferenca kohore mund të arrijë disa të mijëtat e sekondës. Kjo është për shkak se printf përdoret për të nxjerrë të dhëna të formatuara dhe interpretuesi kontrollon të gjithë linjën për të dhëna të tilla. printf përdoret vetëm për të nxjerrë të dhëna që kanë nevojë për formatim.
• echo $var."text" është më e shpejtë se echo "$var text"
  Kjo ndodh sepse motori PHP në rastin e dytë detyrohet të kërkojë variabla brenda vargut. Për sasi të mëdha të dhënash dhe versione më të vjetra të PHP-së, dallimet kohore janë të dukshme.
• echo "a" është më e shpejtë se jehona "a" për vargjet pa variabla
  Kjo ndodh sepse në rastin e dytë motori PHP po përpiqet të gjejë variabla. Për vëllime të mëdha të dhënash, dallimet në kohë janë mjaft të dukshme.
• jehona "a", "b" është më e shpejtë se jehona "a"."b"
  Dalja e të dhënave të ndara me presje është më e shpejtë se me pikë. Kjo ndodh sepse në rastin e dytë ndodh lidhja e vargut. Për vëllime të mëdha të dhënash, dallimet në kohë janë mjaft të dukshme. Shënim: kjo funksionon vetëm me funksionin echo, i cili mund të marrë disa rreshta si argumente.
• $return="a"; $return.="b"; jehonë $kthim; më shpejt se jehona "a"; jehona "b";
  Arsyeja është se nxjerrja e të dhënave kërkon disa operacione shtesë. Për vëllime të mëdha të dhënash, dallimet në kohë janë mjaft të dukshme.
• ob_start(); jehonë "a"; jehona "b"; ob_end_flush(); më shpejt se $return="a"; $return.="b"; jehonë $kthim;
  Kjo është për shkak se e gjithë puna kryhet pa qasje në variabla. Për vëllime të mëdha të dhënash, dallimet në kohë janë mjaft të dukshme. Koment: Kjo teknikë është e paefektshme nëse jeni duke punuar me AJAX, pasi në këtë rast është e dëshirueshme të ktheheni të dhënat si një varg i vetëm.
• Përdorni "insert profesional" ose?> a b
  Të dhënat statike (kodi i jashtëm) përpunohen më shpejt se dalja e PHP. Kjo teknikë quhet futje profesionale. Për vëllime të mëdha të dhënash, dallimet në kohë janë mjaft të dukshme.
• readfile është më i shpejtë se file_get_contents, file_get_contents është më i shpejtë se sa kërkohet dhe kërkesa është më i shpejtë se përfshirja për nxjerrjen e përmbajtjes statike nga një skedar i vetëm
  Koha që duhet për të lexuar një skedar bosh varion nga 0.001 për readfile deri në 0.002 për përfshirjen.
• kërkesa është më e shpejtë se përfshirja për skedarët e interpretuar
  Koment: kur degëzoni një algoritëm, kur është e mundur të mos përdorni një skedar të interpretuar, duhet të përdorni përfshirjen, sepse kërkoj gjithmonë përfshin skedarin.
• nëse (...) (...) tjetër nëse (...) () është më i shpejtë se kaloni
  Koha varet nga numri i degëve.
• nëse (...) (...) tjetër nëse (...) () është më i shpejtë se nëse (...) (...); nëse (...) ();
  Koha varet nga numri i degëve dhe kushteve. Ju duhet të përdorni tjetër nëse është e mundur, pasi është konstrukti më i shpejtë "i kushtëzuar".
• Kushtet më të zakonshme të konstruksionit nëse (...) (...) else if (...) () duhet të vendosen në fillim të degës
  Përkthyesi skanon konstruksionin nga lart poshtë derisa të gjejë kushtin të përmbushur. Nëse përkthyesi konstaton se kushti është i plotësuar, atëherë ai nuk shikon pjesën tjetër të konstruksionit.
• < x; ++$i) {...} быстрее, чем for($i = 0; $i < sizeOf($array); ++$i) {...}
  Kjo ndodh sepse në rastin e dytë operacioni sizeOf do të ekzekutohet në çdo përsëritje. Diferenca e kohës së ekzekutimit varet nga numri i elementeve të grupit.
• x = madhësiaOf ($array); për ($i = 0; $i< x; ++$i) {...} быстрее, чем foreach($arr as $value) {...} для не ассоциативных массивов
  Diferenca kohore është e rëndësishme dhe rritet me rritjen e grupit.
• preg_replace është më i shpejtë se ereg_replace, str_replace është më i shpejtë se preg_replace, por strtr është më i shpejtë se str_replace
  Diferenca kohore varet nga sasia e të dhënave dhe mund të arrijë disa të mijëtat e sekondës.
• Funksionet e vargut janë më të shpejtë se shprehjet e rregullta
  Ky rregull është pasojë e rregullit të mëparshëm.
• Hiqni variablat e grupit që nuk nevojiten më për të liruar memorien.
• Shmangni përdorimin e shtypjes së gabimeve @
  Shuarja e gabimeve prodhon një numër operacionesh shumë të ngadalta dhe meqenëse shkalla e riprovës mund të jetë shumë e lartë, humbja e shpejtësisë mund të jetë e konsiderueshme.
• nëse (isset($str(5))) (...) është më i shpejtë se nëse (strlen($str)>4)(...)
  Kjo është për shkak se operacioni standard i testit isset përdoret në vend të funksionit strlen për manipulimin e vargjeve.
• 0.5 është më i shpejtë se 1/2
  Arsyeja është se në rastin e dytë kryhet një operacion ndarjeje.
• kthimi është më i shpejtë se ai global kur kthen vlerën e një ndryshoreje nga një funksion
  Kjo sepse në rastin e dytë krijohet një variabël global.
• $row["id"] është më i shpejtë se $row
  Opsioni i parë është 7 herë më i shpejtë.
• $_SERVER['REQUEST_TIME'] është më i shpejtë se koha() për të përcaktuar se kur duhet të ekzekutohet një skript
  
• nëse ($var===null) (...) është më i shpejtë se nëse (is_null($var)) (...)
  Arsyeja është se në rastin e parë nuk ka përdorim të funksionit.
• ++i është më i shpejtë se i++, --i është më i shpejtë se i--
  Kjo është shkaktuar nga veçoritë e bërthamës PHP. Diferenca kohore është më e vogël se 0.000001, por nëse i përsëritni këto procedura mijëra herë, atëherë shikoni më nga afër këtë optimizim.
• Rritja e variablit të inicializuar i=0; ++i; më shpejt se i painitializuar ++i
  Diferenca kohore është rreth 0.000001 sekonda, por për shkak të frekuencës së mundshme të përsëritjes, ky fakt duhet mbajtur mend.
• Përdorimi i variablave në pension është më i shpejtë se deklarimi i variablave të rinj
  Ose më lejoni ta riformuloj ndryshe: Mos krijoni ndryshore të panevojshme.
• Puna me variabla lokale është afërsisht 2 herë më e shpejtë se me ato globale
  Edhe pse diferenca kohore është më pak se 0.000001 sekonda, për shkak të shkallës së lartë të përsëritjes, duhet të përpiqeni të punoni me variabla lokale.
• Qasja drejtpërsëdrejti në një variabël është më e shpejtë se thirrja e një funksioni brenda të cilit kjo ndryshore është përcaktuar disa herë
  Thirrja e një funksioni kërkon rreth tre herë më shumë kohë sesa thirrja e një ndryshoreje.

Optimizimi i padobishëm

Një numër metodash optimizimi në praktikë nuk kanë një ndikim të madh në shpejtësinë e ekzekutimit të skriptit (fitimi i kohës është më pak se 0.000001 sekonda). Përkundër kësaj, një optimizim i tillë është shpesh objekt polemikash. Unë i paraqita këto fakte "të padobishme" në mënyrë që të mos u kushtoni vëmendje të veçantë kur shkruani kodin në të ardhmen.

• jehona është më e shpejtë se printimi
• include ("rruga absolute") është më e shpejtë se përfshi ("rruga relative")
• sizeOf është më i shpejtë se numërimi
• foreach ($arr as $key => $value) (...) është më i shpejtë se rivendosja ($arr); ndërsa (lista ($key, $value) = secili ($arr)) (...) për vargje shoqëruese
• Kodi i pakomentuar është më i shpejtë se kodi i komentuar sepse kërkon kohë shtesë për të lexuar skedarin
  Është shumë marrëzi të zvogëlosh vëllimin e komenteve për hir të optimizmit, thjesht duhet të kryesh minimizimin në skriptet e punës ("luftarake").
• Variablat me emra të shkurtër janë më të shpejtë se variablat me emra të gjatë
  Kjo është shkaktuar nga një reduktim në sasinë e kodit që përpunohet. Ngjashëm me pikën e mëparshme, thjesht duhet të kryeni minimizimin në skriptet e punës ("luftarake").
• Shënimi i kodit duke përdorur skedat është më i shpejtë se përdorimi i hapësirave
  Ngjashëm me pikën e mëparshme.

Së fundi, dua t'ju kujtoj edhe një herë se këshillat dhe faktet që kam dhënë nuk janë absolute dhe rëndësia e zbatimit të tyre varet nga situata specifike. Duhet mbajtur mend se optimizimi i skriptit është vetëm një pjesë e vogël e të gjithë procedurës së optimizimit dhe shpesh është e mundur të jetosh në heshtje pa këshillat e mësipërme.

Nëse keni ndonjë pyetje, ju rekomandojmë të përdorni tonën

Nga autori:Çdo zhvillues që respekton veten shqetësohet për "fatin" e kodit të tij. Përpiqet ta bëjë aplikacionin sa më të përshtatshëm, më të shpejtë dhe të rrisë tolerancën e tij ndaj gabimeve. Por optimizimi i PHP nuk do t'ju lejojë gjithmonë të arrini këto lartësi.

Mos e shëro krahun nëse këmba është çalë!

Na vjen keq për aforizmin popullor irlandez! Por ajo pasqyron në mënyrë të përkryer thelbin e problemit. Më shpesh, optimizimi i kodit nuk do t'ju lejojë të përmirësoni performancën e skriptit ose burimit të krijuar. Dhe në rastin e , gjithçka bëhet jashtëzakonisht e ndërlikuar për shkak të një numri të madh faktorësh që ju (si zhvillues) thjesht nuk mund të ndikoni.

Përsa i përket fenomeneve jashtë kontrollit tonë, nënkuptoj shpejtësinë e lidhjes me internetin, ngarkesën e serverit, cilësimet e OS në makinën e klientit dhe fuqinë e harduerit të kompjuterit të përdoruesit. Nuk do të mund të ndikoni në të gjithë këta komponentë. Dhe në fund rezulton se optimizimi i kodit PHP nuk do të japë një rezultat të plotë.

Ajo që mbetet nën kontrollin e një zhvilluesi të uebit:

Cilësimet e serverit janë të kufizuara. Vendosja e parametrave përmes skedarit të konfigurimit Apache httpd.conf ju lejon të caktoni numrin e proceseve të fëmijëve, kohën e përfundimit të lidhjes së prizës, madhësinë e tamponit të daljes për lidhjet TCP/IP, kohën e papunësisë dhe të tjera.

Cilësimet bazë të gjuhës - përmes parametrave të specifikuar në skedarin php.ini. Ju lejon të vendosni vlerat e buferimit, të ndryshoni kohën maksimale të ekzekutimit të skriptit, trajtimin e gabimeve, menaxhimin e regjistrave dhe cilësime të tjera.

Përdorimi i optimizimit të imazhit PHP - më shumë për këtë më vonë. Optimizimi i kodit të programit - ju lejon të "ruani" burimet dhe të rrisni performancën.

Për shembull, duhet të dini se jehona është më e shpejtë se printimi. Është më mirë të fikni mesazhet e gabimit pas korrigjimit për të kursyer burime. Në vend të lidhjes së vargut, përdorni echo. Objektet dhe metodat e klasës () hanë shumë memorie.

Puna me imazhe

Unë nuk jam një adhurues i përpunimit të imazhit nga serveri. Kjo çon gjithashtu në një humbje të burimeve të çmuara, pritja e të cilave është gjithmonë në mungesë. Rezulton se duke kursyer për një gjë, ne harxhojmë "rezerva" të tjera.

Një opsion më optimal është ngarkimi i imazheve në një shërbim të palës së tretë, nga ku ato ngarkohen në një formë të optimizuar në shfletuesin e përdoruesit në një adresë të caktuar. Ka shumë shërbime të tilla në internet. Unë dua të përmend vetëm disa prej tyre: kraken.io, TinyPNG

Siç mund ta shihni, njohuritë e optimizimit të motorëve të kërkimit në PHP janë gjithashtu të rëndësishme për zhvilluesit profesionistë.

Përveç kësaj, ajo ka mjetet e veta të integruara për "ndriçimin" e imazheve. Për shembull, funksioni imagecopyresampled(). Zvogëlon peshën e përmbajtjes duke rimodeluar dhe ndryshuar madhësinë e imazhit. Shembull përdorimi:

Çfarë tjetër mund të bëni?

Gjithashtu mos harroni të aplikoni optimizimin e klientit duke përdorur PHP. Në një farë mase, serveri mund të ndikojë në shfletuesin e klientit përmes Cache-Control, si dhe atributet e këtij titulli: post-check, max-age dhe të tjerët.

Për më tepër, titujt e modifikimit të fundit dhe ETag ju lejojnë të menaxhoni gjendjen e cache në makinën e klientit. Ata vendosin një ID unike për të modifikuar çdo skedar. Falë kësaj, serveri nuk ridërgon burime, por përgjigjet vetëm me një status 304.

Në artikull nuk e ngritëm çështjen e optimizimit duke përdorur PHP FPM. Por për ta konsideruar atë do të kërkojë një artikull të veçantë. Kaq për sot. Deri herën tjetër!

Ditë të mbarë për të gjithë.

1. Nëse një metodë mund të jetë statike, deklarojeni atë statike.
2. jehona është më e shpejtë se printimi.
3. Kaloni disa parametra në jehonë në vend që të përdorni lidhjen e vargjeve.
4. Cakto numrin maksimal të herëve që unazat tuaja for mund të kalojnë përpara ciklit, jo gjatë ekzekutimit.
5. Fshini variablat tuaj për të liruar memorien, veçanërisht nëse ato janë vargje të mëdha.
6. Kujdes nga metodat magjike si __set, __get, __autoload.
7. Kërkoj një herë vjen me një kosto.
8. Specifikoni shtigjet e plota në konstruktet e përfshirjes/kërkimit, më pak kohë do të shpenzohet për të kërkuar skedarin.
9. Nëse keni nevojë të përcaktoni kohën e ekzekutimit të skriptit, përdorni $_SERVER['REQUEST_TIME'] në vend të kohës ().
10. Mundohuni të përdorni strncasecmp, strpbrk dhe stripos në vend të shprehjeve të rregullta.
11. str_replace është më i shpejtë se preg_replace, por strtr është më i shpejtë se str_replace.
12. Nëse funksioni, si funksionet e zëvendësimit të vargut, mund të marrë si argumente si vargje ashtu edhe karaktere të vetme, dhe nëse lista juaj e argumenteve nuk është shumë e gjatë, merrni parasysh të shkruani shprehje të shumta identike zëvendësuese, duke kaluar nëpër një karakter në një kohë, në vend të një kodi të vargut. merr një grup si argument kërkimi dhe zëvendësimi
13. Është më mirë të zgjidhen deklaratat duke përdorur deklaratat else if në vend që të përdoren deklarata të shumta if.
14. Shuarja e gabimeve kur përdorni @ është shumë e ngadaltë.
15. Përdorni modulin Apache mod_deflate.
16. Mbyllni lidhjet tuaja të bazës së të dhënave kur të keni mbaruar së punuari me to.
17. $row["id"] është shtatë herë më i shpejtë se $row.
18. Mesazhet e gabimit janë të shtrenjta
19. Mos përdorni funksione brenda një kushti të ciklit for, si kjo: për ($x=0; $x< count($array); $x). В данном случае функция count() будет вызываться с каждым проходом цикла.
20. Rritja e një ndryshoreje lokale në një metodë është më e shpejta. Rritja e një ndryshoreje lokale në një funksion funksionon pothuajse në të njëjtën mënyrë.
21. Rritja e një ndryshoreje globale është dy herë më e ngadaltë se ajo e një variabli lokal.
22. Rritja e një vetie të objektit (dmth $this->prop++) është tre herë më e ngadaltë se një ndryshore lokale.
23. Rritja e një ndryshoreje të papërcaktuar është 9-10 herë më e ngadaltë se ajo e një variabli të para-incializuar.
24. Deklarimi i një ndryshoreje globale pa e përdorur atë në një funksion gjithashtu ngadalëson punën (përafërsisht me të njëjtën sasi si rritja e një ndryshoreje lokale). PHP ndoshta po kontrollon për të parë nëse ndryshorja ekziston.
25. Shpejtësia e thirrjes së metodës nuk duket se varet nga numri i metodave të përcaktuara në klasë. Unë shtova 10 metoda në klasën e testimit (para dhe pas metodës së provës), pa ndryshim të performancës.
26. Metodat në klasat e derivuara funksionojnë më shpejt se ato të përcaktuara në klasën bazë.
27. Thirrja e një funksioni me një parametër dhe një trup funksioni bosh mesatarisht është e barabartë me 7-8 rritje të ndryshores lokale ($localvar++). Thirrja e një metode të ngjashme, natyrisht, kërkon rreth 15 rritje.
28. Vargjet tuaja të përcaktuara me " në vend të " do të interpretohen pak më shpejt sepse PHP kërkon variabla brenda "..", por jo "...". Sigurisht, ju mund ta përdorni këtë vetëm kur nuk ka variabla në vargun tuaj.
29. Linjat e kufizuara me presje printohen më shpejt se linjat e ndara me pika. Shënim: Kjo funksionon vetëm me funksionin echo, i cili mund të marrë shumë rreshta si argumente.
30. Skriptet PHP do të përpunohen të paktën 2-10 herë më ngadalë se faqet statike HTML. Provoni të përdorni më shumë faqe HTML statike dhe më pak skripta.
31. Skriptet tuaja PHP ripërpilohen çdo herë nëse skriptet nuk ruhen në memorie. Memoria e skripteve zakonisht përmirëson performancën me 25-100% duke hequr kohën e përpilimit.
32. Cache sa më shumë që të jetë e mundur. Përdorni memcached, një sistem memorie të objekteve me performancë të lartë që përmirëson shpejtësinë e aplikacioneve dinamike të ueb-it duke e bërë më të lehtë ngarkimin e bazës së të dhënave. Mikrokodi i memorizuar është i dobishëm sepse parandalon që skripti juaj të kompilohet përsëri për çdo kërkesë.
33. Kur punoni me vargje, kur duhet të siguroheni që një varg ka një gjatësi të caktuar, sigurisht që do të dëshironi të përdorni funksionin strlen(). Ky funksion është shumë i shpejtë sepse nuk kryen asnjë llogaritje, por kthen vetëm gjatësinë e njohur tashmë të vargut, e disponueshme në strukturën zval (një strukturë e brendshme C që përdoret kur punoni me variabla në PHP). Megjithatë, për shkak se strlen() është një funksion, ai do të jetë i ngadalshëm për shkak të faktit se do të thërrasë disa operacione, të tilla si konvertimi i vargjeve me shkronja të vogla dhe kërkimet e tabelës hash, përpara se të kryhen veprimet kryesore të funksionit. Në disa raste, ju mund të shpejtoni kodin tuaj duke përdorur trukun isset().
    Ishte: nëse (strlen($foo)< 5) { echo «Foo is too short»; }
    Tani: nëse (!isset($foo(5))) (jehonë "Foo është shumë i shkurtër"; )
    Thirrja e isset() është më e shpejtë se strlen() sepse, ndryshe nga strlen(), isset() nuk është një funksion, por një konstrukt gjuhësor. Për shkak të kësaj, isset() nuk ka pothuajse asnjë shpenzim për përcaktimin e gjatësisë së vargut.
34. Rritja ose zvogëlimi i një ndryshoreje duke përdorur $i++ është pak më i ngadalshëm se ++$i. Ky është një veçori e veçantë e PHP dhe nuk duhet të modifikoni kodin tuaj C dhe Java në këtë mënyrë duke menduar se do të funksionojë më shpejt, por jo. ++$i do të jetë më i shpejtë në PHP sepse në vend të katër komandave si me $i++, ju duhen vetëm tre. Pas rritjes zakonisht përdoret kur krijohen ndryshore të përkohshme që më pas rriten. Ndërsa rritja paraprake rrit vlerën e ndryshores origjinale. Kjo është një nga mënyrat për të optimizuar kodin PHP në bytecode duke përdorur mjetin Zend Optimizer. Sidoqoftë, kjo është një ide e mirë, pasi jo të gjithë optimizuesit e bajtkodit optimizohen për këtë, dhe ka ende shumë skripta që funksionojnë pa optimizim të bajtkodit.
35. Jo çdo gjë duhet të jetë OOP, kjo është shpesh e panevojshme pasi çdo metodë dhe objekt merr shumë memorie.
36. Mos e përcaktoni çdo strukturë të dhënash si klasë, vargjet mund të jenë shumë të dobishme
37. Mos i prishni shumë metodat. Mendoni se çfarë do të ripërdorni në të vërtetë.
38. Ju gjithmonë mund ta ndani kodin në metoda më vonë, sipas nevojës.
39. Përdorni funksione të panumërta të paracaktuara.
40. Nëse kodi juaj ka funksione që kërkojnë një kohë shumë të gjatë për t'u ekzekutuar, merrni parasysh t'i shkruani ato në C si një shtesë
41. Profilizoni kodin tuaj. Profilizimi do t'ju tregojë se sa kohë marrin pjesë të kodit tuaj për t'u ekzekutuar.
42. mod_gzip është një modul Apache që ju lejon të kompresoni të dhënat tuaja menjëherë dhe mund të zvogëlojë sasinë e të dhënave të transferuara deri në 80%.

Në këtë artikull unë dua të jap disa këshilla, pas të cilave ju mund të shpejtoni ndjeshëm përpunimin e skripteve PHP, duke çliruar kështu serverin e hostit nga puna e padobishme në favor të më të dobishmeve ...

Përdorni thonjëza të vetme në vend të thonjëzave të dyfishta

Fakti është se teksti i mbyllur në thonjëza të dyfishta skanohet nga procesori për praninë e variablave, si dhe zëvendësimet memorike (për shembull, \n për të futur një karakter të linjës së re në tekst).

print("Ky është tekst krejtësisht normal, por procesori PHP e skanon atë për variabla dhe zëvendësime kujtese përpara se ta nxjerrë atë. Nëse një rresht i tillë është mjaft i gjatë, ky proces kërkon një kohë të konsiderueshme.");

Nëse teksti është i mbyllur në thonjëza të vetme, atëherë interpretuesi PHP e shfaq me bindje në formën e tij origjinale, pa menduar as të kërkojë diçka në të. Kjo kërkon shumë më pak kohë sesa në shembullin e mëparshëm.

print("Procesori PHP do të jetë shumë i lumtur kur të shohë një varg të mbyllur në thonjëza të vetme. Dhe si mund të mos jesh i lumtur - nuk ka nevojë të bësh punë të padobishme!");

Natyrisht, vargjet e këtij lloji mund të përdoren jo vetëm në funksione, por edhe në variabla.

$string="Çfarë bekimi është të mos e analizosh më këtë rresht!";

Mos vendosni variabla në thonjëza

Shumë shpesh ju shihni një pamje të ngjashme.

print("Procesorit PHP iu deshën $time sekonda për të përpunuar këtë faqe.");

Pasi mësova këshillat e mia të mëparshme dhe duke ditur se është shumë më e lehtë për interpretuesin PHP të "ngjisë" vargjet së bashku sesa t'i skanojë ato për variabla dhe t'i zëvendësojë ato me vargjet që korrespondojnë me ato variabla, nuk është e vështirë të merret me mend se shembulli im i mëparshëm është një shembull i përdorimit joefikas të burimeve të serverit. Tani le të kënaqim serverin me një skenar të optimizuar.

print("Procesori PHP, duke shijuar jetën, e përpunoi këtë skript në ".$time." sekonda.");

Për ata në rezervuar: linjat bashkohen duke përdorur një pikë (.), domethënë

print("Adresa e kësaj faqeje është http://".$_SERVER["HTTP_HOST"]."/!");

do të shfaqë tekstin "Adresa e kësaj faqeje është http://argon.com.ru/!"

Përdorni një minimum variablash

Duhet të mbani mend gjithmonë se çdo variabël global ruhet në memorie për të gjithë kohëzgjatjen e skriptit! Si shembull i talljes së serverit, unë do të jap kodin e mëposhtëm.

Pyetja është, pse dreqin duhet të marrim memorie shtesë, duke humbur ngarkesën e serverit?.. Është shumë më efikase ta bëjmë këtë në këtë mënyrë.

print("Procesori PHP kënaqet duke nxjerrë linja si kjo.");

Pra, nëse një varg përdoret më pak se dy herë, caktimi i një ndryshoreje vlera e atij vargu është e dëmshme.

Përdorni emra të shkurtër të ndryshoreve

Nëse skripti përdor variabla me emra të paarsyeshëm të gjatë, ngarkesa në server natyrisht rritet.

$windows_xp_edition="Profesionale";
$windows_xp_build="2600";
$windows_server2003_edition="Standard";
$windows_server2003_build="3200";

Por nuk duhet të jepni as emra shumë lakonë - në të ardhmen, kur redaktoni një skenar me përmasa mbresëlënëse, do të kujtoni nënën e krijuesit të tij njëqind herë, dhe jo me një fjalë të dashur :)

$ifa="Profesionist";
$ifb="2600";
$ifc="Standard";
Sifd = "3200";

Mundësia më e mirë është të jepni emra lakonik, por të kuptueshëm, jo ​​më shumë se tetë karaktere.

$wxped="Profesionist";
$wxpbld = "2600";
$ws2k3ed="Standard";
Sws2k3bld = "3200";

Përdorni funksionet e mbivendosura

Ju e shihni këtë lloj gjëje shumë shpesh.

$string=str_replace("\n"," ",$string);
$string=str_replace("\r"," ",$string);
$string=trim($string);
$string=stripslashes($string);
$string=cop($string);
$string=substr($string,0,1024);
print ($string);

$string)))))), 0,1024));

Jam dakord, duket e frikshme, por ka një rritje të dukshme të produktivitetit! Është shumë e lehtë ta bësh një gjë të tillë nëse e nis nga fundi, duke zëvendësuar çdo herë vlerën përkatëse për variablin...

Përdorni funksione të integruara

Më lejoni t'ju jap një shembull të thjeshtë të një skripti që zëvendëson të gjithë karakteret e veçanta HTML me zëvendësimet e tyre përkatëse të kujtesës.

$string=str_replace("<","<",$string);
$string=str_replace(">"",">",$string);
print ($string);

E njëjta gjë mund të arrihet nëse përdorni këtë kod.

print(htmlspecialchars($string));

Duket më bukur, peshon më pak dhe zvogëlon ndjeshëm ngarkesën në server, veçanërisht kur përpunoni vargje të gjata.

Një shembull më shumë. Duke përdorur këtë skript ju mund të lexoni përmbajtjen e një skedari teksti në një grup.

$fp=fopen("baza e të dhënave.txt","r");
ndërsa ($array=fgets($fp,1024));
fclose ($fp);

Por PHP ka një funksion jashtëzakonisht të dobishëm të integruar file() që bën saktësisht të njëjtën gjë, por shumë më shpejt!

skedari ("baza e të dhënave.txt");

Përfundim: mos jini kurrë dembel për të hedhur një vështrim tjetër në librin e referencës së funksioneve PHP. Jam i sigurt se do të gjeni shumë mjete atje për ta bërë jetën tuaj (dhe të serverit) më të lehtë.

Përdorni funksionet tuaja

Shpesh është e nevojshme të përpunohen disa rreshta duke përdorur saktësisht të njëjtin algoritëm. Kjo është ajo që bëjnë programuesit e papërvojë...

print(substr(cop(stripslashes(trim(str_replace("\r"," ",str_replace("\n"," ", $string1))))),0,1024));
print(substr(cop(stripslashes(trim(str_replace("\r"," ",str_replace("\n"," ", $string2))))),0,1024));

Dhe ata me përvojë do të marrin një rrugë më të thjeshtë.

formati i funksionit (&$string)(

}
print(format($string1));
print(format($string2));

Në këtë mënyrë ju mund të kryeni të njëjtin veprim disa herë, duke ngarkuar minimalisht serverin.

Mos krijoni funksione të panevojshme

Për shembull, nëse një programues mjaft me përvojë harron ose nuk di as për ekzistencën e një funksioni të integruar që i nevojitet, ai mund ta shkruajë lehtësisht një të tillë vetë.

optimizimi i funksionit (&$string)(
$string=str_replace("&","&",$string);
$string=str_replace(""",""",$string);
$string=str_replace("<;","<",$string);
$string=str_replace(">"",">",$string);
}
print(optimize ($string));

Por ju mund t'ia dilni me mjete më të thjeshta.

print(htmlspecialchars($string);

Mos përdorni veçori të panevojshme

Këtu është një shembull i kodit joefikas.

print ("Xhaxhai im");
print("i grabiti më të ndershmit...");

Por mund të optimizohet shumë lehtë.

print("Xhaxhai im "."rregullat më të ndershme...");

A e ndjeni ndryshimin? Më besoni, hosti në këtë rast do t'ju jetë mirënjohës vetëm për burimet e liruara të serverit ...

Përdorni funksionet me mençuri

Për shembull, ky skenar.

print(ereg_replace("normal","i pakënaqur",$string));

Aktivizon algoritmin e përpunimit të shprehjeve të rregullta (POSIX) aty ku nuk kërkohet fare. Dhe serveri është i ngarkuar shumë më tepër. Por ju mund ta lehtësoni fatin e tij duke zëvendësuar funksionin grykës me një më pak të pangopur për burime.

print(str_replace ("i pakënaqur", "i lumtur",$string));

Mos e përkulni shumë mbajtësin

Dihet se gjithçka që gjendet jashtë një kodi PHP nuk përpunohet nga procesori PHP, por thjesht transmetohet i pandryshuar. Disa njerëz e përdorin atë në këtë mënyrë.

...koka e faqes...
print ($titull);
?>
…navigacion…

?>
...fundi i faqes...

Por hyrja dhe dalja nga modaliteti i përpunimit PHP ngarkon serverin më shumë sesa nëse do të përdorej.

print("...koka e faqes...".$title."...navigacion...");
përfshijnë ("përmbajtje dinamike");
print("...fundi i faqes...");
?>

Vazhdon

Deri më tani, unë kam mbuluar vetëm një pjesë të vogël të ajsbergut të optimizimit të PHP. Është e mundur që ndjekja e një këshille të mos sjellë një rritje të dukshme të produktivitetit, por ndjekja e të gjitha këtyre rregullave bazë të mirësjelljes së programuesit së bashku do të zvogëlojë ndjeshëm ngarkesën në server dhe do të rrisë autoritetin tuaj.

Nëse keni ndonjë pyetje ose sugjerim, ju lutemi kontaktoni.

Fat i mirë me optimizimin tuaj!

Kur zhvilloni projekte të mëdha, lind gradualisht çështja e optimizimit të kodit të projektit: sa i justifikuar është konsumi i kujtesës, si mund të rrisni shpejtësinë e ekzekutimit të kodit të shkruar PHP. Në fillim, shumë njerëz nuk mendojnë për korrektësinë dhe efikasitetin e kodit të shkruar, ata shkruajnë sipas parimit: funksionon - dhe kjo është në rregull. Megjithëse interpretuesi PHP është mjaft i shpejtë në ekzekutimin e kodit PHP, dhe ka shumë pengesa që ngadalësojnë ekzekutimin e kodit që janë jashtë PHP, optimizimi i kodit PHP është gjithashtu i rëndësishëm dhe optimizimi i kodit duhet të zbatohet në fillim të procesit të kodimit.

Shumica e skripteve PHP bëjnë gjëra të thjeshta. Sjellja standarde e skriptit është të shkarkojë një sasi të vogël informacioni nga përdoruesi, të marrë disa informacione nga një bazë të dhënash ose skedar, të nxjerrë HTML-në e duhur dhe t'i dërgojë rezultatin klientit. Këtu, gjëja e parë që duhet të kuptoni është se cili duhet të jetë saktësisht rezultati i optimizimit: performanca, lehtësia e shkallëzimit, zvogëlimi i sasisë së burimeve të përdorura të serverit, zvogëlimi i kohës së transferimit të të dhënave ose të gjitha së bashku. Në rastin e fundit, është e nevojshme jo vetëm për të gjetur të gjitha fushat kritike, por edhe për të balancuar optimizimin e tyre.

Më lejoni t'ju jap një shembull të thjeshtë: le të ketë dy skripta në një server me 100 MB RAM të lirë, rezultati i të cilit është i njëjtë. Skripti i parë është i optimizuar për performancë maksimale, kërkon 10 MB memorie dhe merr të dhëna nga një skedar duke e lexuar plotësisht, i dyti është i optimizuar për konsum minimal të memories, kërkon 5 MB memorie dhe merr të dhëna nga i njëjti skedar në pjesë. Si rezultat i një kërkese, skripti i parë do të ekzekutohet më shpejt se i dyti, por nëse ka më shumë se dhjetë kërkesa në të njëjtën kohë, është shpejtësia e skriptit të dytë që do të bëhet më e lartë. Pse po ndodh kjo? Në skenarin e parë, pengesa është përdorimi i burimeve të kujtesës, në të dytën - tiparet e sistemit I/O. Pasi skripti i parë të konsumojë të gjithë RAM-in e disponueshëm, sistemi do të kalojë në përdorimin e memories virtuale dhe i njëjti sistem I/O do të bëhet një pengesë shtesë e kësaj skeme.

Sigurisht, ky shembull është shumë i thjeshtuar dhe ka edhe pengesa të tjera përveç RAM-it, por ideja kryesore është kjo: optimizimi për një rast mund të bëhet një pikë kritike në një tjetër. Në shembull, si rezultat i optimizimit për një rritje të lehtë të shpejtësisë në ngarkesa të ulëta, shpejtësia e ekzekutimit të skriptit në ngarkesa më të larta u ul ndjeshëm. Prandaj, për të marrë kthime më të mira, është e rëndësishme të shpenzoni energjinë tuaj duke optimizuar zonat që me të vërtetë meritojnë vëmendje.

Unë nuk do të konsideroj këtu optimizimin e sistemit operativ, optimizimin e cilësimeve të serverit, etj., sepse... Shumica e webmasterëve përdorin hosting dhe, në përputhje me rrethanat, nuk do të jenë në gjendje të konfigurojnë gjithçka vetë. Këtu do të merret parasysh vetëm optimizimi i kodit PHP. Duhet të theksohet se në secilin rast specifik, disa lloje të optimizimit do të jenë të dobishme, të tjerët do të jenë humbje kohe dhe përpjekjesh. Shpesh përfitimi i përmirësimit të kodit do të jetë i papërfillshëm. Ndoshta, me kalimin e kohës, ndryshimet e brendshme në PHP do ta bëjnë optimizimin e suksesshëm të padobishëm apo edhe të dëmshëm.

Më poshtë janë hapat kryesorë të performancës për versionin PHP 5:

Veprimet për të optimizuar konsumin e RAM-it:

1. Analizoni rezultatet e funksioneve tuaja. Përpara se të shkruani një funksion, kontrolloni nëse ka një ekuivalent standard.
2. Lirimi i memories kur përfundojnë grupe të mëdha ose objekte duke u përdorur vetëm në shtrirjen globale (kujtesa do të lirohet automatikisht në shtrirjen lokale). Ju lutemi vini re se funksioni unset () heq një variabël nga objekti dhe, vetëm nëse nuk ka referenca të tjera për objektin, çliron memorien e zënë nga objekti. Caktimi i një vlere për një ndryshore i pavlefshëm gjithmonë shkatërron objektin dhe çliron kujtesën e zënë nga objekti, pavarësisht nëse ka ende referenca për këtë objekt. Në këtë rast, ndryshorja nuk do të hiqet nga objekti, d.m.th. në fakt, ndryshorja do të përmbajë një vlerë të papërcaktuar (zero) dhe, në përputhje me rrethanat, do të zërë memorie për përmbajtjen e kësaj ndryshore (rreth 72 bajt).
3. Analiza e justifikimit të përdorimit të OOP (programimi i orientuar në objekt). Përpara se të shkruani kodin e orientuar nga objekti, bëni vetes dy pyetje: "A kërkon kjo një qasje e orientuar nga objekti?" dhe "a mund të shkruaj kod të orientuar nga objekti?" Për shembull, përcaktimi i një funksioni statik brenda një klase rrit sasinë e memories që kërkohet vetëm për të përmbajtur atë funksion me 10-18%. Përdorimi i një grupi në vend të një klase si strukturë gjithashtu kursen kujtesën. Mund të jetë më fitimprurëse thjesht vendosja e funksioneve në një skedar të veçantë, në vend që t'i zbatojë ato si metoda të klasës.
4. Analiza e mundësisë së zbatimit të një versioni statik të një metode në një klasë. Nëse metoda nuk përdor një parametër $kjo, atëherë duhet të deklarohet duke përdorur fjalën kyçe statike.

Veprimet për të rritur shpejtësinë e ekzekutimit të kodit:

1. Analiza e optimizimit të pyetjeve SQL. Në shumicën e projekteve, është optimizimi i pyetjeve SQL ai që siguron rritjen më të madhe të performancës.
2. Përdorimi i buferimit të daljes dhe moduleve të ndryshme të memorizimit mund të rrisë performancën me 25% -100%.
3. Përdorimi i emrave të shkurtër më të shkurtër për variabla, funksione, konstante dhe klasa mund të përmirësojë performancën deri në 20%. Në të njëjtën kohë, mos harroni për mbështetjen e mëtejshme të kodit, një emër i qartë i funksionit është shumë më i përshtatshëm kur modifikoni kodin.
4. Kontrollimi i ekzistencës së një ndryshoreje (funksioni isset ()) përpara se të kontaktoni me të. Shuarja e gabimit që ndodh kur aksesoni një variabël inekzistent duke përdorur @ është një sukses i madh i performancës.
5. Përdorimi i "thonjëzave të vetme" ju lejon të interpretoni kodin më shpejt, sepse në rastin e "thonjëzave të dyfishta", ndryshoret kërkohen brenda vargut
6. Analiza e mundësisë së heqjes së funksioneve "shtesë" nga cikli. Për shembull, zëvendësimi i një funksioni numëro () në një variabël të llogaritur përpara fillimit të ciklit dhe që përmban rezultatin e këtij funksioni, në shprehje për ($i=0; $i do të përmirësojë performancën e këtij cikli. Përndryshe funksioni numëro () do të thirret dhe do të ekzekutohet në çdo përsëritje të ciklit.
7. Duke përdorur operatorin rast në vend të përdorimit të konstrukteve të shumta nese Tjeter.
8. Përdorimi i aksesit të qartë në fushat e grupit. Kthimi i formës $array["id"] shkon 7 herë më shpejt se përmbysja grup $. Përveç kësaj, kjo mbron nga gabimet gjatë mbështetjes së mëtejshme të skenarit, sepse një ditë mund të ketë një konstante me emër id.
9. Përdorimi i një ndryshoreje shtesë që përmban një referencë për grupin përfundimtar kur përpunohen vargje shumëdimensionale në një lak. Për të përshpejtuar ciklin për ($i = 0; $i< 5; $i++) $a["b"]["c"][$i] = func($i); , para fillimit të ciklit është e mundur të shkruhet instruksioni tjetër $item =p$a["b"]["c"] dhe rishkruani ciklin si kjo: për ($i = 0; $i< 5; $i++) $ref[$i] = $i; .
10. Përdorimi i moduleve Apache mod_gzip dhe mod_deflate ju lejon të reduktoni trafikun, duke rritur kështu shpejtësinë e ngarkimit të faqeve.

Hapat e mëposhtëm të optimizimit të kodit përmirësojnë performancën vetëm kur përdoren në mënyrë të përsëritur: