Twitter
Facebook
RSS
BloggerSpre deosebire de majoritatea firmelor de gazduire am decis sa activam global doua module de Apache considerate putin periculoase intr-un mediu de hosting datorita eterogenitatii website-urilor: mod_security si mod_pagespeed. Primul ofera securitate suplimentara si impiedica unele atacuri des intalnite, blocheaza "botii rai", etc. Este un mic firewall la nivel de aplicatie. Al doilea automatizeaza optimizarile necesare pentru o incarcare mai rapida a website-urilor: compresie GZIP (este cuplat cu mod_deflate), minimizeaza CSS-urile si JavaScript-urile, le si combina in mai putine fisiere iar cele scurte le insereaza inline, incearca sa le incarce ultimele pentru a nu bloca inutil randarea paginii, prelungeste caching-ul (activat de mod_expire), rescrie unele URL-uri, etc.
De aceea codul generat este diferit. Iar .js-urile suplimentare sunt inserate tocmai pentru a gestiona unele dintre aceste functii. O mentiune aici: fisierele si bazele de date nu sunt afectate sau modificate sub nici o forma, toate acestea se intampla "on-the-fly", la acces, si este doar ceea ce primeste browser-ul. Cu pretul unei incarcari mai mari a server-elor, dar asta nu conteaza pentru ca ne priveste.
Ca sa verificati daca mod_pagespeed afecteaza afisarea paginii sau sa vedeti cum arata si se comporta site-ul fara acesta introduceti dupa numele website-ului ?ModPagespeed=off astfel incat link-ul sa fie de forma: http://www.quanta-group.ro/?ModPagespeed=off . Daca eroarea persista inseamna ca are legatura strict cu codul website-ului deoarece pagina este livrata normal si nu prin modul. Apropos poate fi dezactivat complet fara probleme, printr-o singura directiva in virtual host sau direct in .htaccess. Valabil si pentru mod_security.
Iar pentru a afla daca mod_security este vinovat de un anumit comportament verificati log-urile server-ului web si daca pentru IP-ul dvs vedeti ca acesta s-a activat, la ora si data in consecinta, ne furnizati ID-ul regulii cu pricina pentru dezactivare.
Dar de ce folosim cele doua module? Pentru ca sunt necesare, iar majoritatea site-urilor gazduite sunt realizate de noi, deci cam stim ce facem. De extra securitate oricum are nevoie toata lumea, iar de optimizarile de baza sunt scutiti toti cei gazduiti de Quanta. Sunt module la care au contribuit si pe care le folosesc Google (chiar autorul a mod_pagespeed) si Facebook de exemplu. Totusi desi sunt bine testate si verificam functionarea noilor domenii, nu putem acoperi toate situatiile posibile. Este suficient un telefon sau un email pentru a rezolva urgent problema intampinata prin dezactivarea fie particulara, fie pentru intreg domeniul a functiilor care cauzeaza probleme.
NginX, Varnish? Am decis sa nu folosim deocamdata aceste tehnologii excelente de altfel pentru ca server-ului web nginx ii lipsesc momentan cam multe functii (hint: ati vazut cum arata un .htaccess pentru un wiki?) plus o oarecare robustete si versatilitate a Apache-ului; folosite ca reverse proxy, valabil si pentru Varnish, in fata server-ului web, nici asta nu prea este perfect in regula pentru noi. Pentru ca... AwStats, log-uri, panou de control, altele. Si invariabil ajungi sa cache-uiesti doar continutul static altfel vei servi un acelasi continut vechi al site-ului, sau aplicatiile complexe in php trebuie sa aiba plugin-uri pentru a controla cache-ul, probleme si costuri suplimentare pentru cei gazduiti. Normal ca CMS-urile functioneaza cu acestea dar nu fara interventii, ori ale noastre ori ale clientilor, ceea ce este inacceptabil.
De fapt un fisier static in cel mai rau caz introduce o latenta de 5ms in medii asemanatoare cu al nostru unde sistemul de operare cache-uieste in intreg RAM-ul (in acest scenariu este exclus accesul la disc, evident), pe cand un script php... de ce nu 500ms? Asa ca rezultatele bune sunt obtinute mai degraba invers, incarcarea mare a CPU si latentele apar la procesarea scripturilor, exact in site-urile dinamice. Sau folosit un CDN.
Vom mai micsora diferenta indiscutabila si cand trecem la Apache 2.4 si event MPM plus ca deja oferim php 5.5 care include default acum Zend Opcache. Dar acestea sunt valabile doar cand faci gazduire si ai pe un server 100+ website-uri diferite, dinamice, gestionate si de catre clienti. Daca administrezi doar cateva insa, de care te ocupi personal, care au incarcare mare, sau esti intr-un VPS - go Nginx & Varnish!
NginX, Varnish? Am decis sa nu folosim deocamdata aceste tehnologii excelente de altfel pentru ca server-ului web nginx ii lipsesc momentan cam multe functii (hint: ati vazut cum arata un .htaccess pentru un wiki?) plus o oarecare robustete si versatilitate a Apache-ului; folosite ca reverse proxy, valabil si pentru Varnish, in fata server-ului web, nici asta nu prea este perfect in regula pentru noi. Pentru ca... AwStats, log-uri, panou de control, altele. Si invariabil ajungi sa cache-uiesti doar continutul static altfel vei servi un acelasi continut vechi al site-ului, sau aplicatiile complexe in php trebuie sa aiba plugin-uri pentru a controla cache-ul, probleme si costuri suplimentare pentru cei gazduiti. Normal ca CMS-urile functioneaza cu acestea dar nu fara interventii, ori ale noastre ori ale clientilor, ceea ce este inacceptabil.
De fapt un fisier static in cel mai rau caz introduce o latenta de 5ms in medii asemanatoare cu al nostru unde sistemul de operare cache-uieste in intreg RAM-ul (in acest scenariu este exclus accesul la disc, evident), pe cand un script php... de ce nu 500ms? Asa ca rezultatele bune sunt obtinute mai degraba invers, incarcarea mare a CPU si latentele apar la procesarea scripturilor, exact in site-urile dinamice. Sau folosit un CDN.
Vom mai micsora diferenta indiscutabila si cand trecem la Apache 2.4 si event MPM plus ca deja oferim php 5.5 care include default acum Zend Opcache. Dar acestea sunt valabile doar cand faci gazduire si ai pe un server 100+ website-uri diferite, dinamice, gestionate si de catre clienti. Daca administrezi doar cateva insa, de care te ocupi personal, care au incarcare mare, sau esti intr-un VPS - go Nginx & Varnish!
