Onderwerp: Hoe de server minder belasten?

Hallo WHT,

Ik heb hier een aangekocht script liggen, waar de server het nogal moeilijk mee heeft.
De site heeft een heleboel leden, en van die leden worden alle transacties bijgehouden.
Een voorbeeld: de site heeft 25.000 leden, 3.689.168 transacties.
De transacties tabel is 519 Mb!

De leden kunnen op elk moment al hun transacties bekijken...
De server vindt dat echter niet zo leuk.
Ik heb een beetje gedacht, en ik kwam tot deze conclusie:
Als we nu de transacties maar voor 10 dagen in de tabel laten liggen, daarna schrijven we door middel van cron jobs naar .xml bestanden.
Elk lid heeft dan zijn eigen xml bestand.
De transacties van de vorige 10 dagen kan het lid heel gemakkelijk bekijken, en zullen vaak getoond worden. De andere transacties zullen minder vaak opgehaald moeten worden.

Krijgt de server het hierdoor minder zwaar, of verleggen we op deze manier het probleem alleen van een MySQL probleem naar een PHP/Apache probleem?

Ik hoop dat jullie mij een beetje kunnen helpen.

Grtz,
geheimIII

Origineel geplaatst door geheimIII
Hallo WHT,

Ik heb hier een aangekocht script liggen, waar de server het nogal moeilijk mee heeft.
De site heeft een heleboel leden, en van die leden worden alle transacties bijgehouden.
Een voorbeeld: de site heeft 25.000 leden, 3.689.168 transacties.
De transacties tabel is 519 Mb!

De leden kunnen op elk moment al hun transacties bekijken...
De server vindt dat echter niet zo leuk.
Ik heb een beetje gedacht, en ik kwam tot deze conclusie:
Als we nu de transacties maar voor 10 dagen in de tabel laten liggen, daarna schrijven we door middel van cron jobs naar .xml bestanden.
Elk lid heeft dan zijn eigen xml bestand.
De transacties van de vorige 10 dagen kan het lid heel gemakkelijk bekijken, en zullen vaak getoond worden. De andere transacties zullen minder vaak opgehaald moeten worden.

Krijgt de server het hierdoor minder zwaar, of verleggen we op deze manier het probleem alleen van een MySQL probleem naar een PHP/Apache probleem?

Ik hoop dat jullie mij een beetje kunnen helpen.

Grtz,
geheimIII

Hangt er helemaal vanaf waar je verkeer ligt? Kijkt men vaak naar de transacties en zo ja welke periode? Als je dit goed gaat pleilen kun je zien of dit nut heeft.

Wat voor configuratie draai je? Mits je php5 draait is XML in dit geval zeker een uitkomst gezien de performance.. in php4 denk ik dat je het probleem dan verschuifd en niets oplost.

Caching in bestanden (.html of .xml (zoals aangegeven)) is mogelijk een oplossing. Hoewel je ook kunt werken met Header caching, dus zeggen wanneer een pagina verloopt, en tot die tijd wordt een pagina van het eigen systeem gebruikt.

Ik neem aan dat je verder al gebruik maakt van goede indexes, kleine tabellen (dus weinig kolommen), geen * in een select: alleen de kolommen die je nodig hebt enz. ?

Origineel geplaatst door alleznet
Ik neem aan dat je verder al gebruik maakt van goede indexes, kleine tabellen (dus weinig kolommen), geen * in een select: alleen de kolommen die je nodig hebt enz. ? [/B]

Idd, daar maak ik zeker gebruik van.
Mss ook interessant om te vermelden dat er vaak transacties bijkomen.
De pagina met de recenste transacties zal dus dynamisch moeten blijven denk ik?

En is het geen idee om de transacties in een .txt (eventueel .xml) weg te schrijven (weliswaar beveiligd, mogelijk encrypted), en het vanuit daar op te roepen per user? Dan hoef je eigenlijk niet eens meer een database te gebruiken

Dat kan ook gebeuren.
Maar die bestanden zullen op den duur vrij groot worden.
Als de leden dan maar bv de laatste 10 nieuwe willen zien, moet de server wel heel het bestand inladen, of maakt dat niet uit?

Zou je de gegevens dan gwn in een .txt opslaan, bv gescheiden door een komma?

gaat je server dat leuk vinden, 25.000 xml bestanden (in 1 map )?

De transacties tabel is 519 Mb!

An sich is dit voor een database helemaal niet groot; met de juiste indexen moet dit niet zwaar zijn.

Mocht je toch willen cachen, dan zou ik dat als html wegschrijven, zodat er in ieder geval geen belasting is als je opnieuw xml naar html gaat parsen.

Het deleten en wegschrijven naar bestanden is een behoorlijke operatie. Daarnaast zul je logica in moeten bouwen wanneer iemand bijvoorbeeld wil zoeken in de data, of van meerdere dagen / weken data op het scherm wil hebben; ga je dan meerdere bestanden inlezen?

Dit soort getallen moeten voor MySQL in principe geen probleem zijn. Ik heb als V. Kleijnendors ook het idee dat je geen juiste indexes op je tabellen hebt.

Geef eens de output van een: "show indexes from Transactions" query? (of hoe je tabel heet)

Misschien is de query in je transactie bekijkpagina inefficient. Kun je deze eens laten zien?

Nog even voor de duidelijkheid, ik heb het script aangeschaft, en niet zelf gemaakt:

De tabel waar het over gaat ziet er zo uit:
id int(12)
uid int(12)
type varchar(24)
conn_id varchar(36)
credits double(6,4)
c_type enum('cash', 'points')
dateStamp int(14)


Naam: select_count
Type: INDEX
Velden:
uid
type
c_type
conn_id

Naam:maintenance
Type:INDEX
Velden:
dateStamp
conn_id

Naam:account_history
type:INDEX
Velden:
uid
dateStamp
conn_id
type

Deze velden, die als index zijn ingesteld, komen in de query's altijd voor in het WHERE-gedeelte. Zoals het hoort volgens mij?

Zet eens 'EXPLAIN ' voor je query, en print het resultaat daar eens van; dan zie je of mysql ook de indexen gebruikt.

Ik heb Explain er voor gezet.
En bij mijn querys zag ik dat hij altijd gebruik maakte van de indexen.
Zijn er nu nog dingen om het script lichter te maken, of zullen we toch aan een andere server moeten denken?

www.google.be jpcache
is heel goed caching systeem

Origineel geplaatst door geheimIII
Ik heb Explain er voor gezet.
En bij mijn querys zag ik dat hij altijd gebruik maakte van de indexen.
Zijn er nu nog dingen om het script lichter te maken, of zullen we toch aan een andere server moeten denken?

Wat voor server heb je nu draaien?

Ik draai momenteel op deze server (heb ik even uit DA gehaald):
Processor Name
Intel(R) Pentium(R) 4 CPU 2.66GHz (2657.83-MHz 686-class CPU)
Total Memory
759.207 MB