Snelheid

Johan,
Je vraag om concrete aanwijzingen kan ik helemaal begrijpen. Ik hoop dat ik je hier er één geef.
Gisteravond heb ik een vraag over een niet werkende buitentemperatuurmeter geplaatst ( www.volvo700vereniging.nl/?q=node/11039 ). Toen ik erachter kwam dat het gewoon een zekering zal zijn wilde ik gelijk die schaamte van mij afschrijven en dat op de site plaatsen. Het versturen van deze opmerking duurde een minuut of 6. Lekker gewacht totdat het draadje weer terugkwam en toen bleek dat er inmiddels twee andere berichten vóór mij geplaatst waren in de tijd dat ik bezig was met het tikken van mijn 'schaamverhaal.
ik heb enige ervaring met databaseproblemen (dit is een understatement) en dit soort wachttijden worden echt nooit, maar dan ook helemaal nooit, veroorzaakt door slechte hardware, maar altijd door locks.
Hoe wordt het record/de records van een draadje dat door meerdere mensen tegelijk wordt gelezen en/of bewerkt in de database behandeld? Het lijkt mij dat daar sinds een paar weken een probleem is ingeslopen. Ik heb een keer gezien dat door het lock-schema van een database iets aan te passen een applicatie van retetraag naar supersnel veranderde.
Ik hoop dat je er iets aan hebt.
groet
 updated: het plaatsen van dit bericht ging binnen een seconde!

Hej Bart
Updates worden altijd op de een of andere manier gelocked vanwege data integriteit, niks mis mee. Wat me aan jouw verhaal opvalt is dat anderen in de tussentijd wel een update hebben kunnen doen en dus blijkbaar de lock hadden, da's vreemd.. kan een aanwijzing zijn.
Toch verklaart dit nog niet alles. Ik neem aan (en merk zelf) dat ook lees acties traag zijn, gewoon een pagina opvragen. Daar zijn geen locks voor nodig. Bovendien, locking gebeurt op database nivo en heb ik geen invloed op als applicatie.
De site loopt al 2+ maanden vrijwel zonder wijzigingen, ik herken dus geen relatie met recente wijzigingen. De hickups van de afgelopen anderhalve week zijn altijd tussen de middag of tussen 22:00 en 01:00, hobby prime time dus, dat kan load op onze site zijn maar ook op andere hobbysites op dezelfde server. Op andere momenten loopt de site als een speer. Er zijn wel een aantal queries die nu de database groter wordt wat tuning kunnen gebruiken. Als je daar je ervaring in zou kunnen brengen, graag!
Het is met dit soort problemen zaak om objectieve gegevens te verzamelen en dan pas conclusies te trekken anders blijft het gokken en weet je nooit of je een symptoom of een oorzaak aan het aanpakken bent. En iedere poging om het probleem op te lossen verandert mogelijk het probleem zelf weer..

Dat je voor lezen geen lock nodig hebt klopt, maar een gelocked record lezen lukt natuurlijk niet. Het kan ook zijn dat het lezen van een record een write prevent lock zet. dat kost ook tijd en kan bij multi-user gebruik problemen opleveren.
Dit alles verklaart niet het optreden van deze problemen zonder dat er nieuwe zaken aan de site zijn gedaan. Ik ben geen dba-er, maar heb wel veel ervaring met het schrijven van queries in een Oracle omgeving. De wachttijd die ik gisteren tegenkwam kan echt alleen van een lock komen, serverload kan een proces niet zoalng ophouden: dan krijg je een timeout error. De server hield al dir tijd keurig contact met mijn client, als het een loadprobleem zou zijn valt die verbinding weg en krijg je een error-scherm. Hoeveel transacties (read/insert/write) zijn er op de drukke uren?
Ik wil graag mijn steentje bijdragen als ik iets kan betekenen. Al is het maar een nieuwe blik op de zaak. Over dit soort zaken praten met iemand vanuit een andere benadering kan soms zaken oplossen. Hoe kunnen we dat aan de vork prikken?
groet 

Voor de volledigheid zal ik maar melden dat Bart en ik samen op de zelfde tijd, met hetzelfde item hebben zitten stoeien.Ik heb daar ook melding van gemaakt, zie ergens hierboven.
Kan het zijn dat de database dat niet tof vindt, als je met zijn tweeen tegelijk een edit knop indrukt? 

Enkele weken geleden is mij dat ook opgevallen.
Je post iets en ineens is het 9 minuten later.
 [edit : als ik dus iets post, loopt de tijd dus 9 minuten anders. 6apr 21.30 ]

Ik denk dat er wel wat verschillen zijn tussen hoe Oracle en MySQL omgaan met locks op db nivo, principes zijn natuurlijk gelijk.
Ik had net een lock situatie voor de camera (phpmyadmin process list) en heb na wat zoeken op drupal.org 2 tabellen gecorrigeerd (ivm feeds) en een index bijgezet op tabel accesslog. Misschien hielden de achtergrond feed refreshes het zaakje op? even afwachten weer.
Bart, ik mail je met meer details, alvast dank!