Performance van grote MYSQL database

[Verwijderd]

Hallo,

Ik ben al een tijdje bezig met een website voor een klant van mij. Het is een webshop waar nu al meer dan 50000 producten worden aangeboden. Deze site stond eerst op een normaal MKB webhost pakket gehost. Hier gaf de webshop geen problemen, hij werkte snel zo als het hoorde. Vanwege de groote van het MKB webhost pakket zijn we overgestapt naar een VPS pakket met 192Mb geheugen. Sinds dat de website hierop gehost staat werkt deze traaag, heel traag. Wat ik van te voren niet wist of over nagedacht heb is dat de Mysql database in het geheugen geladen wordt. Op dit moment die de Mysql db ongeveer 100Mb groot. Als dit in het geheugen geladen wordt en daarnaast nog alle andere services blijft er geen ruimte meer over voor de verwerking van data. Nu is de vraag of het misschien verstandig is om een eigen server te gaan huren?( of kopen en met co-locating werken)
En is er misschien een manier om de performance van de mysql db te verbeteren. Dat er misschien een manier is om een soort van load-balancing uit te voeren met mysql databases.

Over dit probleem had ik niet eerder over nagedacht dat we hier tegenaan konden gaan lopen. Het was ook eerst de bedoeling dat er rond de 20000 producten op de site zouden komen, maar dat is zoals ik al eerder zei al behoorlijk overschreden. En de bedoeling is eigenlijk dat het voor het einde van dit jaar er rond de 100000 producten op staan. Dit zal in de toekomst nog meer worden. Vandaar dat ik hier de mensen om advies vraag die hier misschien al eerder mee te maken hebben gehad.

[Verwijderd]

Als het zuiver om een webshop gaat, is het fatsoenlijk blijven werken van de site natuurlijk van levensbelang. 192 MB geheugen is bizar weinig, zeker als er ook een DBMS op moet draaien. Ofwel je moet die database op een aparte server zetten, ofwel je moet gewoon een hele aparte server kopen/huren. Zorg dan in elk geval dat daar wel een normale hoeveelheid geheugen in zit.

Overigens wordt niet de hele database in het geheugen geladen hoor. Maar meer geheugen is altijd een pre bij databasewerk.

Op zich is 50.000 of 100.000 records nog niks hoor. Heb je ook al eens onderzocht of er nog iets valt te optimaliseren aan queries, of door bepaalde indexes toe te voegen?

[ Voor 14% gewijzigd door Verwijderd op 17-03-2007 19:50 ]

[incinerator82]

Hallo mensjes,
Ik ben medeverantwoordelijk voor dit pakketje.
Wat ik me ook afvraag, op dit moment staat alles in 1 DB in 1 Tabel.
Zou het niet beter zijn voor performance als alle onderdelen in tabellen wordt verdeelt.
Het gaat voornamelijk om auto onderdelen, dus indexeren op Merk - Leeftijd - type.
Zou het dan niet schelen voor de queries om sneller te laten verwerken?

-edit-

My is geleerd om inconsistensie (srry voor de typo's) te voorkomen, om alles netjes in verschillende tabbelen te plaatsen en daar weer Pr. en/of Sec. sleutels aan te koppelen.
Waardoor de hoeveelheid gegevens enorm zal slinken, en er geen dubbel op stellingen worden geplaatst.

We staan op het punt om een eigen server te gaan huren/kopen.
Maar wat is nou nodig.

[ Voor 34% gewijzigd door incinerator82 op 17-03-2007 19:57 ]

[Verwijderd]

Stp 1 is natuurlijk de database normaliseren. In laats van een tekstveld "Merk" kun je natuurlijk een unsigned int gebruiken, merk_id, en in een aparte tabel de merken bijhouden. Als je het idee hebt dat die database niet goed is, zou ik die eerst even aan een analyse onderwerpen.

Geef anders even aan welke tabellen/kolommen je nu hebt. Dan kunnen mensen wat tips geven over normalisatie en optimalisatie door middel van indexen.

[ Voor 21% gewijzigd door Verwijderd op 17-03-2007 19:59 ]

[Glewellyn]

Verwijderd schreef op zaterdag 17 maart 2007 @ 19:57:
Stp 1 is natuurlijk de database normaliseren. In laats van een tekstveld "Merk" kun je natuurlijk een unsigned int gebruiken, merk_id, en in een aparte tabel de merken bijhouden. Als je het idee hebt dat die database niet goed is, zou ik die eerst even aan een analyse onderwerpen.

Geef anders even aan welke tabellen/kolommen je nu hebt. Dan kunnen mensen wat tips geven over normalisatie en optimalisatie door middel van indexen.

Als er verder geen gegevens zijn die van merk afhankelijk zijn is dat natuurlijk inefficient...

Een lijstje van de kolommen zou inderdaad veel meer duidelijkheid scheppen. Ook veelgebruikte queries zouden extra informatie kunnen opleveren, met name over op welke velden een index nuttig is.

[ Voor 7% gewijzigd door Glewellyn op 17-03-2007 20:02 ]

[incinerator82]

Goed dat is mijn punt dus ook
Maar op dit moment is het pakket zencart gebruikt, die heeft dus de sctructuur opgezet.
Ik heb niet gekeken naar de Normalisatie van de DB.

In eerste instantie zou het om een kleine 20.000 records gaan.
Achteraf zijn dit er dus 56.000+ gworden.

Ik zou zeggen : normaliseer altijd. Geleerd op school (jaha)
Maar dat was toen nog te sprake.

[ Voor 10% gewijzigd door incinerator82 op 17-03-2007 20:06 ]

[Verwijderd]

Ik zal zo even de structuur van de products tabel posten. het gaat omde site www.stroevemotorsport.nl, hier kun je zien dat elk product een eigen omschrijving heeft. En dat deze allemaal verschillen van andere producten, behalve de onderstaande tekst. Deze is gelijk aan alle andere producten van het zelfde product merk en type

[ Voor 52% gewijzigd door Verwijderd op 17-03-2007 20:09 ]

[Verwijderd]

Heel simpel, ik zou direct een dedicated bak huren of een bak kopen en deze colo hangen.

Dan heb je echt performance en kan je ook flink groeien, met het oog op de toekomst.

[Glewellyn]

Je gebruikt schijnbaar een off-the-shelf produkt. Dat beperkt je natuurlijk behoorlijk als je op zoek bent naar een quick-win.

Kijk eens in de applicatie welke queries het vaakst uitegevoerd worden, dan kan je die kolommen misschien indexeren en op die manier veel tijd besparen.

[incinerator82]

DE auto merken en types en bouwjaren blijven hetzelfde.
/offtopic
Ik moet NU weg, ik lees het met een 1,5 uur weer trg en reageert dan weer.
whutten blijft voor verdere info en houd mij op de hoogte.
/offtopic

[ Voor 17% gewijzigd door incinerator82 op 17-03-2007 20:10 ]

[Verwijderd]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:08:
Heel simpel, ik zou direct een dedicated bak huren of een bak kopen en deze colo hangen.

Ik zou eerder mijn hersens gebruiken. De reactie van incinerator82 geeft toch wel aan dat er in de databasestructuur zelf al behoorlijk wat winst valt te behalen.

Dan heb je echt performance en kan je ook flink groeien, met het oog op de toekomst.

Ja joh, schaf dan ook meteen een paar servers een een loadbalancer aan. Overdrijven kan ook natuurlijk.

[Glewellyn]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:08:
Heel simpel, ik zou direct een dedicated bak huren of een bak kopen en deze colo hangen.

Dan heb je echt performance en kan je ook flink groeien, met het oog op de toekomst.

Voor 50k records? Een simpel bakkie moet dat gewoon aankunnen hoor...

[Verwijderd]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:11:
[...]

Ik zou eerder mijn hersens gebruiken. De reactie van incinerator82 geeft toch wel aan dat er in de databasestructuur zelf al behoorlijk wat winst valt te behalen.

[...]

Ja joh, schaf dan ook meteen een paar servers een een loadbalancer aan. Overdrijven kan ook natuurlijk.

Een dedicated bak, of in ieder geval 1GB geheugen voor alleen deze DB is echt geen overbodige luxe ofzo hoor.

[DJ Buzzz]

Ik zou eerst eens goed nadenken voordat je een eigen server gaat ophangen. Wil je hiervoor zelf compleet de verantwoording dragen? Wie heeft er hier verstand van? Wil je nog zonder zorgen zomaar een week op vakantie kunnen en wat als het dan helemaal mis gaat? Als het bedrijf voor een groot deel van de omzet van de webshop afhankelijk is, zou ik niet zomaar daar als enige verantwoordelijk voor willen zijn.

Verder moet met een beetje fatsoenlijk database ontwerp en de goeie indices 50000 producten absoluut geen probleem voor je performance zijn. Je zou dit nog prima moeten kunnen draaien op een wat uitgebreider hosting pakket bij een partij die goeie performance biedt door b.v. loadbalancing e.d. Ik zou dus eerst maar eens flink die database aanpakken in plaats van gelijk naar een eigen server kijken.

[Verwijderd]

Verwijderd schreef op zaterdag 17 maart 2007 @ 19:57:
In plaats van een tekstveld "Merk" kun je natuurlijk een unsigned int gebruiken, merk_id, en in een aparte tabel de merken bijhouden.

Glewellyn schreef op zaterdag 17 maart 2007 @ 20:01:
Als er verder geen gegevens zijn die van merk afhankelijk zijn is dat natuurlijk inefficient...

Dat is niet per definitie waar. Ik neem even aan dat we voor Merk over een varchar praten.
Dat is dus een column met variabele lengte, wat enige nadelen heeft in MySQL boven een van vaste lengte.

Vaste lengte voor alle columns in een table is fijner omdat je dan zonder verdere kennis van de inhoud direct kunt bepalen waar bijvoorbeeld row 12551 staat. Daarnaast is MySQL flink trager (relatief) met ORDER BY op tabellen met variabele row lengte omdat het dan automatisch terugvalt op disk-based sorting.

Dus, ook als het maar 1 field betreft kan het alsnog nuttig zijn deze in een aparte tabel te zetten.
Een andere optie kan zijn om je Merk in een column met vaste lengte op te slaan. Dit zal meer overhead geven. Dus of dat een optie is hangt af van de verschillende lengtes van merknamen.

Meer algemeen: zet je slow query log aan. En kijk voor je trage queries eens goed naar PROCEDURE ANALYSE en EXPLAIN. Het eerste bepaalt het meest optimale tabel-type voor die query (soms komt daar best wat zinnigs uit). Het tweede geeft informatie over hoe MySQL jouw query uitvoert. Bijvoorbeeld join order, gebruik van indexes en het aantal gematchde rows per stap.

Ook zou je bij gebruik van indexes kunnen kijken naar de grootte van je index cache. Die hoger zetten kan helpen. Maar ik vraag me af of je nu al indexes gebruikt. Kortom, meer info.

[Verwijderd]

Verkennen: (52750 Rijen) products
Verkennen: (0 Rijen) products_attributes
Verkennen: (0 Rijen) products_attributes_download
Verkennen: (52750 Rijen) products_description
Verkennen: (0 Rijen) products_discount_quantity
Verkennen: (0 Rijen) products_notifications
Verkennen: (0 Rijen) products_options
Verkennen: Track products_options_types (6 Rijen) products_options_types
Verkennen: (1 Rijen) products_options_values
Verkennen: (0 Rijen) products_options_values_to_products_options
Verkennen: (52750 Rijen) products_to_categories
Verkennen: (0 Rijen) product_music_extra
Verkennen: (5 Rijen) product_types
Verkennen: (0 Rijen) product_types_to_category
Verkennen: (143 Rijen) product_type_layout

Dit zijn de tabellen die apart voor de producten zijn. Hier kun je dus ook al zien dat de omschrijving en de titel in een aparte tabel staan. Zelf zat ik te denken om voor de omschrijving een aparte tabel te gaan maken. Dit omdat de omschrijving veel tekst bevat (en dan ook nog een maal 50000 maakt het behoorlijk groot). Ik hoop door dit te gaan scheiden meer performance te krijgen. Deze hoeft dan alleen maar geladen te worden als het product zelf wordt aangeklikt.


Even over die server:
Het was ook al de bedoeling om samen met Incinerator82 een server te gaan huren of kopen. Daarom zou het misschien mooi zijn om deze klant mee te nemen, maar dan is het natuurlijk van belang om eerst te gaan kijken wat het meest geschikt is. Zelf had ik ook idd al gedacht aan veel werk geheugen. De hardeschijf ruimte vind ik niet heel belangrijk. Deze is natuurlijk altijd nog uit te breiden, maar speelt op het begin geen hele belangrijke rol.

[Verwijderd]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:34:De hardeschijf ruimte vind ik niet heel belangrijk. Deze is natuurlijk altijd nog uit te breiden, maar speelt op het begin geen hele belangrijke rol.

De snelheid van je disk kan wel erg belangrijk zijn.

[Verwijderd]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:36:
[...]


De snelheid van je disk kan wel erg belangrijk zijn.

Dat begrijp ik maar de grootte van de schijf is minder belangrijk.

[Glewellyn]

Kan je de kolommen voor de tabellen products, products_description en products_to_categories eens posten?

[CyBeR]

Op zich heb je strict gezien voor wat je doet aan een VPS wel genoeg. Maar niet aan 192MB geheugen. Maak daar minimaal 1GB van en je zit goed. Zelfs met een perfect databaseontwerp is 192MB gewoon te weinig voor een db waar informatie over 50k producten in staat. En dan moet apache met php en alles er nog naast ook. Dus zorg iig eerst voor een sloot extra geheugen en ga daarna pas kijken naar je db ontwerp.

Een server kopen en colo'en kan ook wel natuurlijk maar ik denk dat je dan wel goed moet kijken naar of je iemand hebt met verstand van zaken en die ten alle tijden zo snel mogelijk ter plaatse kan zijn als er iets mis gaat. En je zit natuurlijk met de veel hogere aanschafkosten dan bij een vps of dedicated.

[ Voor 39% gewijzigd door CyBeR op 17-03-2007 20:44 ]

[Verwijderd]

Wat ik dan een beetje jammer vond van het bedrijf waar het allemaal gehost is, dat ik advies heb gevraag welk pakket de juiste eigenschappen heeft voor zo'n webshop met zoveel artikelen. Zelfs heb ik nog even aangegeven dat het aan het einde van dit jaar op ongeveer 100k artikelen zullen zijn.

[Verwijderd]

Glewellyn schreef op zaterdag 17 maart 2007 @ 20:41:
Kan je de kolommen voor de tabellen products, products_description en products_to_categories eens posten?

ja hoor, komen er aan

[Verwijderd]

Heb het even met exporteren gedaan..

CREATE TABLE `products` (
`products_id` int(11) NOT NULL auto_increment,
`products_type` int(11) NOT NULL default '1',
`products_quantity` float NOT NULL default '0',
`products_model` varchar(32) default NULL,
`products_image` varchar(64) default NULL,
`products_price` decimal(15,4) NOT NULL default '0.0000',
`products_virtual` tinyint(1) NOT NULL default '0',
`products_date_added` datetime NOT NULL default '0001-01-01 00:00:00',
`products_last_modified` datetime default NULL,
`products_date_available` datetime default NULL,
`products_weight` float NOT NULL default '0',
`products_status` tinyint(1) NOT NULL default '0',
`products_tax_class_id` int(11) NOT NULL default '0',
`manufacturers_id` int(11) default NULL,
`products_ordered` float NOT NULL default '0',
`products_quantity_order_min` float NOT NULL default '1',
`products_quantity_order_units` float NOT NULL default '1',
`products_priced_by_attribute` tinyint(1) NOT NULL default '0',
`product_is_free` tinyint(1) NOT NULL default '0',
`product_is_call` tinyint(1) NOT NULL default '0',
`products_quantity_mixed` tinyint(1) NOT NULL default '0',
`product_is_always_free_shipping` tinyint(1) NOT NULL default '0',
`products_qty_box_status` tinyint(1) NOT NULL default '1',
`products_quantity_order_max` float NOT NULL default '0',
`products_sort_order` int(11) NOT NULL default '0',
`products_discount_type` tinyint(1) NOT NULL default '0',
`products_discount_type_from` tinyint(1) NOT NULL default '0',
`products_price_sorter` decimal(15,4) NOT NULL default '0.0000',
`master_categories_id` int(11) NOT NULL default '0',
`products_mixed_discount_quantity` tinyint(1) NOT NULL default '1',
`metatags_title_status` tinyint(1) NOT NULL default '0',
`metatags_products_name_status` tinyint(1) NOT NULL default '0',
`metatags_model_status` tinyint(1) NOT NULL default '0',
`metatags_price_status` tinyint(1) NOT NULL default '0',
`metatags_title_tagline_status` tinyint(1) NOT NULL default '0',
PRIMARY KEY (`products_id`),
KEY `idx_products_date_added_zen` (`products_date_added`),
KEY `idx_products_status_zen` (`products_status`),
KEY `idx_products_date_available_zen` (`products_date_available`),
KEY `idx_products_ordered_zen` (`products_ordered`),
KEY `idx_products_model_zen` (`products_model`),
KEY `idx_products_price_sorter_zen` (`products_price_sorter`),
KEY `idx_master_categories_id_zen` (`master_categories_id`),
KEY `idx_products_sort_order_zen` (`products_sort_order`),
KEY `idx_manufacturers_id_zen` (`manufacturers_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

CREATE TABLE `products_description` (
`products_id` int(11) NOT NULL auto_increment,
`language_id` int(11) NOT NULL default '1',
`products_name` varchar(128) NOT NULL default '',
`products_description` text,
`products_url` varchar(255) default NULL,
`products_viewed` int(5) default '0',
PRIMARY KEY (`products_id`,`language_id`),
KEY `idx_products_name_zen` (`products_name`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

CREATE TABLE `products_to_categories` (
`products_id` int(11) NOT NULL default '0',
`categories_id` int(11) NOT NULL default '0',
PRIMARY KEY (`products_id`,`categories_id`),
KEY `idx_cat_prod_id_zen` (`categories_id`,`products_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Dit zijn inderdaad ook de meest gebruikte tabellen, die allen evenveel rijen bevatten

[CyBeR]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:45:
Wat ik dan een beetje jammer vond van het bedrijf waar het allemaal gehost is, dat ik advies heb gevraag welk pakket de juiste eigenschappen heeft voor zo'n webshop met zoveel artikelen. Zelfs heb ik nog even aangegeven dat het aan het einde van dit jaar op ongeveer 100k artikelen zullen zijn.

Het zou me niets verbazen als zij er vanuit gingen dat je een van hun database servers zou gebruiken. Hoewel dit soort dingen moeilijk in te schatten is weet iedereen die een serieuze mysql server draait dat minder dan 1GB geheugen gewoon geen goed idee is.

[Glewellyn]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:49:
Heb het even met exporteren gedaan..

<snip>

Dit zijn inderdaad ook de meest gebruikte tabellen, die allen evenveel rijen bevatten

Wel vreemd dat een koppeltabel evenveel records heeft als het aantal records in een van de twee tabellen. Zit alles in maar 1 categorie ofzo? Verder vraag ik me af welke queries er uitgevoerd worden op deze tabellen. Indexing lijkt op het eerste gezicht goed.

Ik begin een flauw vermoeden te krijgen dat de traagheid niet in de DB, maar in de code zit. Ik kan me zo voorstellen dat hij alles in een categorie ophaalt (enorme resultset) en er dan overheen loopt.

[ Voor 16% gewijzigd door Glewellyn op 17-03-2007 20:58 ]

[Verwijderd]

• Waarom is er een aparte products_description tabel? Products is toch al geen fixed-size rows, dus waarom descriptions er niet ook bij. Ik neem aan dat je die vaak erbij wil in de resultaten.
• Ik heb geen idee wat voor queries je hierop runt, maar denk eraan dat als je op "products_model LIKE 'blaat%'" je idx_products_model_zen wel helpt, maar bij "products_model LIKE '%blaat' geheel niet.
• Puur estetisch valt me op dat je het field voor model in de products table ook nog products_model noemt. Dat lijkt me nogal overbodig en lastiger leesbaar.

De tip voor dit soort dingen blijft nog altijd: slow query log. Zet het aan, bestudeer alle queries die traag zijn en kijk hoe je die sneller krijgt. Dat is niet veel werk. En als daar niets in opvalt, kan het inderdaad ook nog goed in je code zitten. Op deze manier werken zal denk ik veel effectiever zijn dan in het wilde weg performance improvement mogelijkheden in je database te zoeken.

[ Voor 7% gewijzigd door Verwijderd op 17-03-2007 21:25 ]

[Verwijderd]

alles wordt wel in verschillende categorien gezet.
Hieronder de lijst van verschillende categorien. Dat lijken mij er toch best wat.

* Interieur
o Diversen
+ Gearframes
+ Gordelhoezen
+ Overige
o Gordels
o Handremgrepen
o Instrumenten
o Interieurverlichting
o Mattensets
o Pedaalsets
o Pookhoezen
o Pookknoppen
o Rolkooien
o Stoelen
+ Niet verstelbaar
+ Sledeframes
+ Verstelbaar
o Sturen
+ Sturen
+ Stuurnaven
# Aluminium
# Staal
* Motor
o Bougiekabels
o Bougies
o Carbon Producten
o Chroom delen/Dress up
o Dumpvalves
o Intercoolers
o Luchtfilters
+ Openfilterkits
+ Universeel
+ Vervangingsfilter
o Oliekoeler
o Performance
o Polijswerk
o Siliconenslangen
o Diversen
* Onderstel
o Polyurethaan rubbers
o Remmen
+ Remblokken
+ Remklauwen
+ Remleidingen
+ Remmenkits
+ Remschijven
o Spoorverbreders
o Stabilisatorkits
o Veerpootbruggen
o Verlagingsets
+ Schokbrekers
+ Schokbrekers+veren
+ Schroefsets
+ Verensets
* Sportuitlaten
o Complete systemen
o Einddempers
o Kat vervangers
o Middendemper vervangers
o Middendempers
o Spruitstukken
o Universeel
+ Einddempers
+ Eindstukken
+ Diversen
o Diversen
* Styling
o Achterbumpers
o Achterskirt
o Achterspoilers
o Bodykits
o Grilles
o Koplamspoilers
o Sideskirts
o Spiegels
o Vleugeldeuren
o Voorbumper
o Voorspoiler
o Diversen
* Velgen
o Adapters
o Banden
o Hoogglans verdichten
o Spoorverbreders
o Velgen eendelig
+ Chrome
+ Chrome-silver
+ Zilvergrijs
+ Zwart
o Velgen meerdelig
o Velgen met banden
o Wielsloten
* Verlichting
o Achterlichten
o Koplampen
o Richting aanwijzers
o Zijrichting aanwijzers

[Verwijderd]

ik ga nu eerst even opzoek hoe ik de slow query log aanzet en hoe ik deze bestudeer heb dat nog niet eerder gedaan vandaar...

[incinerator82]

Ik zie al 1 klein dingetje, bij het menu "Sturen".
Het is "Sturen --- Sturen". Ik denk dat het zowieso al "Besturing -- Sturen" moet worden.
Ivm de normalisatie, dan zou het hoofdmenu "Sturen" wegvallen.
Als ik het zo 123 even snel op menu structuur aan het normaliseren ben.

Maargoed even voor de duidelijkheid alle punten op een rij:

- Aangeraden 1Gb Mem.
- Performance winst door de DB GOED te normaliseren in verschillende tabellen.
- Hostingpartij, of 1 met load balancing en 1gb beschikking, of eigenhost met een goede systeembeheerder. (Voordeel ik ga eigenlijk niet op vakantie, en ik heb een fam. lid die ik als backup in kan schakelen nmlk : Supertrooper78 )
- zo veel mogelijk vaste var lengtes gebruiken. Mysql vind dat fijner.

Wat het probleem ook is (na mijn ziens is het niet een probleem) dat we alle producten in excel binnenkrijgen, op allemaal verschillende manieren ingedeelt met verschillende benamingen.

Ik heb zoiets van schrijf per leverancier(van onderdelen) een script die het ordent/compiled voor onze DB en laad het dan in.

[ Voor 3% gewijzigd door incinerator82 op 17-03-2007 21:47 . Reden: verduidelijking ]

[incinerator82]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:36:
[...]


De snelheid van je disk kan wel erg belangrijk zijn.

Ik zat toch echt aan een raid 5 te denken. Voor beetje perf.
Een SAS setje oid.
Ik ben niet echt op de hoogte wat het beste is voor Mysql.
Mysql schijnt daar nogal gevoelig voor te zijn???

[Verwijderd]

incinerator82 schreef op zaterdag 17 maart 2007 @ 21:43:
- zo veel mogelijk vaste var lengtes gebruiken. Mysql vind dat fijner.

Ja nee. Tabellen waarbij elke column vaste lengte heeft is fijner. Maar niet als dat je veel grotere fields oplevert. Maar als je er eenmaal 1 met variabele lengte hebt, maken extra veel minder uit.

Dus bij een column van varchar(100) met 1000x een entry van 10 characters en 50x eentje van 99, is het niet zinnig om daar een char(100) van te maken.

Met betrekking tot raid5, bedenk je wel dat dat vaak qua performance sterft zodra er een disk uitvalt. Het wordt echt ontzettend traag. Misschien wil je eerder raid1 met hotspare. Maar ik vraag me sowieso al af of het wel nodig is.

Belangrijkste lijkt me dat je, los van alle leuke tips, eerst eens achterhaalt waar het probleem nou in zit. Er zijn allerlei leuke trucen om performance te verbeteren, maar misschien zijn die niet nodig en verdoe je je tijd.

[Verwijderd]

Het lijkt mij dat het belankrijk is dat er een eigen of gehuurde server komt. Ik denk de aanpassingen nog wel wat schelen maar niet zo veel dat het nu op een vps zelf snel zal lopen. Het grootste probleem is dan toch het werkgeheugen van de server. Dus dat wordt maandag denk ik eens gaan zoeken naar een hosting die in het datacenter in hengelo zit. Dat is voor ons qua afstand heel goed te doen.

Wel hebben we 1 belangrijke verbetering voor de database en dat is de products_name veld te gaan verplaatsen naar een eigen tabel products_name, zodat als er een product naam moet worden weergeven niet de hele tabel hoeft door gespit te worden waar ook alle omschrijvingen in staan. Dit zal naar mijn weten een hele hoop schelen.

[ Voor 0% gewijzigd door Verwijderd op 17-03-2007 22:42 . Reden: foutje ]

[Wacky]

Al geprobeerd om query caching aan te (laten) zetten?

[Verwijderd]

Ik ga dat in iedergeval ook even proberen...

[ Voor 76% gewijzigd door Verwijderd op 17-03-2007 22:57 ]

[incinerator82]

Wacky schreef op zaterdag 17 maart 2007 @ 22:41:
Al geprobeerd om query caching aan te (laten) zetten?

is niet mogelijk zo ver ik weet met plesk icm vps

[pven]

Volgens mij heb ik nog niet gelezen wat ongeveer de omvang van de database is. Is dat bekend?

[Verwijderd]

pven schreef op zaterdag 17 maart 2007 @ 23:00:
Volgens mij heb ik nog niet gelezen wat ongeveer de omvang van de database is. Is dat bekend?

Ik heb volgens mij op het begin een keer gezegd dat hij op dit moment ongeveer 100Mb is wat ongeveer +-52000 artikelen zijn, maar zal op later termijn nog groter worden.

[Verwijderd]

Ik ben al in overleg gegaan met de hosting om het gedeelde geheugen uit te breiden. Dit zal dan voor een korttermijn voldoende zijn, maar het wordt onder tussen wel gaan zoeken naar een dedicated server.

[Verwijderd]

In iedergeval bedank voor jullie reacties!!!!