Slow webpage - need server load balancing hardware ?

Vezi un processlist in HeidiSQL la serverul tau cu tunnel ssh pe server, totusi e normal sa ai asa load la mysql, ar trebui sa vezi aceasi durata de executie la vreun proces activ si in processlist la heidisql. Daca ai slow query log activat ai o lista cu problemele.

La mysql iti trebuie neaparat innodb daca ai multe write-uri si trebuie sa ai grija la indecsi ca sa nu ai lock-uri aiurea.

Pe langa htop instaleaza http://guichaz.free.fr/iotop/ si pune o poza, in cazul tau n-ar trebui sa ai disk write la apache/php.

Judecand dupa screenshoturile adaugate de tine, pare destul de clar ca structura datelor si modul de interogare a acestora este partea care trebuie imbunatatita.

Daca te bazezi pe Eloquent sa genereze SQLurile in locul tau, aici e locul de unde as incepe curatenia. Este un lucru dovedit ca ORMurile nu sunt bune la acest lucru. cel mai recent moment cand m-am lovit de asta a fost acum cateva luni am intampinat aceeasi problema cu un proiect pe care l-am evaluat dpdv al codebase, tocmai pt ca si ei aveau probleme de performanta, si iti pot spune ca rescrierea interogarilor SQL pentru a fi executate direct din cod (fara a trece prin ORM) a imbunatati substantial executia.

Apoi mai trebuie vazut cum ai structurat entitatile in cod. Si aici se pot face mici schimbari cu impact mare.

Iti recomand neaparat sa citesti despre CQRS. Am scris recent un articol introductiv pe tema asta. Se refera la separarea cat mai mare a flow-urilor de scriere in DB si de citire. Pentru ca atunci cand scrii datele esti interesat sa nu faci procesari suplimentare. Daca acestea sunt necesare, foloseste o coada in care le pui si faci procesarile ulterior, fara ca acest lucru sa impacteze cel care face requestul initial.

Separarea partii de citire (interogarile, rapoartele, etc) pentru a fi executate de un cod diferit (posibil pe o baza de date diferita) ajuta extrem de mult la imbunatatirea substantiala ap erformantei aplicatiei.

3 Likes

Am observat acest lucru la documentatia lor:

(sursa).

Asta inseamna si ca se fac interogari deseori nenecesare. Pe langa alte lucruri nesanatoase pentru viteza de executie.

@binaryk ai instalat new relic? chiar sunt curios ce zice. In linii mari este un inceput bun pentru a gasi hot spots and fix them i.e. poate nu va fi nevoie sa schimbi framework-ul, arhitectura, instalat nginx etc.

@dakull am pus doar pe partea de browser acum abia, o sa pun si pe server un pic mai incolo. Acum configurez (incerc sa configurez) un e2c de la amazon.

:thumbsup:

front-end-ul deja nu prea arata foarte bine / ~3s sunt pierdute doar acolo.

Nu am inteles exact ce se misca greu la aplicatia ta insa daca e ceva legat pur de page-load poti face totul mai rapid cu aproximativ 2-2.5s.

De pe server:


Acum merge binisor, pentru ca am rugat un client sa opreasca traficul care omora tot.

Nu cred ca poti face mai rapid cum zici tu cu vreo 2 secunde din simplul motiv ca serverul e ocupat cu alte chestii - logica pentru alti clienti, si nu are timp sa-ti serveasca pagina, asa ma gandesc, oare nu zic bine ?

Page rendering si DOM processing se intampla strict pe partea clientului - daca optimizezi JS/CSS/HTML poti reduce considerabil din acea latenta.

Legat de network time - un CDN de tip CloundFront iti poate reduce puternic incarcarea asset-urilor pt. clienti din zone departate fata de unde ai deployed server-ul.

P.S.:

Pe langa server monitoring as instala si Laravel specific stuff:

1 Like

Merci frumos pentru implicare. Legat de assets, m-am gandit la CDN, dar mi se parea o chestie greu de implementat :slight_smile:, imediat termin cu ec2, sunt super curios cat o sa tina asta,

1 Like

De multă vreme nu am mai auzit ca cineva să ruleze o aplicație pe o astfel de arhitectură monolitică…
Părearea mea e că, în locul unui singur server de $640, mai eficient ar fi să distribui serviciile pe instanțe diferite. De exemplu:

  • 2 x $160 16GB RAM, 8 Cores, 160GB SSD - pentru Mysql cu Master->Slave replication
  • 3 x $80 8GB RAM, 4 Cores - pentru server-ele HTTP pe care rulează aplicația în sine
  • 1 x $40 4GB RAM, 2 Cores - un load balancer cu HAProxy (sau cu ce vrei tu)
  • 1 x $40 4GB RAM, 2 Cores - un server HTTP pentru resurse statice

Total: $640

Lista de mai sus e doar ficțiune, pentru că nu știu exact care sunt serviciile care folosesc cele mai multe resurse în cazul tău. Este, pur și simplu, o distribuție a bugetului care mi se pare mai eficientă decât ce ai tu în prezent.
Alternativ, unul dintre cele 3 servere pe care rulează aplicația ar putea fi folosit pentru procesări de fundal.

3 Likes

Avand in vedere ca @binaryk este relativ novice in *nix eu unul as merge pe Heroku + Heroku Postgres DAR doar dupa ce se rezolva hot spots din aplicatie.

Este clar ca nu exista o problema de buget insa KISS in zona de devops/sysadmin will save you lots of headaches in the long run.

Plus in loc sa pierzi timp setand AWS, arhitecturi scalabile - mai bine il folosesti to fix the app, then scale it on something simple and when all is working nice and you have the know how to migrate it to a classic scaling architecture created by you then just do it in | | :slight_smile: In the meantime, your clients will be ok whilst no data loss and random headaches bc. you have to google how to properly set-up a load balancer, shard the DB if necessary, tweak the caches, etc.)

1 Like

Te-ai gandit sa mai adaugi inca un layer intermediar atunci cand da clientul click, un messaging queue system, asta pana ajunge la procesare de date?
Din cate ai explicat despre ce face aplicatia ta imi pare o solutie plauzibila.

Toate bune!

Cea mai buna solutie a ta ar fi sa renunti la mysql si la php si sa inlocuiesti totul cu Spark + ceva stocare distribuita. Alternativ daca ti se pare prea complex rethinkdb si nodejs ar fi foarte elegant si usor. Mi-as mai putea imagina o solutie gen ArangoDB cu scripturi javascript in baza de date.

ArangoDB/Spark e foarte practic deoarece poti folosi direct grafuri unde e nevoie (relatia tata, copil, bunic, varfuri, cea mai scurta cale, cine cunoaste pe cine, structura grafurilor…) si baza de date e super rapida cu cache.

Nu de altceva dar asa iti deschizi posibilitatea sa faci analize mai complexe pentru clienti si pentru tine in viitor. Eventual daca moare proiectul din start ai in portofoliu un proiect cu Spark si din cate am vazut sunt companii care cauta si platesc gras pentru cei care stiu cu ce se mananca.

1 Like

Ce am facut pana la urma:

  1. Optimizari pe cat a fost posibil la nivelul interogarilor, unde aveam de procesat mult am introdus proceduri stocate si am incercat sa mai evit pe alocuri ORM-ul.
  2. Un prieten a configurat serverul de apache cu:
    client -> server (nginx -> varnish -> apache2) + nginx (SPDY).
  • acum zboara cu 2500 online in acelasi moment de timp
  1. Pe viitor, daca tot va creste, vom merge probabil pe o solutie similara cu a lui @IonutBotizan.

Multumesc pentru implicare.

Felicitari pentru optimizare. 2 chestii in plus pe care le poti folosi/verifica

  • sa te asiguri ca faci composer install -o, adica sa optimizeze partea de autoload.
  • foloseste blackfire.io pentru identificarea precisa a bottleneckurilor

p.s: php7 rules

1 Like

Da da, am implementat deja ceva de genu, cred ca am zis mai sus. :+1:

Neaparat, si cu php7 am avut ceva conflicte, in sistem era instalat, dar apache folosea 5.6 :slight_smile: pana la urma s-a rezolvat. Composer du -o, si composer optimize --force le folosesc.