Citat:
Samo da dodam još malo ulja na vatru, ovo mi je promaklo (sorry Ilija, mislio sam da je od tebe krenulo  )
Šta znači tačno ova rečenica?
Da "čista" rešenja ("čist" PHP, "čist" ASP.NET..) mogu da serviraju beskonačno mnogo upita na nekom hardveru i da nećeš doći u situaciju da dostigneš maksimum?
(Pa i "čist" PHP, itd. je framework.)
|
ova recenica znaci veoma prostu stvar - od trenutka kada korisnik zatrazi neki content do trenutka kada ga obavi deli ga N tralalala operacija i svaka apstrakcija i svaki layer se penalizuje na odredjeni nacin, u nekim situacijama cena nije bitna - u nekim jeste. kao sto sam spomenuo - u velikom broju slucajeva to apsolutno nije problem, ali twitter je primer u kojem je bilo potrebno osakatiti sam RoR da bi se aplikacija dovoljno dobro skalirala - as easy as that. druga opcija je da pises sve ispocetka, ili da se napravis pametan i kazes "e da sam ja to pisao - ja bih to u ... i stavio ... i upotrebio hepek i ... ma ljubi ga majka".
Citat:
A šta kad koristiš npr. "čist" PHP i dođeš do maksimalnog broja upita koje hardver može da izdrži? Šta onda? Pa i onda moraš da "lomiš", po tebi.
Pa i ako ćeš da "lomiš", šta onda kad za 6 meseci opet dostigneš max? Opet "lomiš"? Pa dokle tako prijatelju? Dok ne odeš u asembler? Pa i tamo ima max.
|
hm... pre svega sa modernim kompajlerima nisam siguran koliko je racionalno poredjenje sa asemblerom - ali da, ima situacija u kojima je potrebno spustiti se dovoljno "nisko", zasukati rukave i raspisati dobar deo stvari od nule - gde nula nije tabula rasa programiranja, nego komponente kao sto su custom index, custom parser content-a, custom whatever - kao sto spomenuh - ovo nije narocito cest slucaj, pogotovo ne u klasicnim biz aplikacijama (u prevodu - koji ce ti?), ali igrom slucaja u kompaniji u kojoj trenutno radim je tako nesto bilo neophodno (vast.com) - to svakako ne znaci da je neko bio retardirano dokon i frontend pisao C-u.
Citat:
|
Kupi se novi server (doda CPU, itd) i kraj priče.
|
jel? mozda ako aplikacija moze prakticno da se skalira vertikalno, takodje - i vertikalno skaliranje ima veoma grube limite koje namece hardware, OS, kao i sam jezik/framework - npr. ruby i sa njim RoR nisu sampioni vertikalnog skaliranja - jedan request == 1 VM (ok, postoje neki standardni mehanizmi kojima se ovo moze delimicno kompenzovati i svakako je cena instanciranja ruby VM-a daleko manja od instanciranja npr. JVM-a) i to ti je sto ti je - i tu opet dolazimo do toga da sam super-mega framework koji te resava mnogih glavobolja na pocetku i ciji izbor izgleda kao jako dobar potez koji stedi mnoge sate programiranja, debagovanja, smanjuje kompletnu cenu izrade, ... name it - u takvoj situaciji pocinje da gubi ogromnu prednost koju je u prvom trenutku davao.
Citat:
|
Ne znači da od početka trebaš da ideš sa najsporijim rešenjem i traljavim programiranjem, naravno.
|
naravno, ali ovde je u pitanju situacija kada npr. odjednom aplikacija koja je iz racionalnih razloga bila pisana da podrzi max 10 upita u sekundi u nekom trenutku mora da skalira na 1000 upita u sekundi i kada "buy more iron" ne pomaze, ili je ekonomsko samoubistvo - struja kosta, rackspace kosta, iron kosta (ovo je barem jednokratna investicija) - ili kada naprosto ne resava problem.
ovo je rasprava koja moze da ide u beskonacnost, ali ono sto mene nervira u celoj prici je X je postigao Y bez price o uslovima Z - u prakticnom primeru to je:
1) django je podrzao ~140 upita u s (out of the box?)
2) twitter koji koristi RoR podrzava ~11K upita u s (out of the box?)
3) java je brza kao/brza od C/C++-a (10 primera u kojima ni u tragovima nije moguce videti ponasanje JVM-a kada GC divlja, ili su na nivou domaceg zadatka iz osnova programiranja - ne mislim nista lose, ali cesto takvi primeri pokazuju izuzetno malo, a buzz koji se generise je izuzetno velik)
4) ... name it, web je prepun potpuno banalizovanih benchmark-a