Ce zice specialistul în securitate şi servere al blogului:
X servere de baza de date pe model cluster – shards (partitionare), cu scalare in caz de nevoie (spike) automata, X servere de procesare CGI (procesarea codului dinamic) cu scalare automata, 10 servere de caching continut dinamic pe model reverse-proxy
Pe româneşte: 100.000 oameni online în acelaşi moment pe site costă între 150 şi 300€ pe oră, în funcţie de câte interogări ale bazelor de date sunt necesare. Emag au avut dimineaţa câte 2-300.000. Altex tot pe acolo. Adăugăm şi siteuri neoptimizate şi sume măricele pentru a le optimiza şi aşa mai departe şi rezultă nişte sume măricele.
Koyos.ro a stat bine cu uptimeul si pot sa spun sigur ca nu are 10 servere ci mai putine dar sunt bine optimizate si balancingul se face intr-un mod profesionist.
Daca te duce putin capul, poti sa faci pagina de oferte Black Friday, statica, doar html, si cu un key in cache pentru cand s-a epuizat stocul.
Iar restul siteului(necesara pt shopping cart si comanda), il poti scala frumos la amazon sau altii care ofera cloud.
https://aws.amazon.com/ec2/pricing/
O instanta extra-large cu hight-cpu costa $0.6/ora. Bagi si tu 100 de instante, ca vorba aia 1 data pe an e black friday-ul si iti rezulta un cost de $60/ora. La finalul zile platesti undeva sub $1500, iar asta fara nicio optimizare de auto-scaling(creste sau scade numarul de instante in functie de utilizare), care poate reduce costul la probabil $300-400 pe ziua respectiva.
E greu tata, e greu.
Vin eu de la pus faianta sa-i invat meserie…
Descopar cu multa surprindere ca avem foarte multi specialisti in scalabilitate in Romania…
Minunata solutie. Scalare elastica be baze relationale shardate. Masuram numarul de conexiuni pe un nodejs care nu duce nimic in spate. We don’t need no stinkin’ transaction. eMAG sigur n-au auzit de memcache si de reverse proxy, ca ei vin cu pluta pe Amazon. Doh?!?
E cineva din cei care comenteaza care chiar a pus manutza pe un site din asta IRL sa vada cum functioneaza dracia?
Nu zic ca nu se poate, doar ca e mult mai simplu sa vorbesti din carti sau din bloguri decat sa implementezi efectiv un astfel de sistem.
@Adrian: luminează-ne la costuri, te rog. cât ar costa să ţii în picoare un asemenea site, făcut cu un cod modest?
am inteles. deci de asta nu merge niciun site
Eu nu cred ca magazinele mici fac in primul rand suficient de multi bani pentru a-si permite asemenea resurse. E pur si simplu un calcul economic, daca BF e pentru ei doar o lichidare mascata de stoc…
De aia exista platforme cloud – autoscaling automat si extrem de rapid, si in sus si in jos – deci in perioadele moarte nu platesti aiurea o infrastructura supradimensionata. Doar ca trebuie sa-ti alegi cu grija providerul si sa ai grija ce informatii urci acolo
Pai ideea nu e sa modifici site-ul actual ci sa muti tot traficul suplimentar in Amazon. Adica in Amazon tii doar informatiile pentru produsele reduse. Sunt doua puncte mai complicate: in prima pagina cand intra hoarda si trebuie sa redirectionezi amatorii de oferte afara din culcus cu tot cu profilul lor de utilizator – si cum aduci tranzactiile din Amazon in backoffice ca sa le procesezi. Dar asta se poate face asincron, nimeni n-o sa se oftice ca angajatii eMAG aud de comanda lor juma’ de ora dupa ce ai primit tu emailul de confirmare. Call centerul nu scaleaza oricum, btw.
Asta ar fi fost o implementare ok. Si relativ simpla, inseamna sa ai un site care vinde un set de produse in Amazon unde e buluc lumea si in paralel site-ul principal functioneaza bine-merci.
Ca si costuri intr-adevar mai mult de cateva sute de dolari pe ora nu are cum sa te duca.
Dar, repet, nu e nevoie sa-si modifice nici un site arhitectura doar ca sa vanda o mana de produse timp de o zi pe an.
Totusi, daca iti respecti clientii, faci in asa fel incat in ziua asta sa nu fie probleme, si ar castiga si ei cu siguranta si mai mult decat oricum castiga.
Sa inchirieze servere doar pt 24h, sau sa gaseasca o solutie, sunt sigur ca exista ceva…refuz sa cred ca ei sunt singurii din lume cu un magazin online maricel si cu o problema de genul asta, tocmai azi.
Alt lucru pe care nu il inteleg, unele produse intrau in black friday cu stock limitat, adica 3 sau sub 3 produse, evident ca s-au vandut instant, si ma gandesc…daca tot vrei sa vinzi, de ce sa nu pui la dispozitie mai multe?
si apropo, ce se mai aude cu faptul ca emag a depus actele pt intregistrarea Black Friday la OSIM?
@Alex: li s-a dat cu flit.
Este si nu prea este asa.
In functie de numarul de produse si de arhitectura sistemului (aplicatiei), se pot servi direct din cache (din memorie) TOATE datele astfel incat baza de date sa aiba un numar suportabil de accesari. In acelasi timp, toate site-urile care se respecta servesc fisierele statice (imagini, js, css, html) via CDN, ridicand astfel presiunea de pe serverul web.
Cu un server NGINX, 2 -3 servere de caching si un server MySQL bine configurat poti suporta pe o aplicatie optimizata mii de utilizatori simultan.
Cred ca punctele principale aici ar fi optimizarea arhitecturii, codului si configurarilor de MySQL.
ca tot se scrie de uptime, infrastructura, etc. Uite cum face tumblr:
wow 100k oameni in acelasi timp (sa zicem cam 1m de requests). super mega putin pentru un sys admin bun. naiba, pana si nodejs, care e single-core, single-thread face fata la 100k connections. dar na, tu sigur vorbeai de cod php de canal si niste mysql queries super greoaie. atunci da, pe cod prost e greu sa faci scalare.
Sa duci un „black friday” e complicat si foarte scump. Amazon-ul (partea cu cloud servers) asa s-a creeat: cumparau/inchiriau multe servere de black friday si sarbatori si dupa aia foloseau 10-15% din ele
). Ne este foarte usor sa aruncam cu pietre dar adevarul este ca niciunul din site-urile mari nu au planuit de la inceput sa ajunga ca si volum si de aceea nu se scaleaza. Eu sunt programator si imi este usor sa zic „dar eu as fi facut asa”, „eu nu faceam asta”, „ce varza sunt” dar adevarul este ca site-urile astea au pornit cu bugete mici, cu owneri care nu inteleg anumite procese din dezvoltarea unei afaceri online, cu programatori/sysadmin ce nu au experienta pe scalabilitate, etc. Este foarte scump pentru site-urile de ecommerce din romania sa tina site-urile up&running azi. Si cand zic scump ma refer la faptul ca ar lua o bucata serioasa din profitul de BF
Problema cu site-urile ro de ecommerce este ca au foarte mari probleme de scalabilitate (mai exact sunt facute pe genunchi
@Mihnea
Daca scoti MySQL din ecuatie si bagi un Redis sau un Mongo, o sa vezi ca pe aceeasi configuratie vorbim de zeci de mii utilizatori simultan. Daca introduci si nodejs pe acolo, deja scalam automat catre magicul 100k.
@Claudiu
One-word: Java.
eMAG din cate stiu e un Python + mySQL shop. Nu e scris pe genunchi dar costa sa faci un sistem scalabil si nu e rentabil sa fii smecher tot anul pentru o singura zi de trafic mare in care epuizezi oricum stocul de promotii in 2-3 ore. Dar au facut cateva alegeri ciudate si era de asteptat sa cada la inceput.
Te lauzi că faci milioane de euro cu ocazia Black Friday, dar nu poţi investi în decurs de un an pentru optimizări. Nu zic să investeşti într-o zi o căruţă de bani, dar în timp eu cred că poţi ajunge la un site care să susţină 100k requesturi fără probleme.
@all: Ideea e ca astia ar investi pentru serverele alea si codul ala optimizat pentru o singura zi pe an. O astfel de investitie nu renteaza.
In restul zilelor totul merge foarte bine, infrastructura face fata.
@razvan
esti omul pesterii?
suntem in anul 2012, mai sus au zis oamenii solutii mai fiabile si flexibile decat html static.
Problema e ca majoritatea site-urilor au tehnologii de acum 4-5 ani (cel putin!), care la momentul respectiv erau ok pentru traficul de atunci. Acum toti incearca tot felul de solutii de scalare, insa problema de fond este ca tehnologiile sunt invechite si softurile sunt scrise cu picioarele. Si vorbesc din experienta, pentru ca si eu am scris cu picioarele softuri pentru magazin online
Solutia cea mai buna ar fi optimizarea sau rescrierea codului sursa si schimbarea bazei de date cu una care acceseaza hdd-ul cat mai putin si memoria cat mai mult. Insa aici e vorba de niste monstrii la care nu vrea nimeni sa se bage: cod scris si rescris de zeci de programatori, interogari aiurea, baze de date neoptimizate, samd. PHP+MySQL is so 2005…
Asa ca din pacate tot scalarea verticala ramane cea mai rapida solutie.
@manole
Nu stiu boss, eu sunt zugrav, dar era niste baieti acolo care vorbea…
E de rasu’ curcii ca magazinul number 1, atentie!!! DE IT din Romania sa clacheze.
Eu as fi curios sa aud parerea unuia care chiar a scalat cu succes si fara probleme un astfel de trafic. Este cineva ? Daca da, ce proiect ?
Un sistem bun este un sistem integrat (cam ce face apple). Degeaba dai doi lei in plus pentru a avea hyperthreding daca mysql nu stie sa-l foloseasca iar php nu e nici macar capabil sa lucreze multithreading nativ, doar prin wrapperi. In schimb java si oracle se vor folosi nativ de aceste avantaje ale hardwareului.
Nu e usor sa gasesti oameni buni care stiu ce fac.
@George: tocmai ai auzit de la 3. adrian, weasel şi băiatul din articolul iniţial.
Adrian este singurul cu o parere competenta dintre toti antevorbitorii pareristi de pana acum.
Redis, mongo sa puneti voi in productie cand e vorba de bani, garantii si istoric clienti + BI + backoffice + logistica etc. Solutiile NOSQL nu se preteaza la modelul de business emag. Relational is the way to go aici; ca e xSQL sau RAC tine doar de buget.
La mine la pravalie (Vali, pastreaza IP-ul pentru tine), traficul a crescut ~de 4 ori pe master si ~7,8 ori pe slaves fata de ieri dar suntem in modul business as usual, nu am primit niciun complaint so far
la ora 12:30 emag avea 90% din stoc „epuizat” deci nu mai e nevoie de niciun supercomputer.
Anul trecut altex a picat fara sa aiba oferte :)) intrau oamenii de curiozitate ca pe emag nu mai era nimic.
Suntem praf in online, emag si f64 s-au pregatit bine, restul au fost praf. Flanco a pus doar un pdf si nu poti sa faci comanda online, ceea ce e ilogic pentru ca flanco si emag sunt dedinute de aceeasi companie.
Altex si Domo ne invita in magazine pentru c-au crapat. Si oricum au niste site-uri jenibile.
Nu pricep de ce nu-si pun serverele pe un cloud capabil, sigur, poate sa vine mult factura dupa o zi de genul asta dar nu-ti crapa site-ul. E mai complicat si trebuie sa si valorifici traficul cu un site ok care are o rata de conversie buna. Dar merita.
N-au priceput inca. Poate la anu’.
@zoso ok. aleg weasel
@George: e la ofertă, cumperi un weasel primeşti un cristi la jumătate de preţ.
Deci, eu mi-am achizitiont licenta AVG cu 40% mai ieftina …Astia au fost banuti stransi de mine pentru zile negre, nu pentru Vinerea Neagra …Acum, tre’ sa trag tare ca vin sarbatorile de iarna !!!Si ,da… pentru cine nu stie este o lichidare de stocuri mascata, pentru ca se intra in febra cumparaturilor, pentru sarbatorile de iarna. Si, sigur ai nevoie de spatiu, ai nevoie de banii( lichiditati), ai nevoie de imagine, etc. Cine nu isi da seama ce mina de aur este aceasta zi isi merita falimentul.
Totusi daca te respecti nu promovezi ofertele speciale pentru ziua asta, daca stii ca ai un rahat de site/server…
@Vali, sa avem pardon, eu nu dau discounturi de black friday. Dar sunt flexibil in politica de preturi daca si clientul vrea calitate. Altfel e plina piata de ingineri care sa le dea fix ce au platit.
@weasel: m-as feri de mongo pentru orice implica tranzactii (eg. simplist: achiti un shopping cart, decrementezi un stoc). Plus ca Mongo by default are prostul obicei de a esua scrierile silent, fara raportare de eroare. Probabil ca pentru un one-night stand in Amazon merge, dar pentru un commitment serios pe termen lung nu e ceea ce trebuie.
Produse software bune pentru tot soiul de utilizari sunt cu toptanul, dar arhitectura trebuie sa fie gandita corect si adaptata situatiilor care pot apare. Cum migrezi produsele? Cum tii stocul corect cand mii de oameni adauga un produs in cart in aceeasi secunda? Cum faci sa nu se blocheze back-office-ul cand vine puhoiul de comenzi? Cum corectezi erorile (comenzi in plus, produse blocate in shopping carts nefinalizate)? Cum muti traficul de pe prima pagina? Cum inchizi treptat din functionalitati cand vezi ca sistemul o ia razna? etc. etc. etc.
In primul rand, solutii pentru un asemenea trafic exista, insa a le pune in practica intr-un proiect care are ceva viata, este o treaba mai usor de zis si mai greu de facut. Greu de facut, pentru ca mai toate siteurile de ecommerce au cel putin 3-4 ani de viata, ceea ce inseamna ca au inceput in php+mysql si fie au ramas, fie au evoluat catre ceva mai bun(python+postgresql o posibila cale), fie au fost rescrise, dar s-a pastrat ceva legacy code, care si acum provoaca dureri de cap programatorilor si asta s-a vazut si astazi.
Acum, am tot vazut, ca s-a tot aruncat posibile solutii salvatoare, cele mai comune o baza de date NoSQL alaturi de node.js. O solutie salvatoare, dar care desi pare una mai mocaciune, in realitate costa mai mult decat folosirea amazonului ca solutie de rezerva si aici nu ma refer la tehnologie, cat la resursa umana, deoarece sunt destui de putini specialisti in Ro pe asa ceva, si mai putini, buni.
Totodata mai exista o problema, despre care nu s-a discutat deloc si anume faptul ca marii giganti aici ma refer strict la altex sau domo, chiar flanco au avut promotii in magazin direct si am observat ca in general multi folosesc acelasi backend cu cel de la site, deci nu e de mirare ca acelea au crapat primele.
Asa ca optimizarile pot fi, din infrastructura sau din cod, orice ar fi costa foarte mult optimizarea si nu stiu cat de rentabil este pentru Black Friday:
https://www.dynatrace.com/news/blog/
https://www.dynatrace.com/news/blog/
Daca site-ul a fost conceput initial pt. a scala orizontal atunci este foarte usor sa scalezi adaugand mai multe instante WebServer (Apache/Tomcat/IIS in functie de platforma folosita). Dar asta inseamna sa ai DB cluster separat, caching cluster separat, LoadBalancer, Search Index, etc.
Also, Varnish face minuni daca e configurat cum trebuie; chiar daca ai Memcache, cu Varnish in fata web severelor reduci costurile enorm dar implica ceva analiza si logica.
In imaginea de mai jos as mai adauga Memcache pe ultimul rand pt. caching in aplicatie.
https://www.lullabot.com/articles/configuring-varnish-for-highavailability-with-multiple-web-servers
Apoi se poate folosi orice tip de baza de date chiar si NoSQL dar e cam greu cu faceted search pe NoSQL.
Sau poate faptul ca „au clacat” a fost de fapt o strategie pentru nu depasi numarul de „oferte hot” alocate pentru a fi vandute in cadrul acestui „eveniment” Black Friday …
Cristi, se poate folosi si mongodb pentru un magazin online, daca structurezi baza de date cum trebuie (been there, done that, got the t-shirt). Ca si „install & go” este mai rapid ca mysql la op/sec, sharding-ul si replicarea se fac mult mai rapid si cu mai putine batai de cap.
Din pacate, intr-adevar ca daca iti pica in productie e foarte nasol. Dar avand in vedere ca numarul de produse, clienti si comenzi este destul de redus pe .ro (aici ma refer la orice magazin in afara de emag) fata de .com, poti sa tii lejer un server de productie si unul doar de backup pentru db. Timp de generare al paginii? < 0.1 sec
Eu recunosc, sunt praf pe partea asta de servere, dar asta nu inseamna ca nu-i pot regula p-astia de le-a cazut site-ul sau pe eMag ca m-au trezit la 4.30, mi-au dat un toc de 4 ore si au inceput BF-ul la 8.30…
Fucking looooooooooooooooool! Păi vă mai miraţi de ce merg magazinele online autohtone ca curu’? Take a look at this shit:
Query mai handicapat ca ăsta nu cred că am mai întâlnit.
„The Amazon.com ecommerce platform
consists of hundreds of decoupled
services developed and managed in a
decentralized fashion. Each service
encapsulates its own data and
presents a hardened API for others to use. Most importantly, direct database
access to the data from outside its
respective service is not allowed. This
architectural pattern was a response
to the scaling challenges that had
challenged Amazon.com through its first 5 years, when direct database
access was one of the major
bottlenecks in scaling and operating
the business.”
De aici
@weasel: cum faci tranzacții în MongoDB?
@adrian @george Revenind… am constant intre 1 si 3mil connections pe node cu redis pe 1 masina cu 32cores si 64gb ram.
@cristi punem, punem, nu e problema. cadou: folosim si mai putine resurse.
Strict pentru frontend nu ai nevoie de SQL relational. Poti pur si simplu sa generezi continutul dintr-o baza de date relationala si sa-l folosesti ca atare pe modelul noSQL. Tranzactii si relationalite ai nevoie abia cand face comanda. Dar numarul de comenzi generate efectiv este mai mic decat numarul de pagini afisate.
Cum observa cineva mai sus, motivul major este ca legacy code-ul pe care au fost dezvoltate majoritatea magazinelor este prost, o rescriere de la 0 are nevoie de resurse, scalarea php-ului se rezuma la pre-generarea paginilor, reverse proxy si apc adica nimic specific php-ului. Chiar si scalarea mysql-ului e tricky. Nu pui inca 5 servere si brusc baza ta de date incepe sa mearga cu viteza sunetului. Daca nu modifici si aplicatia care apeleaza db-ul inca ‘nspe servere nu rezolva nimic.
Din pacate piata s-a maturizat inainte ca cei care vand sa o faca. Daca acum 5 ani de zile era explicabil, acum ca exista solutii ramane doar ca cei care se ocupa de business sa gaseasca oamenii potriviti care sa le implementeze. Dar cand unii migreaza de la Java si Oracle la MySQL si PHP si se mira ca nu le mai merge site-ul ..
La ce profituri au, 900 euro pe ora sa faca fata traficului e jenibil de putin. In locul lui Ostahie (de exemplu), as da de pamant cu managerii de la Altex.
@Thisisit
Este foarte costisitor (din perspectiva resurselor hardware) sa implementezi faceted search pe baze de date relationale. Ca idee, storage-ul solr este document based mai apropiat de modelul noSQL.
@weasel: discutam chestii diferite: ca si cum ai compara o motocicleta cu un BMW. Sunt pentru aplicatii diferite si alegerea lor e strict o chestiune de business. Intamplator ma stiu cu niste oameni de la emag si stiu, in mare, cam cum functioneaza jucaria lor in spate.
Perfectibila? Cu siguranta. Dar tehnologiile lor nu sunt obsolete, not by a long shot. Depinde si ce oameni ai in spate, vezi FB care se descurca binisor cu php&mysql.
Era cineva mai devreme care explica plin de patos cum php+mysql nu scaleaza in threaduri. MySQL-urile recente scaleaza bine pana la 64 de threaduri/masina iar pentru CGI-uri exista nginx, eventual cu varnish care este al naibii de robust.
Marea problema la Altex & Flanco este ca ruleaza pe Magento…epic fail.
Intradevar emag trebuia sa foloseasca Amazon EC2 si probabil sa optimizeze query-urile… optimizarea asta este un neverending story de fapt..
@Ionut: înseamnă că n-ai văzut prea multe query-uri. Măcar folosesc nested sets pentru categorii.
Unii mai comenteaza si-n cunostinta de cauza, dupa ce au mancat pe paine sisteme de genu: https://issues.apache.org/jira/browse/AVRO-1090
@ Mar: si ce platforma ecommerce ai spune tu ca ar trebui sa foloseasca?
3 words: extrem de exagerate aprecierile. Dar e bine sa aruncam cuvine d-astea: cloud, reverse-proxy, scalare automata. Suna bine. Da bine la clientu’ prost. S-arunca si se presare cu Amazon Dynamo (Apache Cassandra) se pomeneste de nginx si varnish si se ajung la concluzii aberante.
E toti bre, d-astia cu NoEsQuElu? Dintr-o data ca tot romanu’, ecspert in di tati?
@Cristi
Sa compari cum foloseste PHP+mysql facebook si cum il foloseste unul care are un magazin online bazat pe php/mysql e ca si cum ai crede ca daca iti pui costumul lui Superman o sa poti sa zbori. Google „PHP HipHop” ar trebui sa te lamureasca cum sta treaba. MySQL-ul pe care il downloadezi si il instalezi ca sa-l folosesti la Magento sau orice alt store nu e acelasi cu cel pe care il foloseste Facebook-ul. Cache la greu, 90% din hit-uri nici macar nu ajung in mysql, codul a fost rescris pentru specificul lor. Si degeaba scaleaza mysql-ul daca aplicatia care il foloseste nu stie sa distribuie cererile. Ca muti partea de comenzi pe alt server de mysql, comentariile si rating-urile pe altul e si asta o scalare dar una care isi va dovedi limitarile in curand.
Vai, sa-mi bag … au zis si de Mongo. Bai baietilor. 5k maxim investitia, in commodity hardware pe-un cluster pre-configurat si pre-testat inainte, de, sa zicem, 10 noduri, tine, scuzati-mi expresia, ca pi*da de tarf*lita comunala, intreg poporu’ de romani pe cel putin 10M interogari/s.
Suntem mai putini romani cu internet in Romania. Si mai putini care sa cumpere. Incetati cu aberatiile astea tampite. Pe bune.
nu vreau sa fac reclama dar noi pe asa ceva lucram: https://www.layershift.com/hosting/?utm_source=jaxldn2012&utm_medium=flyer&utm_campaign=jax
@kmlx, that’s cute, tell me more:
Questions since startup: 8,445,049,120
ø per hour: 20,876,456
ø per minute: 347,936
ø per second: 5,806
oricum isi scot mai mult decat dublu profit ….
Ceva cifre reale:
Totul pe un singur server web (hp dl120). Serverul cu mysql-ul este separat si acolo se foloseste intens sphinx. (+memcached si toate cele)
– 708.000 conexiuni active
– 856.000 request-uri pe secunda
Proof:
Daca e sysadmin bun costurile scad iar performanta este maxima.
Hai că până la urmă scrieţi un magazin online pe blogul lui zoso :)). O să fie mai ceva ca Interspire.
@Ionut: da, şi după aia il vindem. dacă toţi ăştia 4 îşi dedică 1 oră pe săptămână pentru asta, până la anul de black friday o o să fie gata si o să se pişe pe amazon ca scalabilitate
Mariane, calcul simplu: sa zicem ca raspunzi doar cu ceva static, deliram aici si zicem medie 1500 bytes per conexiune per user.
1500 Bytes * 856000 = 1284000000 = 1.19582GB/s (adica un NIC de 10Gbit la >90%, water cooled si cu 10 preoti in spate)
Hai sa lasam povestile, pl0x
ps: chiar si cu bonding, mi se pare exagerat.
@brian the dog: De asta ce zici ? (si nu este ora de varf)
–
root@web:~# vnstat –live
Monitoring bond0… (press CTRL-C to stop)
rx: 53.26 Mbit/s 122791 p/s tx: 3.02 Gbit/s 59214 p/s^C
root@web:~#
–-
mooama, numa hackeri pe blog la zoso
Singurul site care a fost constant online a fost cel al PCGarage.ro, care e adevarat ca arata uneori ca dupa razboi afisat fara nici o poza. Dar puteai intra pe el, da comanda si asta fara sa te crizezi de nspe mii de ori cu refresh-uri.
Deci eMAG, cel mai mare magazin online romanesc care face profituri de zeci de milioane de euro nu are 10.000 de Euro sa fie online 100% in cea mai importanta zi din an pentru vanzarile lor? eMAG care primeste sute de mii de euro de la furnizori pentru marketing, nu are bani sa stea online? Parca se laudau cu zeci de mii de comenzi, clientii aia i-au platit in nasturi si pioneze de nu-s in stare sa fie online?
Pai sa avem pardon, Amazon de UK, DE si FR rezista la milioane de accesari din tot UE si n-au nici pe dracu’. Alea sunt magazine online, nu impuscatori de franci ca eMAG.
Prea multe converastii tehnice. S-a prins cineva pana la urma ce faptul ca emag chiar a mers pe soluția Amazon pentru acest BF ?
@simistef
Emagul a fost gazduit de Hostway in Romania. Nu are nici o treaba cu Amazonul.