eMAG

joi, 26 august 2010

CSS is case-sensitive

Azi am avut o mare bataie de cap. La site-ul la care lucrez am fost nevoit sa schimb HTML DOCTYPE-ul cu, < !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> in loc de < !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

Surpriza, dupa aceasta modificare o parte din design-ul pagini nu a mai aratat la fel.
Bine-nteles dupa ce am sapat prin cateva sute de linii de HTML si alte cateva mii de linii de CSS sa vad ce ar putea influenta aplicarea stile-urilor am zis ca nu mai lucrez pe front-end niciodata.

Cand colo problema a fost una de case-sensitive. In fisierul CSS clasa era scrisa intr-un fel, iar in codul HTML unde era folosita clasa era scrisa in altfel, toata diferenta a fost intre un b si B.

Deci daca aveti probleme de CSS, verificati mai intai daca numele clasei este scris la fel in css si html.

vineri, 20 august 2010

DotNetNuke DataBase Performance Issue

Am avut de-a face cu optimizari pe baza de date de la DotNetNuke Framework.
Mentionez ca lucram pe o versiune mai veche si anume DNN 4.8.3.
Am constatat probleme de performanta la view-ul vw_Modules, mai exact la urmatoarea linie:

WHERE 'fileid=' + convert(varchar,dbo.Files.FileID) = TM.IconFile

acolo unde este folosit acest view (cazul meu fiind procedura GetModuleByDefinition), cauzeaza logical reads mare pe tabela Files.

Asa ca am inlocuit acel WHERE cu:

WHERE dbo.Files.FileID = case when TM.IconFile like '%=%' then right(TM.IconFile, charindex('=', reverse(TM.IconFile))-1) else 0 end

Acesta din urma utilizand corect indecsii pe tabela Files.

joi, 19 august 2010

Extrage nume de fisier cu T-SQL

Această functie TSQL demonstreaza, de asemenea, utilizarea de a gasi ultima aparitie a unui caracter dat, prin utilizarea functiei REVERS. Mai jos este codul TSQL:

Create function dbo.udf_GetFileName(@m_FilePath varchar(255))
Returns varchar(50)
as
Begin

return right(@m_FilePath, charindex('/', reverse(@m_FilePath))-1)

End

Acum sa testam functia:

select dbo.udf_GetFileName('http://www.google.ro/intl/en_com/images/srpr/logo1w.png')

Rezultat:

logo1w.png

Explicatie pentru linia right(@m_FilePath, charindex('/', reverse(@m_FilePath))-1)

reverse   - intoarce reversul unui string

charindex - intoarce pozitia unui substring intr0un string

right - intoarce primele n caractere dintr-un string de la dreapta la stanga

Deci functia noastra intoarce primele caractere din path citit de la dreapta la stanga pana la pozitia ultimului '/'

marți, 3 august 2010

De ce alegerea tipurilor de date este atat de importanta?

Sunt si eu un dezvoltator de aplicatii web si nu de putine ori am fost nevoit sa fac optimizari pe baza de date.
O data cu cresterea traficului apar si problemele si atunci suntem tentati sa apelam la tot felul de subterfugii sau artificii pentru a obtine performanta necesara.
Putini insa se gandesc ca problemele cele mai mari vin de la tipurile de date folosite si felul cum procesam aceste date.

Aici intervin urmatoarele situatii:
  • alegerea tipului de data prea mic
  • alegerea tipului de data prea mare
  • alegerea tipului de data incorect
Daca alegem un tip de data prea mic s-ar putea ca la un moment dat sistemul nostru sa nu satisfaca nevoile necesare pentru a functiona corect sau pentru a fi util.
Daca alegem un tip de data prea mare in primul rand sistemul va folosi mai multe resurse de cat va fi necesar, asta inseamna ca va fi un sistem mai costisitor si nu in ultimul rand vom avea probleme de performanta.
Daca tipul de data este ales incorect atunci vom avea probleme de performanta datorita necesitatii aplicarii a prea multor conversii de tip.

Cel mai des caz intalnit este cel in care este ales un tip de data prea mare iar partea si mai nasoala este cand avem date redundante pe tipuri de date prea mari.

Cum sunt afectate performanta si costurile unui sistem cu astfel de probleme!?
In primul rand un tip de data mai mare foloseste mai mult spatiu in cache (RAM), rezultand o folosire mai mica a cache-ului si mai multe operatii I/O pentru actualizarea cache-ului. Procesorul de asemenea devine mai utilizat datorata timpul mai mare de actualizare.
Totodata parcurgerea indecsilor definiti pe tipuri de date prea mari  va creste si mentenanta lor si a intregii baze de date.
Toate acestea duc la necesitatea unui hardware mai performant, costuri mai mari pentru trafic de date mai mare, pachet pentru hosting mai scump si asa mai departe.

Iata cateva din cazurile de tip de data prea mare la care se greseste foarte des:
  • datetime si smalldatetime unde datetime este un tip de data mult mai precis folosit "by default" de multi dintre programatori dar cu siguranta fara a fi nevoie, deci acolo unde nu aveti trebuinta de informatii despre milisecunda folositi smalldatetime
  • Data type Range Storage/Accuracy
    datetime January 1, 1753, through December 31, 9999 4 Bytes/3.33 milliseconds
    smalldatetime January 1, 1900, through June 6, 2079 2 Bytes/1 minute
  • tinyint, smallint, int si bigint este iar un caz interesant. Aparent e simplu, alegem tipul de data pentru intervalul de care avem nevoie. Insa atunci cand avem o cheie primara sau un non-cluster index pe acest tip de data, este bine sa alegem tipul cel mai mic din lista cu putinta. Aceasta pentru a obtine un timp mai mic la intretinerea indecsilor. Ne putem gandi si la faptul ca in urmatorii 5 ani poate aplicatia nu va atinge valoarea maxima pe tipul de data ales si e mai bine sa avem performanta mai mare in aceasta perioada si ulterior daca e nevoie sa facem update la tipul de data.
  • Data type Range Storage
    bigint -2^63 (-9,223,372,036,854,775,808) to 2^63-1 (9,223,372,036,854,775,807) 8 Bytes
    int -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647) 4 Bytes
    smallint -2^15 (-32,768) to 2^15-1 (32,767) 2 Bytes
    tinyint 0 to 255 1 Byte
  • (n)char, (n)varchar, (n)varchar(MAX) si (n)text evitati pe cat posibil text si ntext, iar daca textul are tot timpul o lungime fixa folositi char(n)
Deci optimizati tipurile de date cu atenţie, deoarece acestea au un impact enorm asupra I/O, CPU şi consumului de RAM.