Matt Dunning Drop mål

PHP er et allestedsnærværende sprog, der blandt andet gør det muligt for en server at gengive en webside på anmodning og servere den resulterende HTML til klienten.

For eksempel kan den serverede side være forskellig for forskellige klienter, og serveren "bygger" HTML pr. Anmodning.

Jeg antager, at dette generelt er praktisk øjeblikkeligt. Men kan dette være et problem for mere komplekse websider? (Eksempel: hvis serveren ved at gengive en side skal have adgang til en tredjepartstjeneste, der muligvis har sin egen latenstid)

I bekræftende fald, hvilke løsninger kan vi implementere for at undgå dette problem?

  • Er adgang til tredjepartsressourcer et reelt problem? Du siger "for eksempel", er dette dit ønske? Der er altid latensproblemer forbundet med at få adgang til ressourcer, ikke på din egen server. Dette er dog ikke et sprogproblem. PHP er det mest populære sprog til webudvikling, men ikke det eneste.
  • Ja dette er mit ønske (jeg forsøgte at gøre mit spørgsmål mere generelt og nyttigt for fremtidige mennesker.)
  • PHP er fint og nemt at bruge. Især er det godt at hente data fra andre ressourcer. Meget afhænger dog af ressourcen, hastigheden, pålideligheden, konsistensen osv. Jeg har altid hentet eksterne ressourcer uafhængigt af brugerinput eller anmodning, men det er kun mig. Jeg fandt det en mulighed for at kompensere for problemer, der måtte opstå, men i tilfælde er det måske ikke engang nødvendigt. Skål !!
  • "Jeg antager, at dette generelt er praktisk øjeblikkeligt" - Det er sjældent nogensinde så hurtigt. Det er meget almindeligt, at sider med PHP-drift tager mange sekunder at behandle en anmodning. Det skyldes normalt travle servere og et stort antal databaseforespørgsler, der bruges til at oprette sider.

Er det tid, det tager PHP at gengive en side og servere den til klienten, nogensinde et problem?

Uden at være færdig med at læse selve dit spørgsmål, har jeg det perfekte svar.

JA

Dette skyldes, at al den behandlingstid, der kræves for at præsentere siden for brugeren fra det øjeblik, brugeren rammer enter-tasten (fra at indtaste en URL eller klikke på et link) er af største betydning. Det er så vigtigt, at hvis tiden er for lang, vil gæsten tro, at webstedet er brudt.

Processen kan forværres, når mange mennesker opretter forbindelse til serveren på én gang, fordi computeren bliver nødt til at håndtere hver anmodning sammen med behandlingen af ​​hver anmodning, og hvis der er alt for mange mennesker, der opretter forbindelse, kan nogle mennesker opleve forsinkelser før nogen en del af deres anmodning behandles. Dette afhænger af serverens processorkraft.

Der er et udtryk, der er værdifuldt for dig. Det hedder "Time to First Byte". Det betyder, hvor lang tid det tager for folk at se nogen del af siden, fra de først beder om det. webpagetest.org kan måle denne værdi for dig, når du kører et websted gennem dem. Du ønsker at holde værdien så lille som muligt (ca. 20 til 50 ms, hvis sider serveres lokalt, eller op til 1 ms, hvis sider serveres til et langt væk sted med dårlig internetforbindelse).

Nu hvis du leder efter en måde, hvorpå den tid, det tager for PHP-processoren at gengive en side, ikke er et problem, kan du enten:

  1. Ditch PHP og brug et andet scriptsprog på serversiden, men så bliver du nødt til at faktorere behandlingstiden for dette sprog.

  2. Se på andre faktorer, der kan forårsage betydelige gengivelsestider, som f.eks. Javascriptet, der bruges på nutidens websteder for at ændre hele udseendet og / eller funktionaliteten på webstedet.

Selvom du tager en af ​​de ovennævnte to muligheder, vil du stadig faktorere den tid, serveren behandler anmodninger som en helhed, selvom det betyder, at PHP og / eller ethvert andet serverscript-sprog, der bruges til at behandle anmodningerne om gæster.

PHP kan faktisk være langsom til tider afhængigt af hvilken slags PHP der bruges på serversiden.

Computere kan beregne og gengive data meget hurtigt, men der kan være ventetid, hvis serverhastigheden ikke er hurtig nok til øjeblikkeligt at beregne anmodningen.

Dette kan ske, når mængden af ​​lagrede variabler bruger en betydelig mængde RAM, eller når der simpelthen er for mange processer og anmodninger om, at CPU'en kan håndtere al information.

Det er også meget almindeligt, at PHP-sprog bruger forskellige file_get_content og file_put_content anmodninger. Og PHP-scriptet kan ikke fortsætte med at behandle yderligere kode, før serveren leverer eller modtager file_get_content eller file_put_content-anmodningen. Med andre ord, hvis det tager 2 sekunder at indlæse en side gennem file_get_content, vil der være yderligere 2 sekunder, der kræves for at dit websted skal gengives og indlæses.

Dette var et problem ... for 20 år siden.

Sikker på, at hvis du har andre vigtige problemer såsom dårligt skrevet php-kode eller en server, der har nogle alvorlige problemer med load- og ressourcestyring, vil det i sidste ende være problematisk og manifestere sig som "langsom loading php-sider". Men det samme ville være tilfældet, hvis du brugte scripting på serversiden eller opkald til databaser; eller virkelig serverer ALT under disse forhold.

Jeg koder udelukkende datadrevne php-websider på alt lige nu; og php-kompilering og udførelse er ALDRIG et problem eller afmatning for mig.

Indlæsning af store ressourcer som jquery, css-biblioteker, bootstrap osv. Kan muligvis være et problem. Men hvis du indlæser dem ved hjælp af async (når det er muligt), fortsætter din side med at indlæse og venter heller ikke på dem. Og de vil sandsynligvis blive cachelagret efter første gang de er indlæst, så nul tid efter det også.

Kort sagt: Selvom der er mange ting at bekymre sig om, når du designer dit websted og brugergrænseflade, er korrekt skrevet PHP-kode ikke en af ​​dem.

  • Der er en grund til, at højtydende websteder ikke bruger PHP og andre programmeringssprog til script-typen. Efterhånden som præstationskravene stiger, såsom et øget antal brugere, bliver PHP et problem, hvor yderligere serverforbedringer skal foretages eller en ændring i det anvendte sprog.
  • Facebook framework Hack er bygget på PHP. Foreslår du, at de ikke er et "højtydende" site? Xenforo-websteder kører også alle på Zend-rammen, også bygget på PHP. Fra og med version 5-5.5 blev PHP meget mere robust sprog, hvilket muliggør grænseflade.
  • Jeg har ikke set nogen benchmarktest i de sidste 5+ år, der tyder på, at PHP er "langsom" sammenlignet med andre SS-programmeringssprog. Eller at det generelt er flaskehalsen i problemer med ydeevne relateret til høj trafik på et websted, når det implementeres korrekt. Hvis du har nogle kilder, bedes du citere dem her, da jeg gerne vil se dem.
  • Kast nok hardware på et sprog, og det vises hurtigt for alle. Hvis du vil være fornuftig, skal du bruge et sprog, der ikke har brug for så meget hardware for at vises hurtigt. Og intet fortolket sprog, såsom PHP, kan sammenlignes med et kompileret sprog.
  • Jeg vil tilføje, men har ikke tid, at Facebook har en compiler til at gøre PHP til native-kode og er afhængig af C / C ++ på backend sammen med andre sprog. Hurtig søgning Jeg kunne ikke finde noget, men en tidligere ingeniør sagde, at de kun bruger PHP, fordi der stadig er ældre kode, der ligger rundt. Ny kode er mere sandsynligt ikke skrevet i PHP eller er kompileret på forhånd.

arbejdet for dig: Charles Robertson | Ønsker du at kontakte os?

nyttige oplysninger