[MySQL] Overhead voorkomen - Softwareontwikkeling

zondag 9 maart 2003 13:57

Acties:

Topicstarter

Heren,

Ik ben bezig met het maken van een gamesite, op deze site kunnen users naturulijk ook reageren, zullen reacties een special beoordeling krijgen etc. Je snapt dat dit veel DB queries e.d. geeft.

Ik ben erg 'bang' voor veel Overhead. Bij een forum als phpBB(wat overigens zwaar belastend voor zowel je webserver als je database is) zie je een gigantische overhead als je niet zorgt dat deze om de zoveel tijd verdwijnt. Ik vraag me dus af hoe ik overhead kan voorkomen. Ik heb via de search gevonden dat dit vooral voorkomt bij varchars en dat je overhead kunt krijgen via queries(dit laatste snap ik niet volledig). Kunnen jullie mij een eindje verder helpen in mijn zoektocht?

Deze post is bestemd voor hen die een tegenwoordige tijd kunnen onderscheiden van een toekomstige halfvoorwaardelijke bepaalde subinverte plagiale aanvoegend intentioneel verleden tijd.
- Giphart

zondag 9 maart 2003 14:13

Acties:

ACM

Software Architect

Werkt hier

Zoiets zal wel gewoon bij je onderhoudsplanning moeten horen, maar eerlijk gezegd denk ik dat je er niet te bang voor hoeft te zijn.
Gewoon zo nu en dan 'optimize table $tablenaam_met_overhead' uitvoeren.

Btw, waarom moet iets "veel DB queries" geven?

Overhead zal vooral onstaan doordat records bijgewerkt worden (bijvoorbeeld met een grotere inhoud waardoor het niet past en ergens anders moet komen) en records verwijderd worden. Delete en update queries zijn natuurlijk ook queries

zondag 9 maart 2003 14:25

Acties:

Alex

Topicstarter

Als ik het zo zie is Overhead dus niet te voorkomen? Ik dacht eigenlijk dat overhead een gevolg was van badly-db-designs

. Dan is een OPTIMIZE van bijv de reactie table aslechts elke 100 reacties o.i.d. nodig.

Het is natuurlijk de bedoeling dat alles in zo min mogelijk queries gaat werken. Dat is inmiddels gelukt bij de reacties(incl. een soort van beoordelingscore), de hele lijst(20 testreacties) krege ik met één querie op mijn scherm echter na een hoop testen kwma ik tot 5% overhead en dara schrok ik erg van. Vandaar deze vraag.

Als er meer reacties komen zal de overhead ook sneller toenmen echter het lijkt mij qua database belasting niet slim om elke update/delete een OpTIMIZE te draaien. Zijn die queries erg belastend?

Deze post is bestemd voor hen die een tegenwoordige tijd kunnen onderscheiden van een toekomstige halfvoorwaardelijke bepaalde subinverte plagiale aanvoegend intentioneel verleden tijd.
- Giphart

zondag 9 maart 2003 14:31

Acties:

ACM

Software Architect

Werkt hier

prog-konijn schreef op 09 maart 2003 @ 14:25:
Als er meer reacties komen zal de overhead ook sneller toenmen echter het lijkt mij qua database belasting niet slim om elke update/delete een OpTIMIZE te draaien. Zijn die queries erg belastend?

Uiteraard zal de overhead sneller toenemen, maar het kost je niet zo veel performance om dat te hebben hoor, voornamelijk ruimte.

Ik zou optimize iig niet _zo_ vaak draaien, hooguit 1x per dag ofzo.

zondag 9 maart 2003 14:31

Acties:

cybermans

wat je kan doen is gewoon een doodsimpel scriptje maken die alleen alle tables optimizt en die door een cron/taakplanner eens in de zoveel tijd laten aanroepen

Strava | Runkeeper | Endomondo (mijn leikr uploads)

zondag 9 maart 2003 14:41

Acties:

Alex

Topicstarter

Het wordt ontwikkeld en blijft draaien op Linux dus dat zal idd een simpel cronjobje worden dan

. Thanx for the help

Deze post is bestemd voor hen die een tegenwoordige tijd kunnen onderscheiden van een toekomstige halfvoorwaardelijke bepaalde subinverte plagiale aanvoegend intentioneel verleden tijd.
- Giphart

zondag 9 maart 2003 18:02

Acties:

slm

Als je een cronjobje schrijft moet je er wel voor zorgen dat het gebruik van de database op het moment dat de optimize acties worden uitgevoerd _minimaal_ is, anders irriteer je je gebruikers.

Overigens komt overhead ook voor in fixed formatted tabellen (dus met alleen chars en geen varchars of blobs/texts). Het voordeel van fixed format in tegenstelling tot dynamic format is dat fixed een stuk sneller is. De server hoeft namelijk niet lang te zoeken naar het begin en einde van een rij omdat die rij een vast aantal bytes in beslag neemt.

Zeker met veel rijen kan dat een behoorlijke snelheidswinst opleveren. Nadeel is natuurlijk dat het meer HD ruimte in beslag neemt.

To study and not think is a waste. To think and not study is dangerous.