Web server za posluživanje statičkog sadržaja

[chmod744]

red_shrike kaže:

Zato što radim sa time svaki dan na netrivijalnim sustavima i znam da bi me brdo klijenata ubilo da im cashiram makar 1 sekundu stare podatke. Jer, recimo, možeš imati reverse proxy tipa haproxy za MYSQL, postgres, oracle, ili neku n-tu bazu, a onda ne želiš servirati stale podatke već raspoređuješ po m baza opterećenje koje jedna ne može podnijeti.

Sad sam ja glup i neiskusan pa moram pitat jesam ja dobro shvatio...

imaš dakle nekakav proxy kojem klijenti pristupaju izvana tražeći podatke iz baze X. Baza X se nalazi na N različitih DB servera.
Kako osiguravaš da su na svim DB serverima isti podaci (nisu "stale") u realnom vremenu?
Da li je svih N servera jednako opterećeno ili se "pale i opterećuju" po potrebi?
Što se dešava kad se podaci u bazi mijenjaju?

Ne moraš mi pisat imena rješenja, zanima me koncept rješenja više od "riješio sam to TIM i TIM sw-om".

Hvala unaprijed na odgovoru.

[Inspektor Dane]

Annatar kaže:

Zanimljivo da nginx i lighthttpd imaju približno iste performanse.

Bilo bi još zanimljivo usporediti i ovo:

https://github.com/nemasu/asmttpd

isprobaće se!
: dokon pop i jariće krsti :

[Inspektor Dane]

chmod744 kaže:

Sad sam ja glup i neiskusan pa moram pitat jesam ja dobro shvatio...

imaš dakle nekakav proxy kojem klijenti pristupaju izvana tražeći podatke iz baze X. Baza X se nalazi na N različitih DB servera.
Kako osiguravaš da su na svim DB serverima isti podaci (nisu "stale") u realnom vremenu?
Da li je svih N servera jednako opterećeno ili se "pale i opterećuju" po potrebi?
Što se dešava kad se podaci u bazi mijenjaju?

Ne moraš mi pisat imena rješenja, zanima me koncept rješenja više od "riješio sam to TIM i TIM sw-om".

Hvala unaprijed na odgovoru.

To je posao baze i dizajna baze u backendu, to nije poso proxy servera.
Bar tako ja vidin.

[chmod744]

sve 5... ali me zanima kako se taj non "stale" dio osigura na N servera u pozadini... replikacija baze među serverima a da nemaš "stale" i da si siguran da će proxy adresirat uvijek "najsvježije" podatke.

[Inspektor Dane]

chmod744 kaže:

sve 5... ali me zanima kako se taj non "stale" dio osigura na N servera u pozadini... replikacija baze među serverima a da nemaš "stale" i da si siguran da će proxy adresirat uvijek "najsvježije" podatke.

Otvori novu temu. replikacija baza, vjerujem da će ti se netko javit.

[logit]

http://www.hpl.hp.com/research/linux/httperf/

Ovo je alat kojim sam radio testiranje infrastrukture na faksu

[Inspektor Dane]

chmod744 kaže:

ne kužim zašto si "analan". Ako misliš da sam offtopic imaš alate za to nagradit.

Nije mi problem otvorit novu temu o replikaciji baza. Više me zanima kako će to "glupi" web proxy znat da upite treba distribuirat na nešto što je zapravo N DB servera bez da ima nekakve informacije koliko je N, gdje se nalaze i koliko su svježi podaci na serverima iz skupa [1...N].

Ili ako hoćeš, evo pitanje i tebi kao otvaraču teme - što kad taj tvoj statički sadržaj bude "napadnut" od klijenata većom silinom no što ti tvoj server može izdržat pa budeš morao balansirat opterećenje?

analan sam jer sam bijo zlostavljan kao mali, pa sam postao inženjer.
fokusiramo se na jednu temu, nemoj torokat okolo.
ne zajebavaj za moderiranje.

[red_shrike]

Web proxy ne servira DB podatke, već to radi tcp proxy, i itekako zna koliko ima servisa jer ih sam dodaš. Isto tako, reversporxy tipa haproxy ima i mehinzam provjere podataka (recimo za web možeš napraviti test da svakih 1 sekunde potraži neki string i ako ga nema da isključi taj backend).

Servanje stale podataka je stvar replikacije baze (znači da ovisi o specifičnoj bazi, host serverima, mrežnoj latenciji, kodu,...), a ne proxy servera. Dakle, to je samo pitanje koliko ti se brzo izvršava replikacija servera sa mastera na slavove (i to nije i ne može biti instantno bez obzira koja baza i sustav bili, no riječ je o par milisekund (možda 10-20 ms) tipično za dobar sustav. Jedan tipični scenarij ti je da na reversporxy imaš odvojene interfejse za write i za read. Tako da ti write ide na jedan backend (kojih tipično u web okruženju ima manje), a read na drugi interfejs. Kako su haproxyu recimo poznati svi backendi (jer ih sam uneseš), onda ti imaš izbor kako češ proxyat na njih requeste. To može biti jednaka podjela, prelijevanje (kada se jedan zapuni ide na drugi), random, itd.

Zašto se to radi? Zato jer jedan server ne može nužno pdonijeti opterećenje. Ne može ih možda ni 2-3, pa ti onda fino nadoštukaš servera koliko ti treba. To je radikalno jefitnije od kupovanja super masivnih servera sa 300-400+ jezgri da odradi tako nešto. Pazi, ti možeš imati toliko requesta da ti ni direktno servanje iz RAM-a nije dovoljno brzo na dual hexacure sustavu sa multithreadingom i >100 GB RAM-a, a klijent ima problem ako su podatci stariji od 1 sekunde. Očito, cashing je potpuno neprihvatljiv jer će dotični servati stvari stare satima, a možda i danima. Ovo ne vrijedi samo za baze, već i za web.

No ukratko, monitoring sustava, replikacija i slično su stvar za odvojenu temu. Ono što ja pokšavam ovdje ukazati na to je da cache i proxy nisu ista stvar. grogo je vidio fino kako mu varnish lijepo radi kao lokalni cashe, i ako je sve na jednom stroju baš i ne radi neki proxying.

[grogo bolger]

Annatar kaže:

Zanimljivo da nginx i lighthttpd imaju približno iste performanse.

Bilo bi još zanimljivo usporediti i ovo:

https://github.com/nemasu/asmttpd

heh morao sam podić 64 bitni vm (nisam imo' )

elem evo test za asmttpd

[root@localhost web_root]# ab -n 100000 -c 100 http://192.168.0.17/032012.gif
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.0.17 (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests

10s bolje od ngixna i lighttpd-a.
Fora, išao sam čitat source kod...ajme
Server Software: asmttpd/0.3
Server Hostname: 192.168.0.17
Server Port: 80

Document Path: /032012.gif
Document Length: 95688 bytes

Concurrency Level: 100
Time taken for tests: 21.330 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 9579800000 bytes
HTML transferred: 9568800000 bytes
Requests per second: 4688.31 [#/sec] (mean)
Time per request: 21.330 [ms] (mean)
Time per request: 0.213 [ms] (mean, across all concurrent requests)
Transfer rate: 438603.82 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 8 1.5 7 19
Processing: 4 14 2.2 13 37
Waiting: 0 5 2.5 5 18
Total: 5 21 2.6 20 41

Percentage of the requests served within a certain time (ms)
50% 20
66% 21
75% 22
80% 22
90% 24
95% 27
98% 30
99% 33
100% 41 (longest request)

10s brži..opa.

[red_shrike]

Inače je recimo fora kod nginx-a da se može raditi microcashing. Znači, rokneš da ti cashira par sekundi doslovno, tako da ti recimo kada dođe navala na requeste (ako ti odjednom neki sajt postane super popularan ili kod testiranja) onda to serva drito iz cachea, a inače ne. Onda možeš recimo vidjeti da ti server handla 7k requesta bez beda

[grogo bolger]

Inače kako se sa apachiem najbolje osjećam krenio sam čačkat sa

http://httpd.apache.org/docs/2.2/caching.html

npr.

MMapFile /usr/local/apache2/htdocs/index.html
iz
http://httpd.apache.org/docs/2.2/mod...ile_cache.html

pomoću kojeg narokaš sadržaj foldera u memoriju...
ali na mom centosu nije bilo tog modula...a nije mi se dalo kompajlirat.

[Annatar]

Time per request: 21.330 [ms] (mean)
Time per request: 0.213 [ms] (mean, across all concurrent requests)
Transfer rate: 438603.82 [Kbytes/sec] received

Iii naravno, web server napisan ručno v assembleru je kompletno pomel konkurenciju... servisiral si 10 sekundi brže duplo više sadržaja od sljedećeg po redu najbržeg web servera.

Sad neka još samo negdo pisne o tome kak optimizirajući compileri generiraju bolji / brži kod od ručno napisanog assemblera...

Kod zgledi čist' okay, kulike sem imal prilike vidjeti. Kaj mu fali, osim kaj nije portabilan?

[Annatar]

grogo bolger kaže:

ali na mom centosu nije bilo tog modula...a nije mi se dalo kompajlirat.

Eee jebiga, nikad ti se niš ne da!

Najdi .srpm, instaliraj rpm-build, napravi si ~/.rpmmacros (imaš primjer na Linux (i o njemu)), i neka ti rpm-build to izkompilira. A usput odmah završiš i z RPM paketom za deployment v produkciju.

[grogo bolger]

Annatar kaže:

Eee jebiga, nikad ti se niš ne da!

Najdi .srpm, instaliraj rpm-build, napravi si ~/.rpmmacros (imaš primjer na Linux (i o njemu)), i neka ti rpm-build to izkompilira. A usput odmah završiš i z RPM paketom za deployment v produkciju.

a daajj, pa vidiš da kenjam..probat ću zanima me taj feature od apachia

nisam kompetentan ocjenjivat taj asm kod, jer stvarno osim što sam na fakultetu drljio po z-80 asmu... zašto nije prenesiv?

bi li radio kod tebe na solarisu?

[UrchinStar47]

http://nginx.com/blog/why-netflix-ch...rt-of-its-cdn/

Clanak on Netflixovom rjesenju. Nek se nadje.

[jKicker]

Annatar kaže:

Iii naravno, web server napisan ručno v assembleru je kompletno pomel konkurenciju... servisiral si 10 sekundi brže duplo više sadržaja od sljedećeg po redu najbržeg web servera.

Sad neka još samo negdo pisne o tome kak optimizirajući compileri generiraju bolji / brži kod od ručno napisanog assemblera...

Kod zgledi čist' okay, kulike sem imal prilike vidjeti. Kaj mu fali, osim kaj nije portabilan?

Mislim da je ovo ipak prenapadan zakljucak na temelju jednog benchmarka gdje se usporeduju punokrvni web serveri i jedan minimalan gledajuci po kodu.

No i meni je interesantna razlika, a ja uvijek volim testirati jer i sam koristim za statikcki sadrzaj uvijek neki "svoj" pa bih te grogo molio ako mozes testirati ovaj web server

to je server 2 iz boost primjera (github) koji bi recimo odgovarao ovom u asembleru, skompajliran staticki sa

c++ main.cpp connection.cpp io_service_pool.cpp   mime_types.cpp reply.cpp request_handler.cpp  request_parser.cpp server.cpp  -o server -lboost_thread -lboost_system -lpthread -O3 -static

./server 
Usage: http_server <address> <port> <threads> <doc_root>
  For IPv4, try:
    receiver 0.0.0.0 80 1 .
  For IPv6, try:
    receiver 0::0 80 1 .

[Annatar]

jKicker kaže:

Mislim da je ovo ipak prenapadan zakljucak na temelju jednog benchmarka gdje se usporeduju punokrvni web serveri i jedan minimalan gledajuci po kodu.

Nisu uspoređivane mogućnosti, nego PERFORMANSE.

A kaj se veličine tiče, veličina koda indicira njegovu kvalitetu: kaj je kod manji, to znači da je veće kvalitete. Ocjenjivanje nekog programa po veličini njegovog koda, odnosno po logici da puno koda znači bolji program je posljedica ispiranja mozga bloatwareom (i nedostatkom uskustva v natjecanju z ostalima v pisanju optimiziranih programa). Žalosno. To se mora promijeniti, pod hitno!!!

c++ main.cpp connection.cpp io_service_pool.cpp   mime_types.cpp reply.cpp request_handler.cpp  request_parser.cpp server.cpp  -o server -lboost_thread -lboost_system -lpthread -O3 -static

Zakaj kompilirati statički, kaj točno misliš da buš z tim dobil?

[jKicker]

Annatar kaže:

Nisu uspoređivane mogućnosti, nego PERFORMANSE.

Pa mislim da nam je svima poznato da cim veci softwer sa vecim mogucnostima gdje se ne pridaje pozornost samo jednoj stvari, performanse na jednoj stvari padaju.

Annatar kaže:

Zakaj kompilirati statički, kaj točno misliš da buš z tim dobil?

Ponekad ne mozes shvatiti 'sitno', znaci zato da to moze skinuti i pokrenuti pa da ne instalirava sam boost lib i kompajlira jer je vjerojatno kratak sa vremenom ko vecina pa mu zelim izaci u susret jer sve imam spremno?

Ako rezultati budu korisni, moze sam kopmajlirati, dodati jos i -march=native pa da vidimo razliku. To mene interesira, testovi, razvoj...ne naklapanja.

I Annatar, nekad si bio koristan sa svojim komentarima i volio sam te citati, sad si bas naporan, pod hitno trebas hobi nabaviti

[red_shrike]

A same performanse bez mogućnosti nisu baš korisne specijalno to je ko da imaš auto koji troši decilitar na 100 km i ide 500 km/h, ali može ići samo ravno i nikako drugačije. I da, statička kompilacija daje bolju portabilnost.

[Annatar]

red_shrike kaže:

A same performanse bez mogućnosti nisu baš korisne specijalno to je ko da imaš auto koji troši decilitar na 100 km i ide 500 km/h, ali može ići samo ravno i nikako drugačije.

Ispravi me ak griješim, ali tema je statičko posluživanje sadržaja. Kakve ti vse mogućnosti za HTTP GET zahtjev još trebaju?

Nemojmo nepotrebno komplicirati.

I da, statička kompilacija daje bolju portabilnost.

...I jedno faktor 10 x veće programe, jer se kompletni objekti iz svih biblioteka kojima se linka fuzioniraju u finalni izvršni program, a "bolju portabilnost", možeš zaboraviti jer se glibc i dalje linka dinamički, osim ako nisi superheroj (III) koji sam još k tome i statički kompilira glibc da bi dobil glibc.a za 100% statički link.

http://stackoverflow.com/questions/3...inking-is-dead

Prevedeno na hrvatski: da bi taj prekompilirani web server delal kod groge, jKicker i grogo bolger bi morali vrtiti identičnu verziju OS-a, ili u optimističnom slučaju, grogo bolger bi moral imati noviju, ali nije garantirano da bi to delalo. Čak ni statično kompilirano, zbog dinamičkog linkanja glibc-a. Ali možete probati... možda vam se posreći.

Napomenimo još samo da na UNIX sustavima to uopće nije tema. Postoji samo jedan jedini scenario gdje statičko linkanje ima smisla, a ovaj nije taj.