Argumente
de netăgăduit

“Unii inţeleg ce pot, cei mai mulţi ce vreau.” – Nicolae Iorga

Acum că aveam şi numele era momentul să caut şi un provider care să găzduiască situl. Nu a fost greu, deoarece aveam o oarecare experienţă cu provider-ii români. Situl publionline.ro era deja online de mai bine de un an.

Astea fiind zise, situl a acostat în portul celor de la Rohost, unde era găzduit şi situl frate (sau trebuia să spun “soră”?).

Toate bune şi frumoase până în momentul în care au început să apară primele probleme. Am început să primesc notificări tot mai dese cum că situl consumă multe resurse. A început un şir interminabil de optimizări şi de discuţii (inutile, cred, cu cei de la Rohost). Sunt profesionişti adevăraţi, dar au avut o mică problemă de atitudine în momentele acelea. Am primit un prin mail (eu nu ştiam absolut nimic despre eventualele probleme!) pe care il voi lista aici:

From: ROHOST Tech …@rohost.com
Date: Mon, 13 Jun 2005 23:34:29 +0300
To: …@berg-computers.com
Subject: incarcare server

> Buna seara,
>
> Astazi server-ul pe care se afla contul reseller r5376.rohost.com a avut
> o zi “incarcata” din cauza mysql-ului abuzat.
>
> Load-ul a fost generat in principal de site-urile publionline.ro si
> anunturi-gratuite.ro, singura lor “vina” fiind ca sunt vizitate si ca
> folosesc mysql. Transmit atasat log-ul de slow query-uri pana la ora
> 21:20, cand server-ul a fost “pus la pamant” de un crawler care incerca
> sa aduca site-ul anunturi-gratuite.ro, servirea in paralel a catorva
> sute de request-uri combinate cu query-uri de mysql de pe acest site
> fiind mult prea mult pentru un Dual Xeon cu 2 GB memorie.
>
> Dupa ce veti citi slow_queries_danic_0613.log si statistica lor:
> slow_queries_danic_0613s.log, speram ca veti ajunge la concluzia ca
> 161142 row-uri parcurse la aproape fiecare accesare a site-ului ( un
> simplu exemplu care se repeta in log-uri: # Query_time: 7 Lock_time: 0
> Rows_sent: 2 Rows_examined: 161142 – select date_format(cr_datetime,
> “%d-%m-%Y”) as dtDate, NUME_ZIAR, LINK_ARTICOL, STIRE from
> tbl_revista_presei order by cr_datetime desc, rand() limit 2; )
> nu este de dorit pentru site-uri cu mii de accese zilnic si nu trece
> neobservat de ceilalti clienti de pe server.
>
> In concluzie, va rugam sa corectati urgent indexarile bazei de date si
> sa apelati la ajutorul unui programator avansat in baze de date care sa
> va ajute la indexarea/optimizarea tabelelelor si a query-urilor
> folosite. Singura varianta alternativa este cea a unui server dedicat.
>
> In cateva zile va fi pus pe picioare un nou server in locatia New York,
> vom muta contul reseller pe acest nou server pentru a evita viitoare
> probleme pe server-ul actual. Speram sa rezolvati rapid problemele de
> mysql pentru a putea colabora in termeni buni ca si pana acum.
> Statisticile WHM pentru consumul de resurse de astazi, 06-13, media este
> de 3,5 procese mysql:
>
> User Domain %CPU %MEM Mysql Processes
>
>
> danic publionline.ro 5.13 3.94 0.9
> Top Process %CPU 17.0 httpd [www.publionline.ro]
> [/matrimoniale/im.php?actioncheck&rand1118674253859]
> Top Process %CPU 14.0 httpd [www.publionline.ro]
> [/matrimoniale/im.php?actioncheck&rand1118689906053]
> Top Process %CPU 2.2 httpd [www.publionline.ro] [/images/bottom_3.gif]
>
>
> danic21 anunturi-gratuite.ro 3.48 3.90 2.6
> Top Process %CPU 31.8 httpd [www.anunturi-gratuite.ro]
> [/recomanda-anunt-824.html]
> Top Process %CPU 18.8 httpd [www.anunturi-gratuite.ro]
> [/educatie-invatamant/]
> Top Process %CPU 9.0 httpd [www.anunturi-gratuite.ro]
> [/afaceri/comert/ejaculare-precoce-stop-www-sexshop-a2996.ht]
>
>
> si de ieri, duminica, 06-12, cand site-urile nu au fost atat de
> vizitate, atingand totusi o medie de 1,2 procese mysql:
> danic publionline.ro 3.96 2.91 0.4
> Top Process %CPU 35.0 httpd [www.publionline.ro]
> [/matrimoniale/images/menu__b4_over.gif]
> Top Process %CPU 29.0 httpd [www.publionline.ro] [/catalog_firme.php]
> Top Process %CPU 15.8 httpd [www.publionline.ro]
> [/matrimoniale/images/menu__b5_over.gif]
>
>
> danic21 anunturi-gratuite.ro 1.68 2.14 0.8
> Top Process %CPU 9.0 httpd [www.anunturi-gratuite.ro] [/auto/]
> Top Process %CPU 7.0 httpd [www.anunturi-gratuite.ro]
> [/servicii/servicii/]
> Top Process %CPU 6.0 /usr/local/bin/php fake_cron.php
> starwars starwars.ro 1.68 2.63 0.0
>
> —
>
> Numai bine,
>
> Tudor Vaida
> ROHOST Tech

Am început să optimizez. Situl chiar avea probleme grave cu interogările pe baza de date. Am rescris TOATE interogările. Am reuşit să scad considerabil timpul de execuţie al interogărilor (query-uri care durau înainte 3-4 secunde, acum se executau în mai puţin de o zecime de secundă). Şi totuşi nu era destul. Cred că nu mai eram privit cu ochi buni de către cei de la Rohost. Nu am acceptat oferta de a găzdui situl pe un server dedicat (oferta a fost cât se poate de pertinentă – CPU: Intel Celeron 2.4GHZ, Memorie: 512MB DDR RAM, Hard Drive: 60GB IDE sau 18GB SCSI, Bandwidth: 2000GB/MONTH, Pret: 110 USD + TVA – dar nu o puteam accepta din cauza lipsei de fonduri). Date fiind condiţiile enumerate, îmi era destul de clar că venise vremea să îmi caut un alt provider pentru a îmi găzdui siturile.

Oferte peste oferte… Unele făcute de către profesionişti adevăraţi, altele de către copii care abia ieri îşi încropiseră o firmă de găzduire. Un kucru ciudat era faptul că marea majoritate dintre ofertanţii demni de luat în seamă aflase deja despre “căruţa de resurse” pe care o ocupa situl (citatul e dintr-o sursă al cărei anonimat prefer să îl păstrez). Nu fac nici un fel de speculaţie. Probabil că din respect pentru Rohost, fiecare a întrebat despre cauzele care m-au determinat să mut situl la alt provider (în perioada respectivă, situl avea un trafic constant de 4500-5000 de vizitatori unici pe zi, deci era deja consacrat).

Vorba multă, sărăcia omului. Într-un final am ales HostAge, acelaşi provider care găzduieşte şi în prezent situl publionline.ro. Lucrul care mi-a plăcut cel mai mult la cei de la HostAge a fost pragmatismul. Interesant a fost că, până în momentul în care situl a fost mutat la cumparatori, nu a apărut nici un fel de problemă. Ba da, a apărut o mică problemă: conexiunile persistente la baza de date. La momentul vânzării sitului, l-am întrebat pe Cosmin Stănescu (persoana cu care comunic la HostAge) despre cum s-a comportat situl cât timp a fost gâzduit la ei. Mi-a răspuns că nu au fost probleme cu el. Nu tu “slow-queries”, nu tu “resurse consumate”. Cât despre concluzie, ar fi absurd dacă aş fi eu cel care ar trage-o.