This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Friday, 20 February 2004
Deadlocks... Ik haat de kleine klootzakken! Ik heb de hele dag geprobeerd om een 'issue' te repareren met een site die ik voor een klant heb ontwikkeld. Dit is een beetje vervelend omdat het een 'theoretisch' probleem is. In wezen heeft de klant ervoor gekozen om iets te doen dat ik normaal gesproken nooit doe, de bewerkingspagina's van de site te laden. Helaas, deze site heeft een oneven bewerkingssysteem - het gebruikt het concept van een 'gemeenschappelijke' tabellen om alle items te houden, ongeacht wat voor soort item ze zijn (dus het bezit alle gemeenschappelijke eigenschappen, met de verschillende eigenschappen worden gehouden in verschillende tabellen). Dit ontwerp geeft me een heleboel flexibiliteit - en laat me gebruik maken van een bos van gemeenschappelijke controles om de objecten op het display, voor veiligheid enz... Echter, het heeft een groot nadeel - om sommige items te bewerken betekent meerdere updates aan dezelfde tabel op een Use-Case - het heeft ook een paar geïndexeerde weergaven op dezelfde tabel. Dit heeft me geleid naar waar ik momenteel vind mezelf, als we meer dan zeggen 10 gelijktijdige gebruikers (dus, het creëren van 10 nieuwe items op precies hetzelfde moment, dan proberen om die dezelfde gegevens uit de DB te halen) Ik krijg dit na ongeveer 200 of zo herhalingen:
Transactie (Proces ID 74) werd geblokkeerd op lock resources met een ander proces en is gekozen als de impasse slachtoffer. Herrun de transactie.
Nou, ik heb hier de hele dag aan gewerkt, queries optimaliseren, nieuwe indexen creëren, triggers doden, data cachen in pagina's, alles... als gevolg dat ik een rotte hoofdpijn heb en eigenlijk alle objectiviteit heb verloren - ik heb geen idee of ik echt dingen heb verbeterd of niet!
Ook helpt het niet dat ik eigenlijk niet weet voor welk aantal gebruikers ik probeer te optimaliseren! Overigens heb ik berekend dat op basis van gangbare gebruikspatronen 10 gelijktijdige bewerkingen ongeveer gelijk zouden zijn aan ~1000 gelijktijdige 'view' gebruikers of ongeveer 144000 bezoekers per dag...umm..ja, dat is waarschijnlijk 100+ keer meer dan deze site krijgt op het hoogtepunt...
Oh, zou moeten zeggen, als iemand problemen heeft met de site vandaag, is dit de schuld - ik heb een lading testen als een gek ding en mijn arme server voelt de pijn ...
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.