Vi har laget en mobil applikasjon som leverer dynamiske bilder. I denne sammenheng trenger vi et setup som takler 1000 request per sekund på bilder med størelse rundt 0.2 MB.

Vi har vurdert tredjeparts tjenester som amazon s3, men sammenlignet med vp fra digitalocean.com er vp'en mye billigere. Vi loaded en nginx server med 7500 over 30 sec (250 i sekundet) og resultet ble slik: http://i.stack.imgur.com/n6OdT.png.

Resultatet var ved å benytte php, x-accel og redis for å cache content så en slipper å hente fra disk hver gang. Vi vurderer å kjøre dobbel nginx server med dette setupet der vi har en loadbalancer forran. Problemet er at dette vil bare kunne takle rundt 500 r/s med dårlig respnose time. Har dere noen forslag til hva vi kan gjøre ?

Er bildene lagret i Redis eller på disk?
Hva skjer med en ucachet request (bildet ligger på disk)? (Typisk nginx->fastcgi->php->filsystem)
Hva skjer med en cachet request (bildet ligger i Redis)? (Ideelt sett nginx->redis).
Er cachen varmet opp når dere kjører load-testing? (alle bilder i redis)

* Kjør noen benchmarks som ser på forskjellen mellom request som går direkte til redis, og de som går innom Fastcgi/PHP. Implementer eventuelt dette om det mangler.
* Er det mulig å fikse slik at bildene ikke er dynamiske?
* Er det nok minne til å holde alle bildene i cache?
* Prøv en kraftigere server.


[COLOR="Gray"](PS: Er dere Gobi?)
[/COLOR]

1 million requests i sekundet, og du vurderer å køyre det på billigaste vpsen du finn?

Du er sprøyte gal.

1M*0.2MB=195GB/sekund.

Edit:
Det er 1K request, ikke 1000k r/s

Bildene er lagret på disk, men vi prøver ut redis slik at de bildene som blir spurt om ofte ikke trenger å leses fra disk, men heller fra RAM.
Det vil nok gå nginx->fastcgi->php->filsystem (er ikke helt sikker, men bruker nginx med php og headeren x-accel)
cachet request blir dessverre nginx->Redis->php (så tjener ikke så mye på det)
Det er varmet opp der vi kjører et gitt utvalg av bilder. Skal sies at redis/ikke redis har ikke så mye å si.
Har vurdert å implementere varnish og cashe hvert bilde response, men vet ikke om dette ville vært effektivt?


Bildene blir lastet opp av brukeren og er veldig dynamiske, er Gobi ja.


Her er php koden:

Og hvorfor bruker dere ikke en tjeneste som Azure Blob Storage?
Returner image url til appen, appen tar seg av lastingen fra azure.

Azure blob storage 3T transfer = 248,11/MO DO = 20 / mo

Mulig jeg overser noe i beskrivelsen, men hvilken funksjon har fastcgi og PHP i dette oppsettet? Kan ikke nginx servere filene rett fra disk? Og ja, varnish vil nok kunne hjelpe en god del.

Om jeg ikke tenker helt feil så blir 1000/req/sec a 0.2MB ca. 200MB / sec eller drøyt 2Gbit/sec. Eller rundt 500TB overføring/mnd. (forbehold om avrundinger og regnefeil).

Om du klarer å trykke det ut av en VPS til 20 USD/mnd over tid (dvs at du ikke blir stengt ned el.l.) så skal du få en hundrings av meg.

Først og fremst så tror jeg ikke et sekund på at dere kommer til å bevege dere opp mot 1kreq/s, det er helt fantasi. Ikke halvparten av det engang, regn litt på det så ser du fort hvorfor. Vi snakker titalls millioner requests om dagen.

Du er nødt å forklare oss hvorfor disse bildene må bli generert on the fly kontinuerlig. Forklaringen din på bruk av FastCGI gir absolutt ingen mening, Nginx er på ingen måte "primært laget for proxying", det er kanskje den mest avanserte webserveren som finnes.

Hvis den lar seg caches er det helt problemfritt å levere den mengden trafikk, gitt at du har båndbredden til det. Du er mer eller mindre bare begrenset av båndbredde når det kommer til f.eks. Varnish. Men en VPS vil ikke gi deg den båndbredden, til og med Amazon vil ha deg til å gjøre "pre-warming" av Elastic LoadBalancers hvis du skal dytte så store mengder trafikk.

Finn en norsk isp som normalt sett har privatkunder og lei plass til egen boks der. Dei har normalt sett masse ledig utgående trafikk tilgjengelig. Men noen k må du basere deg på å betale.

Jeg er ganske sikker på at Igor Sysoev ikke vil stå inne for den forklaringen. Det blir flisespikkeri, men Nginx er langt mer enn bare en reverse proxy server, hvis det var tilfellet så hadde den vært mer eller mindre vært som Varnish, bare enda mer begrenset når det kom til håndtering av caching. Og med den tankegangen så vil også Apache2 være en reverse proxy, hadde det ikke vært for mod_php. Man har bare innsett problemet med å bundle applikasjonskode inn i webserveren, det gjør den unødvendig treg når man ikke skal bruke denne funksjonaliteten. Det er en konseptuell endring i hvordan vi snakker om webserver og applikasjonsserver. Det er i samme gate som å omtale Varnish som en webserver, det forvirrer folk.

Hvis filene kan leses rett fra disk og serveres direkte så vil du ikke oppnå noe særlig ved å sette Varnish forran Nginx. Moderne maskiner bruker virtual memory og har mange nivåer av read caching på filsystemet. For alle praktiske formål er det ikke mye forskjell å bruke malloc eller file som storage engine på Varnish, med mindre man snakker om optimalisering på et langt høyere nivå enn jeg tror dere trenger å tenke på enda.

Dere vil være begrenset av båndbredden på denne last balansereren, så jeg er ikke helt sikker på hva dere oppnår med å gjøre det, med mindre det er fordi det krever mye prosessorkraft å generere disse bildene, noe du har konsekvent utelate å skrive noe som helst om. Generelt så er det umulig å komme med anbefalinger og råd når du er så tilbakeholden med hva du faktisk ønsker å oppnå.

En kompis dro 275kreq/s gjennom Varnish på sin maskin. Tall uten substans og mening er ganske poengløst.

Husk å slå på gzip ratio 5 eller 6 i nginx for de fleste normale maskiner. gzip er blandt de mer effektfulle optimaliseringene nginx kan gjøre mot nettleser.

Det er alltid greit å sjekke hvilken trafikk som faktisk er der med wireshark.

Husk å benytte loopback interface mot undertjenester som kjører på samme node; da denne aktiviteten garantert ikke vil benytte et nettverkskort's båndbredde.

Sjekk med ethtool at du faktisk benytter 100, 1000 eller 10000 eller hva det nå enn er som er høyeste kapasitet på det aktuelle nettverkskortet/ene.

Tweak også iostat til å redusere flaskehalser.

Eg er veldig nysjerrig på korleis du vil nytte wireshark til dette føremålet. Kan du utdjupe?

Igjen - ab vil gi deg samme informasjonen, utan alt analysearbeidet.
Du får total, du får nyttelasta og du får timing. Det er mykje arbeid å få tak i med wireshark/tcpdump, og eg vil påstå at dei er feil verkty. Det er protokollanalyse, ikkje trafikkanalyse-verkty. Kor mykje trafikk du får er trivielt å sette seg ned og rekne ut, med papir og blyant.

Når det gjeld kompresjon av bilete, så funker ikkje gzip, bzip2 eller andre liknande ting. Auka jpeg kompresjon funker, men går utover kvalitet. I tillegg er det nyttig å finne ut kva som er bottleneck - og det gjer en ved å sjå på lasta på serveren, typisk io-bruk, cpubruk og nettverksbruk.

Forslaga dine i denne tråden har utan unntak vore på viddene.

Wat.

Du mangler helt elementær forståelse for hvordan et filsystem opererer. Når et bilde lastes inn fra filsystemet blir det liggende i virtual memory, der vil operativsystemet selv sørge for at de mest benyttede filene ligger raskest tilgjengelig. Når du ser på minnebruken din, se på "buffers and cache", det er akkurat dette. Det er mulig å optimalisere dette, men her er det mange fallgruver.

ab, eller apache benchmark er bare et verktøy for å gjøre parallelle spørringer mot en webserver. Du kan gjøre det mot alt som snakker HTTP/1.1. Et annet alternativ er httperf.

Øke kapasiteten er ikke et enkelt banalt grep som ingen tenker på. Det er mer eller mindre det eneste grepet folk gjør. Og strengt tatt stort sett det eneste grepet folk bør gjøre, da folk flest ikke innehar den kompetansen til å optimalisere uten at det går utover f.eks. dataintegritet.

Kan du forresten utbrodere litt hva du mener med å optimalisere iostat? Eller er det nok en buzzword dumping fra din side, siden du konsekvent utelater å forklare hva du mener med ting som "bedre datamodeller" eller "sjekke hvilken trafikk som faktisk er der med wireshark".

Praktisk eksempel IPFS implementasjon: https://www.youtube.com/watch?v=skMTdSEaCtA&t=270

Bortsett fra at matematikken hans er helt whack. Hvis du skal sende en 1MB stor fil, gjennom 8 hops, så regner du det ikke som 8MB overført data.

Og man bruker CDN med en kombinasjon av anycast og GeoDNS. Så eksemplet hans med et Facebook-bilde blir helt feil, da bildet du laster ned når du aksesserer Facebook mest sannsynlig er fra en maskin inni eller tett opp mot din egen ISP sitt kjernenett.

IPFS er bare en morsom hack som har svært få praktiske formål. Og hvis du bryr deg om latency så har du virkelig ikke lyst å være avhengig av JavaScript performance i nettleseren til Gunnlaug på 75 år som har maskinen full av virus.