Black Friday 2016

Black Friday 2016

Am scris în anii trecuți despre BF și despre cum s-ar putea îmbunătăți unele lucruri de mi-a ieșit pe nas. Chestii de rumegat:

  1. Nu ai voie să te plăngi că site-ul ți-a picat atunci când landing-page are 1Mb (emag) sau 3-4Mb (evomag). Pur și simplu, ți-ai pierdut dreptul să te plângi. E ca și cum ai pune cauciucuri de vară (și tocite!) pe polei;
  2. Nu ai voie să te plângi că serverele ți-au picat când tu nu folosești un CDN pentru imagini;
  3. Nu ai voie să te plângi că ți-au picat jucăriile când tu incluzi 6-700kb de JS;
  4. Nu ai voie să comentezi atunci când, pe pagina de produs, tu încarci reviews, recomandări, produse vizualizate recent etc. Cu cel mai ninja caching, la 400k+ simultani, se simte.
  5. Conceptul de elastic cloud are deja vreo cinci ani (dacă nu mai mult!) de când a apărut. Ce înseamnă asta? Ai un server scalabil în care poți băga resurse serioase (pe Amazon poți pune până la 64 procesoare și 700+ GB RAM!). Ah, costă? Ei bine…

Iar astea sunt chestii de bun simț, ce le poți observa chiar dacă ești sau nu în sistem. Google a pus la punct niște „reguli” (sfaturi?) despre cum ai putea îmbunătăți lucruri. Înainte de ei, au fost cei de la Yahoo!, cu al lor YSlow. Sunt subiecte discutate și răsdiscutate de ani de zile. Ani!

Dorin zice el bine:

Răspunsul ar trebui să vină din IT-ul românesc. Și el răspunde cu mediocritatea caracteristică; în fond e-mag angajează unii din cei mai buni oameni din România, și totuși, eșuează. De ce?

V-am mai vorbit despre cât de găunos e domeniul ăsta. V-am mai povestit cum IT-ul românesc este un câmp de executanți, fără pic de imaginație, fără pic de coloană vertebrală, cu oameni incapabili să-și asume responsabilitatea sau să dea soluții coerente.

Doar că aici deja nu e (doar) mediocritate. Nu.

Nu trebuie să fii Knuth pentru a lua lista de la Google și a începe să îmbunătățești lucruri.

Nu trebuie să fii Stroustrup pentru a gândi o strategie pe o săptămână la modul: „bă, noi știm ce produse vor fi reduse; hai să punem tot ce se poate în cache-ul browserului (i.e. imagini), iar când începe show-ul, servim doar ce nu este în cache”.

Dacă nu ești în stare să faci optimizări, nu trebuie să fii Jacob Neilsen pentru a face o pagină a produsului cu minimum de informații și cu un buton uriaș de „cumpără!”. Fără reviews, fără recomandări, fără nimic altceva. Minimum.

Dar nu! Noi trebuie să ne lăudăm că lucrurile nu au mers. De vină sunt sutele de mii de vizitatori, alinierea planetelor, băsescu.

13 Comentarii

Malin a scris

Trei chestii pe subiect:
1. 68% din trafic a fost de pe mobil, ceea ce presupune ca prin AMP sau o versiune mobile/responsive cu ceva lazy/load impactul pe resurse trebuia sa fie mult mai mic, deci manageable chiar si cu un sistem de load balance clasic;
2. Pe mine m-a frapat faptul c-a iesit ala de la EasyHost la ZF sa ne spuna ca anu’ asta traficul eMag o sa creasca cu intre 100 si 200% si ca 60% din trafic o sa fie pe mobil. Cifrele i-au cam iesit, competentele nu prea;
3. Rateurile astea sunt simularile perfecte pentru rezistenta la DDoS. Ca cineva sa puna eMag jos in orice moment (plecand de la premisa ca de BF au avut ceva in plus ca hardware si latime de banda) nici macar n-ai nevoie de un botnet de IoT-uri ca te descurci cu un laborator de informatica de la o scoala si ceva script care deschide aleatoriu 30-40 de taburi de pe eMag :D

vlad a scris

Acum 2 ani am lucrat la site-ul Flanco de BF (care era separat de site-ul principal).

Am ales sa facem totul cat mic si simplu in cloud-ul de la microsoft (azure), si dupa ~5 saptamani de lucru (de 3 persoane), a fost totul gata, inclusiv integrarile cu serviciile adiacente.

Cu 60 de masini pornite in peak, si ~20k oameni pe site simultan, a mers totul blana, fara probleme majore. La emag magnitudinea este cam de 10 ori mai mare decat la flanco, deci ar trebui sa fie rezonabil de rezolvat

Malin a scris

@Ionuț Staicu: Programatorii n-ar trebui sa aiba legatura directa cu stabilitatea siteului. E drept ca ei ar trebui sa se ocupe de performanta de care vorbesti in articol, dar in ceea ce priveste stabilitatea atunci ar trebui sa vorbim mai degraba de devops sau sysadmins.

Empire a scris

Eu cred ca s-au descurcat destul de bine. A picat jumatate de ora dimineata, apoi a fost tot timpul operational si se incarca bine. Fata de anii trecuti, a mers perfect emag-ul. Jumatate de ora de downtime si in rest mers perfect o zi intreaga in care au vandut enorm. Da, puteau face site-ul mai light, dar imaginea conteaza mai mult decat sutele de kilo carora sistemele le-au facut fata.

Malin a scris

@Empire: LOL! Jumatate de ora downtime inseamna ca s-au descurcat bine? Ai idee cam cate vanzari se puteau face in perioada de downtime la un astfel de eveniment si cati au abandonat convinsi ca n-o sa mai revina prea curand si chiar daca revine n-or sa mai gaseasca produsele pe care le voiau? I think not!

Ionuț Staicu a scris

@Empire: exact, ne complacem în mediocritate:

– a picat doar jumătate de oră.
– fură, dar mai și face pentru oraș (despre primari)
etc

S-ar fi descurcat destul de bine dacă ar fi putut ieși sâmbătă să spună „nu am avut downtime deloc (sau doar câteva secunde, până au pornit cele 50 servere suplimentare)”.

Când ai văzut ultima dată downtime la amazon? Sau hai, nu amazon, că e prea mare. Când ai văzut downtime la newegg? Exact, nu ai văzut. Și nu ai văzut nu pentru că nu urmărești newegg ci pentru că nu au avut.

Adaugă un comentariurăspuns pentru

Link-urile în context sunt binevenite. Comentariile fără nume/email valid sunt șterse.

Site-ul blog.iamntz.com utilizează cookie-uri. Continuarea navigării presupune acceptarea lor. Mai multe informații.

windows apple dropbox facebook twitter
windows apple dropbox facebook twitter