Alvorens te lezen, toch volgende mededelingen:
- Alle ergernissen hieronder beschreven zijn mijn personlijke ergernissen en niet die van mijn werkgever.
- Ik viseer niemand, mensen die zich toch zouden aangesproken voelen beschikken blijkbaar over voldoende zelfkennis.
- Ik vind mezelf verre van perfect of alwetend, maar met de doorheen de jaren verworven kennis tracht ik toch het beste van mezelf te geven bij het realiseren van projecten
In mijn vorige post had ik het redelijk beknopt over de frontend ergernissen, maar laat ons vooral het geblunder van sommige backend developers niet vergeten. Frontend en backend zijn een tandem, 2 mensen die perfect moeten samenwerken en weten wat er waar moet gebeuren. Een site mag nog überclean gelayout zijn, met kraaknette w3 valide xhtml / css geschreven zijn, fancy javascript effectjes bevatten de grote dooddoener blijft SNELHEID.
Snelheid is dikwijls al de grootste fout bij vele developers. Soms werkt hun site traag, en meestal wordt de oorzaak geweten aan de “trage webserver”, bijgevolg worden klanten de kosten ingejaagd om zwaar te investeren in een energievretende killerserver die pagina’s serveert aan de luttele 5 bezoekers per dag.
Er kunnen verschillende oorzaken zijn, soms 1, mss 2, en soms is het helemaal in orde gedaan en zijn er 1001 zaken die van een slick site een lomp geheel maken.
Laat ons beginnen bij de basis, zijnde de database… Laat ons even de manual ter hand nemen. (Backend developers die nu mijn site verlaten, er bestaan wel degelijk manuals, en néén, deze zijn niet geschreven voor uw buurvrouw die weleens een stap op het wereldwijde web wil wagen, manuals zijn geschreven voor iedereen, en wél in het bijzonder voor diegene die zich goed genoeg achten om het zonder te kunnen.) Een goede database is genormaliseerd, beschikt indien nodig over de juiste relaties / tussentabellen en heeft vooral velden die geoptimaliseerd zijn voor de inhoud. Ok, je kan al je data opslaan in varchars, text of BLOB velden, dan heb je “plaats genoeg”, maar dan verlies je het doel van je database uit het oog.
De juiste velden gebruik je om:
- de juiste data te kunnen uitlezen en op QUERY niveau te kunnen filteren (datums selecteren op MONTH, etc…)
- de juiste data te kunnen inserten en laten valideren op DATABASE niveau
Als voorgaande punten al goed zitten, petje af, een bank vooruit en een kus van de juf! Op naar de volgende vaak voorkomen fout, zijnde te véél queries. Data selecteren is 1 ding, maar data filteren, grouperen en sorteren gebeurt op database niveau. Zaken als DISTINCT, GROUP BY, ORDER BY, ASC, DESC, JOIN, INNER JOIN, OUTER JOIN, … zijn geen fancy sql commando’s. Maar al te vaak wordt data uitgelezen, in een array gepompt om die op zijn beurt te sorteren / filteren, door te loopen en per loop nogmaals een query afvuren, performantie troef. Mensen die dit doen zouden moeten verplicht worden om enkel genoeg benzine in hun tank te doen tot aan het volgende tankstation, zodat ze mss het concept snappen. De pipeline tussen de webserver en database server is klein, zeer klein. Zorg er dus voor dat je niet méér dan de benodigde data terugkrijgt. Net zoals schoenen kopen weet je ook welke maat je nodig hebt (of mss 2 maten), welke kleur, mannen of vrouwenschoenen, etc… De verkoper alle schoenen laten aanrukken én ze vervolgens 1 voor 1 passen zou een beetje overhead zijn, niet? (voor sommige vrouwelijke lezers, ik veroordeel je niet als je de voorgaande stelling niet snapt). Voor diegene die Roger van Dobbit magazine kennen, vergeet zijn wekelijkse stelling. “Wat je zelf doet, doe je beter” klopt voor geen vliegende meter als het op databases aankomt.
Voor de betweters die bovenstaande stellingen zouden benchmarken, ga uw gang. Een vertraging van 0,2 ms is niet veel voor 1 record, maar wat bij 10.000 records?
Het programmeren op zich kan nog op 1001 vlakken fout gaan, teveel om op te noemen. Misschien volgende zaken toch in het achterhoofd houden:
- Object Oriented programmeren is vandaag de dag HOT, het maakte zijn opmars begin de jaren 90 maar het principe bestaat al van in de jaren 60. Het is niet omdat je volgens OO programmeert dat je een kickass developer bent. Bekijk OO design patterns, snap alle principen (inheritence, abstraction, encapsulation, polymorphism, decoupling)…
- Frameworks zijn geschreven om het leven te vergemakkelijken, gebruik ze dan ook indien mogelijk.
wordt vervolgd
Tags: database, framework, frustratie, object oriented, webdevelopment
Ik sta er altijd van versteld als ik een niet-genormaliseerde database in een live-applicatie ontdek.
Hoe kunnen mensen geld uitgeven aan een webmaster/bedrijf dat niet eens weet hoe je deftig de database opstelt..
Hoe?
Omdat de klanten van zo’n bedrijven zelf niks afweten van databases. Bedrijven kan drie vierden van hen clienteel belletjes wijsmaken over zo’n dinge. “Uw server is te traag” en de kous is af.
Ook niet vergeten hoe stampvol met startups zo’n markt zit, gasten die het zelf niet goed weten, of het personeel niet kunnen veroorloven die de correcte know-how en expierence hebben. Sta er ook bij stil dat deze markt, vooral de web-apps markt een zeer jonge markt is en het aanbod voor een werkgever op vdab.be niet overloopt van getalenteerde ervaren backend devs. Zakken schoolverlaters die enkel OO kennen dat hun docent zelf nog maar net onder de knie heeft.
Dagelijks zie je dergelijke fouten, zelfs mensen die al jaren in het “vak” zitten maken ze nog.
Het is wel goed dat er aangehaald wordt dat het belangrijk is om goeie SQL te schrijven!
Veel performantie problemen zijn afhankelijk van slecht geschreven SQL en eenmaal die statements in de final code zitten worden ze er zelden nog uitgehaald.
Een database is geen “Magic Box”. Je krijgt wat je vraagt en op een slechte vraag kan je dikwijls een slecht antwoord verwachten…
Ik ben van mening dat veel verholpen kan worden door developers een extra opleiding te geven over hoe ze moeten samenwerken met een database.
Natuurlijk ligt het hele performantie probleem niet alleen bij slecht geschreven SQL.
Elke database heeft onderhoud nodig. Een database is geen statisch gegeven, een DB wordt elke dag gewijzigd en ondergaat veelal een sterke groei. Veel is afhankelijk van het design (normalisatie), indexering, statistieken, gebruik van bepaalde technieken, …
Het is ook geen schande om een stuk van de backend code in de database te integreren (bvb triggers, functions, procedures, packages, … op DB niveau)
Database systemen worden ook verder door ontwikkeld en zijn verre van bug vrij, dus updates van deze component zijn ook van levensbelang.
Door de huidige kostprijs van hardware, memory en storage wordt dikwijls voor een gigantische server gekozen door onkunde van de betrokken personen en omdat de kostprijs voor onderzoek en optimalisatie van een applicatie regelmatig hoger ligt dan het vervangen van een server. Hierdoor worden alsmaar meer de symptonen aangepakt en niet de oorzaak van het probleem!
De echte miserie begint dan pas op lange termijn.
Een performantie probleem kan overal zitten, zelfs buiten de eigenlijke applicaties. Denk maar eens aan crappy client pc’s, netwerk problemen, …