Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  5 1351
Hei!

Har en server kjørende som webserver med WAMP. Foreløpig en Windows 7 installasjon. Denne hoster da en web-applikasjon som foreløpig mottar ca 1 request i sekundet. Ikke snakk om virkelige brukere selvsagt, er datamaskiner som snakker med hverandre. Men vurderer å gå over til Linux og LAMP. Bedre ytelse på Linux?

Uansett, vanligvis ligger responstiden på mellom 10-100 ms. Det er da snakk om litt PHP-kode som kjøres, hente litt data fra MySQL og kanskje et par bilder samt enkel HTML og CSS. Vi har kjørt et par stresstester på den med veldig mange forespørsler hvert sekund, og da dropper plutselig responstiden til opptil flere sekunder. For denne tjenesten skal nemlig utvides til å takle 10-20 request i sekunder, og mulig streaming av videoklipp.

Spørsmålet er hvordan det er best å skalere en webserver-løsning? Hva er som regel det svakeste punktet?

Foreløpig ser oppsettet slik ut:

* Nettlinje: 100/100 mbit
* Brannmur: Microsoft TMG (server 2008 R2)
* Server: Win 7 med WAMP virtualisert på ESXi med godt med CPU og RAM

Men har vurdert noen mulige måter å skalere på:

http://bildr.no/thumb/1043577.jpeg

Har prøvd å googlet litt rundt, men har fått få konkrete løsninger. Derfor spør jeg her om noen har erfaring med slike systemer, og/eller linker til gode ressurser.
Vil tippe det svake punktet her er php-koden og databasen din.
Har du gjort noen grep for å optimalisere de?

Det kan jo såklart være uheldige konfigurasjoner i tillegg, men om dere ikke har gjort stort utover standard er det neppe tilfellet.

En moderne flerkjerneprosessor burde ikke ha store problemer med å klare noen titalls requests i sekundet.
Sist endret av Goophy; 5. desember 2011 kl. 11:20.
Goophy: Har gått gjennom PHP-koden og databasen, så tror denne skal være ganske grei. Det som derimot stresser stress-testen mest, var når vi kjørte den mot Wiki-sidene som lå på serveren. Men vet ikke hvor avansert det er bygget opp i grunn.

Men skal prøve å gå litt mer nøye gjennom koden, og gå gjennom konfigurasjonen i Apache/PHP
Er det et nøyaktig klokkeslett, ti tusen realtime søkeresultater eller en ukentlig timeliste som skal vises; hvilken type og mengde data hentes ut fra databasen? Er dette data som krever kontinuerlig oppdatering? Jeg ser du setter opp forslag til cache-server/løsning, så da må jo det være noe du tenker kan mellomlagres.

Caching i PHP er ikke særlig komplisert, du kan f. eks benytte deg av direkte buffer-kontrollering (output buffering), eller et veletablert bibliotek. Memcache er et av de mest populære, men til prosjekter med lavere kompleksitet vil jeg anbefale Cache_Lite.

Sitat av Toak Vis innlegg
Goophy: Har gått gjennom PHP-koden og databasen, så tror denne skal være ganske grei.
Vis hele sitatet...
Hvordan har du gått igjennom PHP-koden? Hvilke metoder har du brukt for å kalkulere utførende tidsbruk, databaseload, request tider til Apache samt kartlegge eventuelle optimaliseringstiltak?
Dropp caching i php. Hopp over til linux, eventuelt sett opp en server i front med linux og installer varnish. Kan også hjelpe med varnish på samme server som apache, bare at da må apache lytte på en annen port enn 80.

https://www.varnish-cache.org/

Her kan sett sette opp caching og lastbalansering hvis du har to backendservere.

Tenk igjennom om du stort sett har statisk innhold (Samme innholdet leveres til mange)(Varnish, memcache). Da bør du cache. Dersom du hele tiden leverer forskjellig innhold på hver request bør du satse på lastbalansering. (Linux: Varnish, Pound, eller perlbal).

Dersom du har tid til det vil jeg anbefale deg å sette deg inn i varnish (De fleste av landets nettaviser bruker dette). Hvis ikke er pound relativt enkelt å sette opp (bare lastbalansering).
Varnish er fint og vel, men det hjelper null på dårlig PHP performance. Det er mange tilfeller hvor man ikke kan servere cachet side, og da er det ganske kjipt og ytelsen er dårlig, spesielt hvis du har dårlig hit-ratio. Ytelsen din vil også yte eksponentielt hvis backends yter godt.

I korte trekk, sjekk koden din med en profiler og installer en form for opcode caching, slik som APC eller XCache. Det vil gi en ganske drastisk ytelsesforbedring. Jeg foretrekker APC, uten å ha noe grunnlag for det, utover at det ... fungerer...

Hvis applikasjonen din har støtte for det kan du spare ganske mange databasekall ved å bruke memcache, som blir et lag mellom databasen og applikasjonen, men det lever i minnet. Merk at memcache kommer i to versjoner, en som standalone og en som nettverks daemon, har man flere webservere er det vanlig å bruke delt cache.

Du skal ha en bra aktiv side for at en normalt godt speccet server skal knele på grunn av trykk, og 10-20 req/s er ikke akkurat enormt, Antar forøvrig at det er under peak load. Hvilken applikasjon og hvilke parametere brukte dere til loadtest? Når vi snakker responstid, snakker vi ICMP ping eller prosessering av PHP?

(TL; DR: Fiks ytelsesproblemet i applikasjonen, sett en boks med varnish (versjon 3 for streaming, kan være kjekt hvis dere har et stort video-arkiv), den fungerer som en lastbalanserer og cache for statisk innhold. Webserverene bør settes opp slik at de er stateless og databasen skilles ut slik at man har kontroll på bruken; hvis man har litt vel optimistisk Apache2-settings kan det fort gjøre at MySQL blir uresponsiv fordi det ikke er mer tilgjengelig minne, etc...)

Det du kaller "statisk lastbalansering" er forøvrig galskap, for å fjerne en server fra listen må du vente til TTL på DNS, da er det bedre å bruke Varnish til å gjøre health checks og eventuelt ta de ut av listen hvis de er uresponsive eller kaster ut 500-errors o.l.
Sist endret av Deezire; 10. desember 2011 kl. 01:31.