Back-end u Ruby/Perl/C++ za bolje performanse

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Čitao sam skoro neku diskusiju vezanu za menadžere bazi podataka i koji je u sposobnosti da opslužuje veliki broj korisnika u isto vreme, koji nudi bolje opcije i sl. Iznenadio sam se kada sam video da dosta njih ne gotivi MySQL, navodno zbog loših performansi kod većih sajtova. Ali opet, Facebook koristi MySQL i uspeva u tome - verovatno zbog HHVM. Zanima me da li neko ima iskustva sa korišćenjem CGI uz PHP i kako se ovako mogu postići bolje performanse kod sajtova sa veoma velikim brojem korisnika (stotinama hiljada i milionima)?

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Ko god da kaze da MySQL los taj neka sebe upuca u glavu odma. Najprosireniji, mogucnos povezivanja na udaljene baze, kompatibilnost itd, itd, itd....

Taj ko je to rekao hoce da troluje ljude slepac...

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Nije rekao u fazonu da je loš, nego da nije povoljno rešenje PHP + MySQL za te sajtove koji opslužuju ogroman broj korisnika i da tu treba da postoji neka back-end podrška u vidu Perl-a ili Ruby-a (FB recimo koristi C++). Sa druge strane, neki navode NoSQL i InnoDB kao bolje rešenje, ali ne znam zbog čega.

Kontam da to više zavisi od toga kako programer optimizuje aplikaciju, ali mi je zanimljiv taj pristup.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Ma nema dalje diskusije oko gluposti. Pokusavaju da sruse giganta ali neide

• 1Ovo se svidja korisniku: E.L.I.T.E.
  
  Registruj se da bi pohvalio/la poruku!

Facebook je možda koristio MySQL u ranim fazama razvoja ali sam siguran da je kasnije a najviše zbog automatizacije shardinga / particionisanja, sve od relacionih podataka (veći deo Facebook podataka) preseljeno sa MySQL-a na Cassandru (NoSQL tip baza podataka). Izuzetno je skup proces particionisanja relacionih baza koje imaju fiksno određene šeme zbog samih relacija (čitaj stranih ključeva).

Sa druge strane, ni jedan veći backend heavy projekat ne zavisi samo od jednog servisa. U Facebook slučaju su oni čak i napisali pojedine servise koji bi maksimalno odgovarali njihovim potrebama. Npr. od 10 ili više mikroservisa svi komuniciraju preko određenog RPC servisa, Thrifta, koji su oni sami napravili.

Sve u svemu, tvoja pitanja su poprilično opširna a odgovore po pitanju skalabilnosti softvera možeš da dobiješ samo kada postaviš precizna pitanja. Nije stvar u tome da zvučim nadobudno nego je u ovom slučaju pravi odgovor uvek pitanje zahteva određenog softvera i njegov plan razvoja. Niko nije nikad napisao da je MySQL sranje, jednostavno postoji minimum 5 čvrstih razloga zbog kojih je kod neke vrste backend softvera npr. lakše odabrati bazu kao što je Riak, jer inženjeri u Amazonu nisu iz nepoznatih razloga osmislili Dynamo princip konzistentnog hashinga.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

@Default, hvala na odgovoru Hteo sam samo da pitam da li neko ima iskustva sa korišćenjem drugih jezika pored PHP-a koji bi ubrzali sam proces servisiranja kod nekih većih sajtova (kao što se C# može koristiti uz Python, Ruby...). Ivan me je pogrešno razumeo pa nisam hteo da nastavljam diskusiju.

U međuvremenu sam pogledao neka predavanja vezana za veće projekte (gde se koriste virtuelne mašine, sistemi za pripremu upita i sl.) tako da su mi se sad složile kockice

• 1Ovo se svidja korisniku: E.L.I.T.E.
  
  Registruj se da bi pohvalio/la poruku!

Napisano: 11 Avg 2015 16:00

Citat:Zanima me da li neko ima iskustva sa korišćenjem CGI uz PHP i kako se ovako mogu postići bolje performanse kod sajtova sa veoma velikim brojem korisnika (stotinama hiljada i milionima)?

Što se tiče CGI-a, CGI kao način pokretanja PHP-a putem web servera je davno prevaziđen zbog loših performansi iako je pružao više izolacije i samim tim više sigurnosti.

Zamena za CGI je FastCGi koji otprilike ima sličan princip izolacije jer za razliku od npr. načina na koji Apache po defaultu pokreće PHP interpreter (embeduje ga u svoje procese i samim tim php interpreter nema sandbox memorije), FastCGI pokreće njegov PM (process manager ili FPM) koji može paralelno da opslužuje više procesa tako što forkuje (pokreće) dodatne pod-procese koji po defaultu koriste keširan php bytecode (opcode) glavnog php procesa. U neku ruku sličnom procedurom radi i Apache mod_php kada za svaki http request treba da kreira nov process koji je embedovan u Apache procesu zbog bržeg izvršavanja jer nema context switcheva (po defaultu je process, ali može da bude i thread), ali mislim da opcode caching nije uključen po defaultu.

Drugim rečima, stvar između FastCGI-a i mod_php-a je stvar izbora ali samo ako koristiš sve prednosti.
Apache će svaki request da forwarduje php-u pa čak iako polovina URL-a koje treba parsirati zapravo samo servisa statični sadržaj. To znači da Apache po defaultu uzima više memorije jer čak i zahtevi koji nemaju dinamičan routing prođu kroz inicijalni parsing dinamičnog routinga.

TL;DR ili svoje statične fajlove veži za pod-domen a onda ih serviraj nečim kao što je LightHTTPD, tako da Apache PHP-u prosleđuje samo dinamične zahteve ili stavi ispred Apache-a proxy server kao što je Nginx koji će isto to da radi, ili jednostavno koristi Nginx koji podrazumeva da PHP treba da pokreće kao FastCGI a kojem konfigurišeš static content folder tako da zaobilazi PHP.

Hint: Dobra praksa kod Wordpress sajtova je da se instalira W3TC plugin i podesi Cloudflare CDN koji takođe radi proxy svim requestovima i kešira statični sadržaj koji potom geo-distribuirano servira, tako da je na backendu stvar izbora svedena na minimum. Možeš da potražiš neke benchmarks, ali imaj na umu da većina benchmarka testira Apache i mod_php sa statičnim requestovima što je besmisleno. Mislim da sam samo jedan benchmark video koji ima smisla i prema kojem se sve navedene konfiguracije ponašaju identično a iz svojeg iskustva sam više puta viđao da Nginx ima point of failure koji nema nikakav tracing ili log što je verovatno posledica fleksibilnog konfiguracionog fajla.

Dopuna: 11 Avg 2015 16:09

E.L.I.T.E. ::@Default, hvala na odgovoru Hteo sam samo da pitam da li neko ima iskustva sa korišćenjem drugih jezika pored PHP-a koji bi ubrzali sam proces servisiranja kod nekih većih sajtova (kao što se C# može koristiti uz Python, Ruby...). Ivan me je pogrešno razumeo pa nisam hteo da nastavljam diskusiju.

U međuvremenu sam pogledao neka predavanja vezana za veće projekte (gde se koriste virtuelne mašine, sistemi za pripremu upita i sl.) tako da su mi se sad složile kockice

Sve je manje ili više u današnje vreme što se tiče performansi svedeno na minimum razlika.
Sam si i napisao da Facebook koristi HHVM što je potpuno identično pristupima drugih platformi koje odavno koriste JIT kompajlere i virtualne mašine - C# CLR, Python PyPy (mada Dropbox radi na novom JIT endžinu koji ide putem V8 dokazanih praksi https://github.com/dropbox/pyston jer se PyPy pokazao lošim u par slučajeva), Java JVM, node.js v8, itd.

Sa druge strane i stvar aplikacionog sloja i njegovih performansi isto zavisi od zahteva koji sam softver ima. Ali kao što sam i napisao, Facebook pokreće PHP ali 60-70% CPU-a rade C++, Erlang, Haskell mikroservisi a ne PHP.

Drugim rečima, od plana razvoja zavisi i odabir tehnologije. Danas je sa skoro svakim tech stackom moguće lako napraviti modularnost u vidu mikroservisa koje sam već naveo i onda zameniti delove loših performansi prvobitne aplikacione strukture ili endžina sa nekim drugim koji može da bude čak i assemblerom pisan.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Hvala Default, sad mi je mnooogo jasnije

Izvini sad što te smaram, ali imam još jedno pitanje kad si već tu (da ne bih otvarao novu temu), koji PHP framework preporučuješ za početnike? Imam solidno poznavanje OOP i hteo bih da krenem da radim sa nekim framework-om, ali nisam siguran koji da izaberem. Da li je Laravel dobar za početnike?

Znači treba mi samo savet za početak koji bi me framework najbolje uveo u celu priču, a posle ću ja da vidim koji mi najviše odgovara, pozdrav i hvala još jednom

• 1Ovo se svidja korisniku: E.L.I.T.E.
  
  Registruj se da bi pohvalio/la poruku!

E.L.I.T.E. ::Hvala Default, sad mi je mnooogo jasnije

Izvini sad što te smaram, ali imam još jedno pitanje kad si već tu (da ne bih otvarao novu temu), koji PHP framework preporučuješ za početnike? Imam solidno poznavanje OOP i hteo bih da krenem da radim sa nekim framework-om, ali nisam siguran koji da izaberem. Da li je Laravel dobar za početnike?

Znači treba mi samo savet za početak koji bi me framework najbolje uveo u celu priču, a posle ću ja da vidim koji mi najviše odgovara, pozdrav i hvala još jednom

Ako je učenje u pitanju ali i kasniji nastavak rada sa tim frameworkom, Symfony ili Laravel - poprilično su razvijeni do tih mera da ih samo finese razlikuju. Mislim da Laravel deluje intuitivnije a i trenutno je popularniji u PHP-u pa ćeš verovatno i više materijala/dokumentacije da nađeš. O finesama ne bih sada, a i već smo pisali u nekoj temi ... zanemarive su stvari jer ćeš uticaj razlika verovatno da vidiš tek ako ti neko ukaže na njih. Sa druge strane, nisam pratio razvoj php frameworkova više od godinu dana, verovatno se svašta izmenjalo ali nekako verujem da su se stvari samo više izbalansirale odnosno da su se razlike zamaglile.

Zend je uvek bio nešto komplikovaniji framework jer su uvek težili ka tome da arhitekturu klasa svedu na maksimalnu moguću odvojenost klasa / objekata što je u većini slučajeva, odnosno za većinu upotreba bespotrebno, odnosno 'over engineered'.

Drugi frameworkovi su ili previše magični, pa samim tim i nećeš naučiti paterne organizacije koda koje se kriju iza jer ti ih neće pokazati, ili su u pitanju neki minimal frameworkovi.

Možda Ivke ima nešto da opovrgne ili kaže na ovu temu, mislim da je više praktičnog iskustva imao sa PHP i Java frameworkovima, ali verujem da je to to.

• 3Ovo se svidja korisnicima: E.L.I.T.E., Default, _ivKe
  
  Registruj se da bi pohvalio/la poruku!

Treca stvar koju svaki developer mora da zna (pored "never trust user input" i "assumption is mother of all fuck ups") sledeca:



Postoji X varijanti za opsluzivanje veceg broja korisnika, a nijedna od njih ti nije potrebna dok ne prebacis Y korisnika na dnevnoj bazi. Ne zamaraj se time, gubis fokus sa mnogo bitnijih stvari.