Ik zag dat ik vorige week maandag geen artikel gepost had. Dan weet je dat je het druk hebt. Ook deze week weer, dus dit artikel gaat er even snel tussendoor.
Als het goed is zul je bij de vraag aan een developer wat hij/zij het moeilijkst vindt het antwoord krijgen: het schatten van uren. Want vaak moet je iets wat nog niet eerder gedaan is inschatten. Waarbij je bepaalde elementen wel kent, maar ook een aantal niet. Of die tijdens het ontwikkelen net anders blijken te zijn waar je dan weer extra tijd aan moet besteden. Een goede 2e op de lijst van "horror vragen" is om een applicatie die traag is weer op snelheid te krijgen. Want tijdens het bouwen hadden we 10 producten, maar inmiddels zijn het 2.455.000 stuks....
Morgen (22 november) zit ik in de Beurs van Berlage in Amsterdam, hier wordt Elasticon gehouden: link. Dat is midden in de stad, het is vroeg in de ochtend, dus het zal wel druk worden. Om 6 uur maar in de auto die kant op.
Oud-collega Dirk-Jan tipte ons dat dit event gehouden werd. Hij had in samenspraak met onze hosting-partner al eerder naar Elastic gekeken, Kibana-omgeving opgezet en daar ook APM in gekoppeld. Dus dit was een interessante conferentie voor hem geweest. Ware het niet dat de man een nieuwe baan heeft: hij werkt nu bij Init3.
Dat we "er iets mee moeten" doen, dat is wel duidelijk. Want er zijn genoeg developers de bij een bedrijf werken zonder monitoring. Bij mijn vorige werkgever waren ook wel projecten waar "traagheid" speelde. We gebruikten daar (als me niet vergis) Cacti om inzicht te krijgen: link.
Bij mijn huidige werkgever maken we gebruik van Zabbix. Een fantastisch product. Je kunt alles meten. Maar... het is alsof je vanaf de server waar Zabbix draait naar een black box kijkt: het duurt ineens 5 seconden om de homepage te laden terwijl anders 150 milliseconden de standaard responstijd was. Wat is er aan de hand? Geen idee....
En zo kan het pollen (wat Zabbix doet) jouw het beeld geven dat de tijd om data op te vragen nog wel oké is, maar als iemand "normaal" de site gebruikt en door verschillende type pagina's bladert kan hij/zij wel traagheid ondervinden. Niet optimaal dus.
Via onze oud-collega Teade werden we getipt over APM wat met Elastic werkt: link. Code toevoegen aan je project, paar zaken instellen en bam: je kunt zien welke flows doorlopen worden, hoe lang het duurt, welke database-query's uitgevoerd worden. En daardoor wat er lang duurt. En kun je onder andere indexen toevoegen aan je database (wat we als het goed is toch al deden). Maar nu gaan we misschien ook de code anders opbouwen omdat we zien dat als we het op een andere manier aanpakken er tig database-query's niet meer uitgevoerd hoeven worden.
Als je zoals ons wat hybride oplossingen hebt is dat trouwens nog niet altijd "de oplossing", want we zien soms een responstijd van 12 seconden, waar je van 6 seconden wel de query's e..d kunt bekijken, maar de resterende 6 zijn een grijs deel. Nou ja, probeer dan eerst maar wat we wel kunnen zien te fixen, dan komt dat andere deel later wel.
En nu ik toch aan het "name-droppen" ben, onze oud stagiair/afstudeerder Jeroen Smink (en toekomstig collega) heeft eens gekeken naar het gebruik van Elastic met zoekresultaten. Waar we nu in een "traditionele database" met tabellen, records, joins werken, zo werk je daar op een hele andere manier. En dat gaf fenomenale snelheden.
Hopelijk leer ik morgen veel bij, wat we zelf in praktijk kunnen brengen. 1 ding wat je sowieso zelf kunt doen, is tijdens het bouwen (als je in C# werkt, met het Entity Framework) om even een logger aan je DataContext te koppelen. Zo zag ik namelijk dat ik bij sommige mooie LINQ-constructies met loopjes werk en dat is fataal: meer dan 1.000 losse "SELECT" statements op je database. Als je 1x alles in een dataset in je geheugen zet, kun je daar op werken. Op die manier zorg je dat je code snel blijft en de hoeveelheid lees-/schrijfacties op je database beperkt.