DORS 2014 Radionica

"Ekstremna optimizacija servera"

Ivan Voras

Ukratko...

Manje "radionica" a vie "razgovor"

Nema velikih mudrosti, veina sistemaa e sve ovo ve sami nauiti u praksi (kad-tad)

"Common sense"

"Best practices"

"goal-setting" web stack

I jedna velika tajna...

Jedna velika tajna

"Da server bude brz, treba raditi to manje"

You can quote me on that :D

Izbor hardvera

Oko CPU-a se ne treba previe brinutiOsim ako se koristi Django (Python) ili RoR (Ruby) :D

Meu ostalim i zbog specijaliziranog hardvera:Mrene kartice s TSO, RSS, multi-queue

AES u CPU-u

DMA, VT-d, IOMMU

ak i bez dodatnog application-specific hardvera (ASIC, anyone?)pitanje je samo to se mjeri

Objasniti to je

Statiki HTTP - trivijala

Najlaki sluaj, nema "skriptnih jezika", danas je bilo koji novi hardver prebrz za mreu (mrea je bottleneck)

Raspberry Pi / 700 MHz (~~350 MHz Pentium 2)400-450 pages/s (3.5 KiB, lighttpd)

Moderni hardware:> 10.000 pages/s/(CPU+NIC) (3.5 KiB, nginx)

ALI: Gigabitno suelje se zasiti s jednom jezgrom

Vrste HTTP servera

Pre-forked jo uvijek default na velikoj veini trenutno koritenih distribucija LinuxaPraktiki nikad se bi smio koristiti

Pure event-based: THTTP, Lighttpd, stari nginx

Threaded: uglavnom Apache, Java

Events+threads, events+processes: novi Apache, novi nginxNajbolje od oba svijeta, uvijek treba koristiti

Loiji

Bolji

IIS je tu negdje

HTTPS (SSL / TLS)

Enkripcija je zahtjevna za CPU (d'oh!)

Nije dobro koristiti single-threaded event-based HTTP servere (kao lighttpd)nginx za efikasni SSL mora imati vie workera

Utjecaj izbora cipheraNajbolji izbor za sigurnost:
ECDHE-RSA-AES256-GCM-SHA384 800 pages/s

Najbri izbor:
RC4-SHA 1200 pages/s

Objasniti zato

SW RC4: 1.38 GB/s
HW AES: 1.18 GB/sSW AES: 0.48 GB/sBottleneck: RSA

Primjer openssl

Keep-alives

It's... complicated

ALI, uglavnom treba ukljuiti

Obian HTTP (nginx):~~ 10.000 pages/s --> 20.000 pages/s

SSL (nginx, ECDHE-RSA-AES256-GCM-SHA384):800 pages/s -> 6000 pages/s

SSL (nginx, RC4-SHA):1200 pages/s -> 7000 pages/s

Objasniti to je

CGI, FastCGI, WSGI...

(CGI nitko ne koristi, forget it)

FastCGI, WSGI, SCGI (Django): skoro istiRazlike unutar 1%-2% na "normalnim" optereenjima

Na 250 concurrent: do 20%

FastCGI da best!!1
(RoR)

LOL FastCGI sucks
(Django)

Stvari na koje treba misliti

Memorija: svi protokoli s "eksternim" aplikacijskim procesima trebaju N*MB memorijePHP, Django, Rails... nije udno vidjeti do 50 MB po procesu x 100 procesa = 5 GB memorije

Stateful firewall moe uvesti ogranienje (limit) na broj istovremenih konekcija

"Neoekivani" lockovi (Apache rewrite lock), database locks...

Rastereivanje servera

Memory cache serverMemcached, ali svatko ima svog klona

Ako ga ne koristite, ubijte se

8 GiB serverskog RAM-a je jeftinije od 1000 knUSA: modul 8 GiB DDR3 1333, ECC+reg, CAS 9: 110 USD

Moderne matine ploe: 768 GiB per-socket256 GiB = 32.000 kn

64 GiB = 8.000 kn

Cachirajte sve, memorija je jeftina

Outsourceanje servera

Jedan nain da server radi to manje je da se koristi drugi server

CDN-ovijQuery, druge JS i CSS biblioteke

Fontovi, slike

Mini(mi)ziranje resursaTinyPNG

Google Minify

Primjer gov.hrPrimjer
zakoni.ivoras.net

Optereivanje klijenta

Moderne aplikacije ponovno guraju aplikacijski kod na klijentsku stranu

JavaScript, vrlo dinamina suelje, AJAXAngularJS, KnockoutJS, EmberJS [comparison]

Server request jednom ili nijednom (CDN!)

Ekstreman sluaj: server posluuje statike datoteke i dinamiki AJAX (JSON iz baze) npr. CouchDB

Klijent (browser) moe vui resurse "prirodno" s veeg broja servera! (static.x.hr, ajax.x.hr)

Primjer web

Disk IO

Mehaniki disk od 15.000 RPM: 175 IOPS

10 takvih diskova od 15.000 RPM: 1.750 IOPS

Enterprise SSD, Intel 730, 480 GB: 10.000 IOPS

10 takvih diskova: 100.000 IOPS (4.8 TB)

20 SSD-ova, RAID 10 (4.8 TB)200.000 IOPS READ

100.000 IOPS WRITE

20 * 3.500 kn = 70.000 kn

Hrvatska ima oko
188.000 studenata(AZVO)

Plan to fail

U velikim okruenjima se mora uzeti u obzir statistika da e se odreeni broj komponenti (diskova, napajanja, memorije, itd) pokvariti svaki dan.

Kvarovi se predviaju i "rjeavaju" redundancijom komponenti, replikacijom podataka i (kao zadnju liniju obrane) backupom

Redovita zamjena opreme i migracija podataka je danas nuna

Primjer Google, Netflix...

Slaganje stacka

Lego kockiceHTTP server (npr. Apache, nginx)

Aplikacijski server (npr. Django, RoR, PHP)

Baza podataka (npr. PostgreSQL, MySQL)

Statiki resursi (npr. slike, video, CSS, JS)

Kako ih posloiti da cijeli sustav bude najefikasniji i najlake proirljiv ?

Objasniti zato je
dobro da su odvojene

Preliminarno pitanje

Da li vam to treba ???

Hrvatska je mizerno mala zemlja, teko da ima realnih usluga koje ne moe odraditi jedan jedini moderan i jeftin serverFiskalizacija (slubene procjene iz 2012):10 milijuna poruka dnevno

60 80 GB podataka dnevno

24h: (115 po sekundi, 1 MB / s), 12h: (230/s, 2 MB/s)

Bilo kakvi problemi u performansama su odraz nesposobnosti i mogu se ispravit

Stack: HTTP server

Posluuje statiki sadraj, sve dinamike zahtjeve predaje aplikacijskom serveru

Generika rjeenja: Apache, nginx, Lighttpd...

Specijalizirana rjeenjaVarnish reverse proxy, HTTP router, front-end acc.

Haproxy reverse proxy, load balancer

G-WAN specijalizirani HTTP server, app server za C/C++ aplikacije, cache svega u memoriji

Objasniti to je

Stack: aplikacijski server

Koji god je potreban za aplikaciju

JAKO paziti da je:Neovisan i o web serveru i o bazi podataka i o storageu

Mogue ga je instancirati vie puta, na vie sustavaOva osobina je najee prisutna po defaultu jer moderna okruenja predviaju multithreading pa su svjesna potrebe za izolacijom procesiranja

Ako instance trebaju meusobno komunicirati s globalnim podacima, to se radi preko memory cache servera ili message queua

Moderni aplikacijski server

Best practices za skalabilnost aplikacijskog servera koji je takoer re-usabilna komponenta za budui razvoj:Poeti od web servisa / REST API-a to je "back-end"Nekad se to zvalo "middleware"

Web servisi su takoer web aplikacija i moraju se moi instancirati na veem broj servera

Ovi web servisi su otvoreni prema van korisnicima

Front-end koristi web servise a ne bazu podatakaFront-end je web app i mora se moi proizvoljno instancirati

Postoji proizvoljan odnos M:N instanci WS-a i front-enda

Ovdje dolazi HTTP routerObjasniti zato

Stack: baza podataka

Pitanje religije:Shared nothing

Shared everything

Sharding RAID 0

Replikacija RAID 1

Sharding + replikacija RAID 10

Vi zapravo elite eventually consistent bazu

Objasniti zato je shared nothingbolji i zato IBM sucksObjasniti zato

Stack: statiki podaci

Upucajte developera koji sprema slike, CSS i druge BLOB-ove u bazu podataka

Datoteni sustavi su brzi, lako se odravaju, repliciraju, kopiraju, backupiraju, gledaju, konvertiraju iz formata u format, snapshotaju, nadgledaju, you name it...Osim kad ste Facebook

Ponovno, shared nothing je ideal kojem treba teiti

to napraviti bez novaca?

Maksimalno opteretite browser, smanjite broj zahtjeva na server i njihovu kompleksnostSve to je kompleksno se moe cacheirati

Outsourceajte komentiranje na stranici na Disqus

Osim specifinog CSS-a i JS-a, sve ostalo moe biti na CDN-u

Access log vam ne treba, moe se zamijeniti s Google Analytics, + client-sideError log je mali

ili FB

/