Aktivering av dynamisk komprimering av gjengitte HTML-sider (

) kan komprimere dem med et gjennomsnitt på 20-60%, øke nedlastingshastigheten og redusere antall "hengende" prosesser. Har du en båndbreddebegrensning på hostingen din? Da vil dynamisk sidekomprimering gi doble fordeler.

Selvfølgelig bør det huskes at buffering øker minneforbruket litt og komprimering - en belastning på prosessoren. Men disse ofrene blir ofte mer enn kompensert for av fartsøkningen. Og ikke bare hastigheten på opprettelsen, men også hastigheten på lasting av siden.

Endelig kan en frontend http-server ta ytelsen til PHP-skriptene dine til neste nivå. Faktum er at selv med caching vil prosessene knyttet til brukerens forespørsel "henge" til brukeren aksepterer alle dataene (eller til tidsgrensen er nådd). Essensen av frontend-serveren er å umiddelbart motta data, slik at du umiddelbart kan laste ut de behandlede prosessene. Det er en slags kobling mellom brukeren og en ganske "tung" backend-server - hvor PHP-skriptene dine blir utført. Men på grunn av sin "letthet" reduserer front-end-serveren de forbrukte ressursene betydelig. Igjen, dette er et veldig bredt tema, og vi vil se nærmere på det i nær fremtid.

6) Totalt inklusive

Anta at du har laget din "motor" i PHP, fulgt alle de tidligere tipsene. Det vil nesten uunngåelig inneholde mange forskjellige inkluderinger: konfigurasjonsfiler, funksjoner, språk, etc. Poenget er at selv en normal inkludering av samme fil med funksjoner vil kreve mye tid og minne, selv om det i tillegg til funksjonene i include ikke er noen kjørbar kode, og ikke en av funksjonene kalles.

Men funksjonene er veldig forskjellige og spesifikke. Så å legge hele listen over funksjoner i én fil og inkludere den hver gang er ikke den beste løsningen. For eksempel har nettstedet brukerregistrering: for dette kan du ha en rekke spesialfunksjoner som kun brukes under registrering. Så hvorfor legge dem inn i den generelle inkluderingen av funksjoner, som kobles til hver gang du går inn på sidene på nettstedet?

Ikke overse optimaliseringen av inneslutninger. Ta ut det som ikke er universelt brukt i separate, spesialiserte inneslutninger. Et annet eksempel for forankring. Min favoritt nyhetssidemotor. Funksjonene for å legge til nyheter, kommentarer, deres kontroll og preparsing tar omtrent 1/3 av koden av det totale antallet funksjoner. Men hvor ofte trengs de? I 1 av 100 søk? Eller 1 av 200? Eller enda sjeldnere? Så hvorfor laste dem hver gang? Dette kan faktisk redusere ytelsen til løsningene dine betydelig.

7) Overflødig funksjonalisering og OOP-tymisme

Funksjoner bør bare brukes når det virkelig gir mening. La oss huske det grunnleggende formålet med funksjoner. Dette er ikke noe mer enn en takeaway

deler av koden til en egen, felles del. I prinsippet er det fornuftig å plassere koden i en "separat del" selv når den utføres på en relativt usannsynlig hendelse. For eksempel ved å legge ved et bilde til et foruminnlegg. Å flytte handleren for lasting og bearbeiding av et bilde til en "separat del" vil ha en positiv effekt på ytelsen, selv om den er inkludert i en betingelse (det faktum å laste et bilde). Dessuten, hvis vi trenger denne "separate delen" bare én gang, er det bedre å kjøre den bare som en kode (inkluder), og ikke som en funksjon. Funksjoner krever alltid noen ekstra ressurser. Det samme gjelder OOP-programmering i PHP. OOP-kode bruker litt mer ressurser, så hvis du ikke er interessert i OOP-kodeformatering, er det bedre å forlate den. Jeg snakker spesifikt om OOP-formatering, siden OOP-tilnærmingen i PHP har lite å gjøre med selve konseptet OOP-programmering. Samt PHP med en klassisk forståelse av programmeringsspråk og deres oppgaver - som jeg skrev om i begynnelsen.

Nå er du kjent med 7 grunnleggende prinsipper for produktiv PHP-kode. Dette er bare - bare begynnelsen. Vi har fortsatt mye interessant, mer spesifikt materiale om dette emnet fremover.

Jeg studerte hele httpd.conf, gravde opp en haug med guider om høybelastning (de er gamle og med tvilsomme råd som "deaktiver unødvendige moduler"

1) Har alle VPS en såkalt "kraftig" prosessor tregere enn på en eller annen patetisk hosting, om enn med VIP-tariff?

2) Vil FastCGI hjelpe i en slik situasjon?

3) Hvorfor er eAccelerator-funksjoner ikke populære (AST-bufring osv.)?

Jeg vet at mange av dem er forlatt, men dette er ikke en årsak, men en virkning.

4) Hva annet kan hjelpe?

P.S. Hvis du formulerer spørsmålet(e) mer presist, kan jeg gi mer presise anbefalinger, hvis du selvfølgelig trenger dem :)

P.P.S. Det er en måte å løse problemet på generelt "head-on", den vanskeligste og kanskje den mest produktive i noen tilfeller. Dette er lakk + finjustering av det, det lar deg utstede de fleste sidene fra cachen (RAM) på nanosekunder, noen ganger lar det deg betjene mange tusen forespørsler per minutt, mens dette ikke bare er kodebufring eller noe sånt at ... dette er caching i sin helhet sider og/eller serversvar. Den lar deg blant annet «ikke berøre backend i det hele tatt», d.v.s. når en side blir forespurt, kan det hende det ikke er noen databasetilgang, eller kjøring av den samme PHP-koden (eller annen) på serversiden. Det krever ganske finjustering, er lite egnet for nettsteder "på CMS", for nettsteder på rammeverk - det krever en i utgangspunktet riktig tilnærming til utvikling og tenkning over hva og hvordan som skal/skal bufres. Med en feil tilnærming - det mest sannsynlige resultatet - vil det fungere, men ikke så raskt som vi ønsker, og deler av siden kan slutte å fungere normalt. Det finnes også andre løsninger, men med tanke på den ganske generelle formuleringen av spørsmålet, er det ganske vanskelig å snakke om dem.

Å ja, jeg glemte en viktig detalj ... Hvorfor bruker "hosting" Apache og ikke forlate det (helt)? Mest på grunn av at Apache lar deg delegere noen av innstillingene til brukeren gjennom .htaccess. Samtidig, for statikk, er det ikke uvanlig å bruke den samme Nginx, som, som du forstår, ikke tillater å delegere deler av innstillingene til brukeren på denne måten, med tanke på at den ikke er egnet for disse oppgavene og "hopper ikke over" dette (i motsetning til Apache "men inkludert av denne grunn nektet vi 99% av "hosting" (på grunn av tilstedeværelsen av Apache, og umuligheten av å bli kvitt den eller konfigurere den på egen hånd, og som et resultat av "bremsene" som følger med en slik tilnærming) ...

Ønsker dere alle en god dag.

1. Hvis metoden kan være statisk, erklær den statisk.
2. ekko er raskere enn utskrift.
3. Send flere parametere til ekko i stedet for å bruke strengsammenkobling.
4. Angi maksimalt antall passeringer av dine for-løkker før løkken, ikke mens den kjører.
5. Slett variablene dine for å frigjøre minne, spesielt hvis de er store matriser.
6. Pass på magiske metoder som __set, __get, __autoload.
7. require_once er dyrt.
8. Spesifiser fullstendige stier i include / require-konstruksjoner, mindre tid vil bli brukt på å søke etter filen.
9. Hvis du trenger å bestemme tidspunktet da skriptet ble kjørt, bruk $ _SERVER ['REQUEST_TIME'] i stedet for tid ().
10. Prøv å bruke strncasecmp, strpbrk og stripos i stedet for regulære uttrykk.
11. str_replace er raskere enn preg_replace, men strtr er raskere enn str_replace.
12. Hvis en funksjon, som strengerstatningsfunksjoner, kan akseptere både matriser og enkelttegn som argumenter, og hvis argumentlisten din ikke er for lang, bør du vurdere å skrive flere identiske erstatningsuttrykk, gå gjennom ett tegn om gangen, i stedet for én streng. kode som tar en matrise som et søk og erstatt-argument
13. Det er bedre å velge utsagn ved å bruke en else if-setning enn å bruke flere if-setninger.
14. Feilundertrykkelse ved bruk av @ er veldig sakte.
15. Bruk Apache mod_deflate-modulen.
16. Lukk DB-tilkoblingene når du er ferdig med å jobbe med dem.
17. $ row ["id"] er syv ganger raskere enn $ row.
18. Feilmeldinger er dyre
19. Ikke bruk funksjoner inne i en for loop-tilstand, som denne: for ($ x = 0; $ x< count($array); $x). В данном случае функция count() будет вызываться с каждым проходом цикла.
20. Å øke en lokal variabel i en metode er den raskeste. Å øke en lokal variabel i en funksjon fungerer nesten på samme måte.
21. Å øke en global variabel er dobbelt så sakte som en lokal.
22. Å øke en objektegenskap (dvs. $ this-> prop ++) er tre ganger langsommere enn en lokal variabel.
23. Å øke en udefinert variabel er 9-10 ganger langsommere enn en tidligere initialisert.
24. Å erklære en global variabel uten å bruke den i en funksjon bremser også ting (med omtrent samme mengde som å øke en lokal variabel). PHP sjekker sannsynligvis om det finnes en variabel.
25. Hastigheten på metodeanrop avhenger tilsynelatende ikke av antall metoder som er definert i klassen. Jeg la til 10 metoder til testklassen (før og etter testmetoden), ingen ytelsesendring.
26. Metoder i avledede klasser er raskere enn de som er definert i basisklassen.
27. Et funksjonskall med én parameter og en tom funksjonskropp er i gjennomsnitt 7-8 trinn av den lokale variabelen ($ localvar ++). Å kalle en lignende metode er selvfølgelig omtrent 15 trinn.
28. Strengene dine definert med "heller enn" vil bli tolket litt raskere fordi PHP ser etter variabler i "..", men ikke "...". Selvfølgelig kan du bare bruke dette når det ikke er noen variabler i strengen din.
29. Kommaseparerte linjer skrives ut raskere enn punktdelte linjer. Merk: dette fungerer bare med ekkofunksjonen, som kan ta flere linjer som argumenter.
30. PHP-skript vil bli behandlet minst 2-10 ganger langsommere enn statiske HTML-sider. Prøv å bruke flere statiske HTML-sider og færre skript.
31. PHP-skriptene dine kompileres på nytt hver gang hvis skriptene ikke er bufret. Skriptbufring øker vanligvis ytelsen med 25-100 % ved å fjerne kompileringstiden.
32. Buffer så mye som mulig. Bruk memcached, et høyytelses inne-minnet objektbufringssystem som forbedrer hastigheten til dynamiske webapplikasjoner ved å gjøre det enklere å laste databaser. Bufret mikrokode er nyttig fordi det hindrer skriptet ditt fra å kompileres igjen for hver forespørsel.
33. Når du arbeider med strenger, når du skal sørge for at strengen har en viss lengde, vil du selvfølgelig bruke strlen () funksjonen. Denne funksjonen er veldig rask, fordi den ikke utfører noen beregninger, men returnerer kun den allerede kjente strenglengden som er tilgjengelig i zval-strukturen (den interne C-strukturen som brukes når man arbeider med variabler i PHP). Men fordi strlen () er en funksjon, vil den gå tregt ved å kalle noen operasjoner, for eksempel å konvertere en streng til små bokstaver og søke i en hash-tabell, først hvoretter hovedhandlingene til funksjonen vil bli utført. I noen tilfeller kan du øke hastigheten på koden din ved å bruke isset ()-trikset.
    Var: if (strlen ($ foo)< 5) { echo «Foo is too short»; }
    Nå: if (! Isset ($ foo (5))) (ekko "Foo er for kort";)
    Isset () er raskere enn strlen () fordi, i motsetning til strlen (), er isset () ikke en funksjon, men en språkkonstruksjon. Dette betyr at isset () praktisk talt ikke har noen strenglengde overhead.
34. Å øke eller redusere en variabel med $ i ++ er litt langsommere enn ++ $ i. Dette er spesifikt for PHP, og du trenger ikke å endre C- og Java-koden din på denne måten og tenker at den vil kjøre raskere, dette vil ikke skje. ++ $ i vil være raskere i PHP fordi i stedet for fire kommandoer, som med $ i ++, trenger du bare tre. Post inkrement brukes vanligvis når du oppretter midlertidige variabler som deretter økes. Mens pre-increment øker verdien av den opprinnelige variabelen. Dette er en av måtene Zend Optimizer optimerer PHP til bytekode. Dette er imidlertid en god idé, siden ikke alle bytekodeoptimalisatorer optimaliserer dette, og det er også ganske mange skript som kjører uten optimalisering til bytekode.
35. Ikke alt trenger å være OOP, det er ofte overkill, siden hver metode og objekt tar opp mye minne.
36. Ikke definer hver datastruktur som en klasse, arrays kan være veldig nyttige
37. Ikke overbryt metodene. Tenk på hva du faktisk vil gjenbruke.
38. Du kan alltid bryte ned koden i metoder senere, om nødvendig.
39. Bruk utallige forhåndsdefinerte funksjoner.
40. Hvis koden din inneholder funksjoner som tar svært lang tid å fullføre, bør du vurdere å skrive dem i C som en utvidelse.
41. Profiler koden din. Profilering vil vise deg hvor lang tid det tar å utføre deler av koden din.
42. mod_gzip er en Apache-modul som lar deg komprimere dataene dine på et øyeblikk og kan redusere mengden data som overføres med opptil 80 %.

I disse dager, når dedikert internettbåndbredde har blitt normen, trenger du egentlig ikke å bekymre deg for sidestørrelsen. Det er imidlertid fortsatt verdt å være oppmerksom på. Hvis du ønsker å redusere belastningen på serveren, reduser antall HTTP-forespørsler – det finnes flere teknikker for dette. Denne opplæringen vil dekke noen få PHP-triks (bufring, komprimering).

1. Kombinere CSS-filer med PHP.

Som webutviklere deler vi ofte stiler på tvers av flere stilark for en mer logisk struktur og enkel modifikasjon senere. Dette øker imidlertid antallet forespørsler til serveren, noe som fører til tregere sidelasting. Ved å bruke PHP kan vi slå to fluer i en smekk: ha flere stilark, og bruke bare ett søk for å få tilgang til dem alle.

Forberedelse

Før vi optimaliserer CSS-filene, trenger vi at stilene fungerer. La oss lage noen stilfiler:

// main.css
// CSS for eksempel

kropp (
bredde: 800px;
margin: 0 auto;
farge: grå;
}

#wrapper (
marg-top: 30px;
bakgrunn: url (../ bilder / cats.png);
}
// typography.css
// CSS for eksempel

kropp (
font-familie: Arial, san-serif;
font-weight: fet;
}

sterk (
skriftstørrelse: 120 %;
}
// forms.css
// CSS for eksempel

skjema (
stilling: pårørende;
topp: 400px;
z-indeks: 99;
}

input (
høyde: 50px;
bredde: 400px;
}

Vi må trekke ut innholdet i alle filene og slå dem sammen i en bestemt rekkefølge. Dette betyr at skriptet vårt skal hente navnene på stilarkene gjennom URL-parametrene, åpne disse filene og koble dem til.

// Definer variabler
$ cssPath = "./css/";
if (isset ($ _ GET ["q"))) (
$ filer = $ _GET ["q"];
// Få en rekke filer

foreach ($ filer som $ nøkkel => $ fil) (
}

$ cssData = "";
foreach ($ filer som $ fil) (

fclose ($ filhåndtak);
}
}
// Fortell nettleseren at vi har en CSS-fil
if (isset ($ cssData)) (
echo $ cssData;
) annet (
}
?>

// Definer variabler
// --- MERK: STIER MÅ ETTERSTREK ---
$ cssPath = "./css/";
if (isset ($ _ GET ["q"))) (
$ filer = $ _GET ["q"];
// Har en rekke filer!

// La oss sørge for at det ikke er noen skumle symboler i filnavnene :).
foreach ($ filer som $ nøkkel => $ fil) (
$ files [$ key] = str_replace (array ("/", "\\", "."), "", $ fil);
}

Denne koden setter banen til stiler-mappen og ser etter filer. Banen til mappen må ha skråstreker i begynnelsen og på slutten av mappenavnet, ellers får vi mange feil. Deretter sjekker vi hvert filnavn og fjerner prikker og/eller skråstreker.

$ cssData = "";
foreach ($ filer som $ fil) (
$ cssFileName = $ cssPath. $ fil. ".css";
$ fileHandle = fopen ($ cssFileName, "r");

$ cssData. = "\ n". fread ($ fileHandle, filstørrelse ($ cssFileName));
fclose ($ filhåndtak);
}
}

Nå må vi lage et generelt stilark fra filene. For å gjøre dette, kjører vi en løkke som går gjennom en rekke filer, åpner hver fil og setter den sammen til en enkelt fil. "\ n" legger til en ny linje for orden og renslighet. Filstørrelsen ()-funksjonen brukes til å finne ut lengden på en fil og sende den til fread ().

// Fortell nettleseren at vi har en CSS-fil
header ("Innholdstype: tekst / css");
if (isset ($ cssData)) (
echo $ cssData;
echo "\ n \ n // Generert:". dato ("r");
) annet (
echo "// Filer er ikke tilgjengelige eller ingen filer spesifisert.";
}
?>

Den siste delen av koden sender alle stilene til nettleseren. Dette betyr at vi må fortelle PHP at vi sender CSS-informasjon og at PHP bør informere nettleseren om det. Vi gjør dette med header () funksjonen, og setter Content-type: text / css. Deretter sender vi CSS til klienten. Men før det sjekker vi for tilstedeværelsen av CSS-stiler i filen. Hvis de ikke er der, betyr det at navnene på CSS-filene ikke ble overført. Hvis vi har filer, overfører vi dem og legger til en melding om generasjonen.

Undersøkelse

Nå er tiden inne for å teste manuset. Opprett en mappe og filer i den. Ta en titt på mappestrukturen nedenfor. Hvis du trenger en annen struktur, så ikke glem å endre banene.

Last nå opp alle filene til roten av nettstedet og få tilgang til index.php-filen via nettleseren din. Du bør bli møtt med uttrykket "Filer ikke tilgjengelige eller ingen filer spesifisert". Dette betyr at vi ikke har gitt navn på filene som må kobles til. Den gode nyheten er imidlertid at alt fungerer uten feil. La oss prøve å skrive ut "index.php? Q = main" i nettleseren. Du vil se innholdet i main.css-filen på skjermen. Hvis vi trenger å trekke ut flere filer og kombinere dem, må vi sende følgende forespørsel "index.php? Q = main & q = forms". Som du kan se, kan vi gjenta "q =" så mange ganger vi vil. Du kan kombinere minst 50 stilark til én fil.

Konklusjon

Denne metoden kan være svært nyttig og har mange fordeler. Du kan ha et felles stilark for hele nettstedet, og et eget for eksempel for sider med skjemaer.

En liten advarsel: hvis du legger index.php-filen i en hvilken som helst mappe (ikke i CSS-mappen), må du skrive relative stier til bakgrunnsbilder som om index.php var stilarket ditt. Dette er hva nettleseren vil tenke.

2. Fjerne tomme linjer fra HTML og CSS

Mange av oss bruker mange tomme linjer når vi skriver kode. Den gode nyheten er at tomme linjer i PHP ikke sendes til nettleseren. Imidlertid sendes de i HTML.

Blanke linjer bruker ubetydelig mengde trafikk. Hvis trafikken til nettstedene er stor, kan denne lille tallet vokse til en betydelig. Det er her PHP kommer oss til unnsetning.

Forberedelse

Nedenfor er kodene for HTML- og CSS-filer.

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Display: blokk;
bredde: 100 %;
høyde: 48px;
}
#Hoveddelen (
font-weight: fet;
}

Fordelen med dette skriptet er at det kan fungere med både HTML og CSS samtidig. Skriptet laster filen, fjerner alle tomme linjer, etterlater bare 1 mellomrom, slik at ordene ikke er sammenkoblet til en helhet.

$ fileDirectory = "";
$ fil = $ _GET ["q"];
$ ext = $ navnExplode;

// Se etter hackere
dø ("Hackere ...!");
) annet (
// La oss begynne


// Underverk av regulære uttrykk

fclose ($ håndtak);
// Vis data
if ($ ext == "css") (
header ("Innholdstype: tekst / css");
}
echo $ newData;
}
?>

Lær mer om hver del av koden

Vi får navnet på filen og sjekker typen. Deretter trekker vi ut alle dataene og fjerner mellomrom og tomme linjer. Denne metoden er den mest primitive og vil ikke fjerne alle tomme linjer, men den vil håndtere de fleste. Og det er bare noen få linjer med kode.

$ fileDirectory = "";
$ fil = $ _GET ["q"];
$ nameExplode = eksplodere (".", $ fil);
$ ext = $ navnExplode;
$ filnavn = $ filkatalog. $ fil;

Denne koden setter de nødvendige variablene. Igjen sender vi all data gjennom "q". Mappen for filer er også definert her.

If ($ ext! = "Css" OG $ ext! = "Htm" OG $ ext! = "Html") (
// Se etter hackere
dø ("Hackere ...!");
) annet (

Her sjekker vi om filen virkelig er CSS eller HTML.

// La oss begynne
$ handle = fopen ($ filnavn, "r");
$ filData = fread ($ håndtak, filstørrelse ($ filnavn));
// Underverk av regulære uttrykk
$ newData = preg_replace ("/ \ s + /", "", $ fileData);
fclose ($ håndtak);
// Vis data
if ($ ext == "css") (

header ("Innholdstype: tekst / css");
}
echo $ newData;
}
?>

Denne koden åpner og leser filen – og fjerner deretter så mye mellomrom som mulig. Dette oppnås ved å bruke regulære uttrykk. Alle mellomrom, tabulatorer, tomme linjer blir funnet og erstattet med et mellomrom.

Virker det?

Hvis du skriver "index.php? Q = css.css" i nettleseren din, vil du se én linje med CSS. Så alt fungerer! Hvis du åpner kildekoden til siden, vil du se det samme bildet. Med denne metoden har vi redusert CSS-filen på 314 tegn til 277 tegn. HTML-fil med 528 til 448 tegn. Ikke dårlig for 15 linjer med kode.

Konklusjon

Dette er et godt eksempel på hvordan vi kan gjøre mye med bare noen få linjer med kode. Hvis du tar en titt på kildekoden til nettsteder som Google, vil du legge merke til at det nesten ikke er tomme linjer.

3. Bufre PHP-skript.

Jeg vil vise deg hvordan du setter opp caching for skriptene dine ved å bruke eksemplet ovenfor. Målet er å få fart på nettstedet. Hovedpoenget er veldig enkelt - data vil ikke bli generert hver gang du går inn på siden. De vil bli lagret i cachen.

For å legge til caching, må vi legge til tre ting til skriptet vårt. Først må vi samle alle dataene i et skript og generere en fil som er unik for dette settet med innlagte data. For det andre må vi finne cache-filen og sjekke hvor "fersk" den er. For det tredje må vi bruke en bufret kopi eller generere en ny hurtigbufferfil for senere bruk.

Mer informasjon

$ fileDirectory = "";
$ fil = $ _GET ["q"];
$ nameExplode = eksplodere (".", $ fil);
$ ext = $ navnExplode;
$ filnavn = $ filkatalog. $ fil;
// - VI HAR NOK DATA TIL Å GENERE ET CACHE-FILNAVN HER -
if ($ ext! = "css" OG $ ext! = "htm" OG $ ext! = "html") (
// Se etter onde mennesker ...
dø ("Hackere ...!");
) annet (

// - VI KAN AVSTYRE OG SE ETTER DEN BUFFREDE VERSJONEN HER -

// La oss komme i gang
$ handle = fopen ($ filnavn, "r");
$ filData = fread ($ håndtak, filstørrelse ($ filnavn));
// Nå for litt regex-trolldom!
$ newData = preg_replace ("/ \ s + /", "", $ fileData);

Flukk ($ håndtak);
// Tid for å sende ut dataene.

// - NÅ KAN VI LAGRE DE NYE DATA OM NØDVENDIG OG UTGI DATA -

If ($ ext == "css") (
header ("Innholdstype: tekst / css");
}
echo $ newData;
}
?>

$ fileDirectory = "";
$ fil = $ _GET ["q"];
$ nameExplode = eksplodere (".", $ fil);
$ ext = $ navnExplode;
$ filnavn = $ filkatalog. $ fil;
$ cacheName = "./cache/". $ navnExplode. $ navnExplode. ".tmp";
if ($ ext! = "css" OG $ ext! = "htm" OG $ ext! = "html") (
// Hackere
print_r ($ ext);
dø ("Hackere ...!");
) annet (
if (fil_eksisterer ($ cacheName) OG filemtime ($ cacheName)> (tid () - 86400)) (


fclose ($ cacheHandle);
$ isCached = TRUE;
) annet (
// La oss begynne
$ handle = fopen ($ filnavn, "r");
$ filData = fread ($ håndtak, filstørrelse ($ filnavn));
// Underverk av regulære uttrykk
$ newData = preg_replace ("/ \ s + /", "", $ fileData);
fclose ($ håndtak);
// Buffer


fclose ($ cacheHandle);
$ isCached = FALSE;
}
// Vis data
if ($ ext == "css") (
header ("Innholdstype: tekst / css");
if ($ er bufret) (

}
) annet (
if ($ er bufret) (
ekko "";

}
}
echo $ newData;

Forklaring

I dette skriptet er funksjonen med å oppdatere cachen hver 24. time lagt til. Det er behagelig. Hvis du for eksempel har endret noe på siden, kan du vente i 24 timer eller tømme hurtigbufferen.

$ cacheName = "./cache/". $ navnExplode. $ navnExplode. ".tmp";

Denne kodebiten tar ut filnavnene og utvidelsene deres, limer dem sammen og legger dem til hurtigbufferen med riktig ".tmp"-utvidelse.

If (fil_eksisterer ($ cacheName) OG filemtime ($ cacheName)> (tid () - 86400)) (
$ cacheHandle = fopen ($ cacheName, "r");
$ newData = fread ($ cacheHandle, filstørrelse ($ cacheName));
fclose ($ cacheHandle);
$ isCached = TRUE;
) annet (

Her sjekker vi tilstedeværelsen av en lagret cache og om den ble opprettet i løpet av de siste 24 timene (verdien i sekunder kan endres til en hvilken som helst annen). Hvis begge betingelsene er oppfylt, åpner du filen og pakker ut innholdet for å erstatte resultatet av skriptet med det. Vi har også satt $ isCached true for å vise flere meldinger på slutten.

// La oss cache!
$ cacheHandle = fopen ($ cacheName, "w +");
fwrite ($ cacheHandle, $ newData);
fclose ($ cacheHandle);
$ isCache = FALSE;
}

Vi cacher resultatet av skriptet for bruk med videre anrop. Vi åpner bare filen i skrivemodus, dumper informasjonen der og lukker.

// Tid for å sende ut dataene.
if ($ ext == "css") (
header ("Innholdstype: tekst / css");
if ($ er bufret) (
echo "// Hentet fra hurtigbufferfilen. \ n";
}
) annet (
if ($ er bufret) (
ekko "";
}
}

Denne delen av manuset er litt modifisert slik at vi kan se resultatet av arbeidet. Hvis innholdet i filen har blitt hentet fra cachen, kan vi legge til en melding om det.

Prøver

Hvis vi bruker skriptet igjen, vil vi ikke se endringene før vi oppdaterer siden. Nedenfor vil vi se en inskripsjon om at filen er hentet fra cachen.

Konklusjon

Å raskt kunne legge til enkel caching i et hvilket som helst skript betyr at du er på vei i riktig retning. Et skript med caching vil redusere belastningen på enhver server betydelig.

Oppsummering

I denne opplæringen viste jeg deg flere praktiske og enkle måter å øke hastigheten på nettstedet ditt ved å bruke PHP.

Fra forfatteren: enhver utviklere med respekt for seg selv bekymrer seg for "skjebnen" til koden hans. Han prøver å gjøre applikasjonen så praktisk og rask som mulig og øke feiltoleransen. Men PHP-optimalisering vil ikke alltid tillate deg å nå disse høydene.

Ikke behandle hånden din hvis benet er halt!

Beklager den irske folkeaforismen! Men det gjenspeiler hele essensen av problemet i selve "bull's-eye". Oftere enn ikke vil kodeoptimalisering ikke tillate deg å forbedre ytelsen til det genererte skriptet eller ressursen. Og i tilfellet er alt ekstremt komplisert på grunn av det store antallet faktorer som du (som utvikler) rett og slett ikke kan påvirke.

Når det gjelder fenomenene utenfor kontroll, mener jeg hastigheten på Internett-tilkoblingen, belastningen på serveren, OS-innstillingene på klientmaskinen, kraften til brukerens PC-maskinvare. Du kan ikke påvirke alle disse komponentene. Og til slutt viser det seg at optimaliseringen av PHP-koden ikke vil gi et fullverdig resultat.

Hva gjenstår under nettutviklerens myndighet:

Serverinnstillinger - begrenset. Ved å angi parametere gjennom Apache-konfigurasjonsfilen httpd.conf kan du angi antall underordnede prosesser, tidsavbrudd for socket-tilkobling, utgangsbufferstørrelse for TCP/IP-tilkobling, inaktiv tid og annet.

Språkkjerneinnstillinger - gjennom parameterne spesifisert i php.ini-filen. Lar deg angi bufferverdier, endre maksimal skriptutførelsestid, feilhåndtering, loggbehandling og andre innstillinger.

PHP bildeoptimalisering - mer om det senere. Optimalisering av programkoden - lar deg "spare" ressurser og forbedre ytelsen.

For eksempel må du vite at ekko er raskere enn utskrift. Det er bedre å slå av visningen av feilmeldinger etter feilsøking for å spare ressurser. Bruk ekko i stedet for strengsammenkobling. Klasseobjekter og metoder () spiser opp mye minne.

Arbeid med bilder

Jeg er ikke en tilhenger av bildebehandling på serversiden. Det fører også til sløsing med dyrebare ressurser, som alltid er knappe på hosting. Det viser seg at ved å spare på en, kaster vi bort andre «reserver».

Mer optimalt er muligheten for å laste opp bilder til en tredjepartstjeneste, hvorfra de allerede er lastet opp i en optimalisert form til brukerens nettleser på en gitt adresse. Det finnes mange slike tjenester på nettet. Jeg vil bare nevne noen av dem: kraken.io, TinyPNG

Som du kan se, er kunnskap om PHP søkemotoroptimalisering også viktig for profesjonelle utviklere.

I tillegg har den egne innebygde verktøy for å «lyse opp» bilder. For eksempel funksjonen imagecopyresampled (). Det reduserer vekten av innholdet ved å prøve og endre størrelsen på bildet. Brukseksempel:

Hva annet kan du

Ikke glem å bruke klientsideoptimalisering med PHP. Til en viss grad kan serveren påvirke klientnettleseren gjennom Cache-Control, så vel som attributtene til denne overskriften: post-check, max-age og andre.

I tillegg lar Last-Modified og ETag-hodene deg kontrollere tilstanden til hurtigbufferen på klientmaskinen. De setter en unik identifikator for å endre hver fil. Takket være dette sender ikke serveren ressurser på nytt, men bare 304 statussvar.

I denne artikkelen tok vi ikke opp spørsmålet om optimalisering ved bruk av PHP FPM. Men for vurderingen er det nødvendig med en egen artikkel. Og det var alt for i dag. Til neste gang!