6 Comments

  1. Excelent articolul si e bine ca in coltisorul nostru de lume cineva se gandeste si la optimizari. As face niste mici comentarii si completari pe marginea acestuia.

    1. La punctul 2, redundanta aceasta, asa cum este ea descrisa, se numeste denormalizare in terminologiile RDBMS. In general este utila atunci cand normalizarea (procesul invers) este exagerat sau cand se foloseste un sistem de baze de date neperformant la join-uri (de ex. mysql)
    2. Citirile intensive pe tabele frecvent actualizate (cum e in cazul exemplului cu actualizarea numarului de afisari si sortarea in functie de aceasta la citire) se pot realiza in sisteme moderne folosind separatia izolarii tranzactiilor (SQL Server, Oracle etc.) intr-un mod perfect transparent (nu e necesar sa se modifice codul SQL existent). Chiar si in cazul mysql se poate folosi un engine mai orientat catre tranzactii (InnoDB de exemplu in loc de MyISAM) si astfel nu se va face lock pe toata tabela ci doar pe rand.
    3. „Cache logic la nivelul bazei de date” se numeste in terminologiile RDBMS agregari si tind spre cuburi OLAP asa cum sunt descrise. In cazul in care aplicatia este puternic orientata catre analize de date este recomandat sa se foloseasca un engine dedicat pentru asa ceva, scurtand timpul de dezvoltare, micsorand numarul de bug-uri si marindu-se performanta sistemului
    4. Un framework pentru aplicatia web poate introduce un cost de executie suplimentare sensibil doar in cazul mediilor interpretate fara opcode caching (ex php chior). Pentru mediile compilate (ASP.NET, Java etc.) costul suplimentar este de nivelul catorva nanosecunde (miliardimi de secunda) per thread = nesemnificativ. Insa chiar si mediile interpretate (Perl, php, python etc.) pot beneficia de un cache de opcode cum ar fi APC sau Zend Accelerator.

    Personal prefer introducerea unui cache / alte solutii de accelerare decat renuntarea la un framework de lucru. Asta pentru ca fara unul, dezvoltatorii vor crea un mare ghem de cod care pe masura ce creste ajunge de neintretinut si deseori asa apar rescrierile de aplicatii (situatie tare nasoala si costisitoare in viata unui proiect).

    As si niste mici completari privind incarcarea fisierelor la client :
    • Fisierele javascript ce fac parte din anumite framework-uri de client (jQuery etc.) pot fi incarcate si de pe CDN-uri ale unor companii mai mari (Microsoft, Google etc.) avand avantajul ca au datacenter-e in multe puncte din lume, asigurand, pe langa descarcarea serverelor proprii (asa cum bine ai mentionat), si apropierea geografica si comunicationala fata de client
    • Fisierele CSS au un tratament similar privind cele JS cu mentiunea celor JS proprii – i.e. nu prea poti (ieftin) sa iti gazduiesti pe un CDN fisiere CSS proprii. Poate poti gasi vreun CSS de resetare dar cam atat.

    In final mai adaug doar ca as fi considerat oportuna o mentiune ca anumite recomandari sunt specifice php/mysql (cum ar fi modul delayed / low_priority, costul de procesare in cazul folosirii unui framework etc) si faptul ca s-ar putea vorbi de ferme de server-e web si distributia incarcarii pe acestea in mod dinamic.

  2. Daniel Buca

    @Andrei Rinea
    Multumesc si eu pentru comentariu.
    Intr-adevar, articolul este orientat catre dezvoltatorii LAMP pentru ca in aceasta zona sunt si cei mai multi dezvoltatori dar si cele mai multe probleme.
    Constraint-urile pe care le impune .Net sau Java te ajuta sa eviti o parte din problemele descrise in articol.

    Legat de folosirea unui framework: depinde foarte mult si de proiectul pe care il dezvolti desi la high level projects este indiscutabila folosirea unuia.

    Voi updata si articolul cu cateva completari :)

    Nu in ultimul rand: ma bucur ca exista oameni receptivi si la astfel de articole 😉

  3. Interesant articolul…dar nu tot, pentru ca sunt unele chestii care nu le inteleg. De recomandat ar fi si cel putin un exemplu pentru fiecare chestiune.
    Oricum, este de retinut.
    Merci!

Leave a Reply