[MySQL] +/- 2000 rijen laden traag

[Scott]

Hallo,

Ik heb een tabel met een stuk of 25 kolommen en 2000 rijen. Nu is het probleem dat hij dit erg langzaam laadt, hetgeen ik opzich wel snap, zeker als je ziet dat het aangeroepen wordt op een server die gewoon hier thuis staat. Ik zou er alleen toch wel een oplossing voor willen hebben.

Ik heb gekeken naar indexeren, maar omdat ik alle kolommen vrijwel altijd uitlees (en als dit niet het geval is, hangt dit ook af van welke kolommen de gebruiker wenst te zien), heeft dat geen zin.

Serverside cachen heb ik ook geprobeerd, maar dit ging ook niet geweldig snel, ietsjes sneller misschien, maar omdat de gegevens in de database vrij veel aangepast worden, moet dat dus ook elke keer in het cache bestand verwerkt worden.

Het hoeft niet per sé sneller te laden, maar ik wil alle gegevens in één keer op mn scherm, dus als hij aan 't laden is dat er een melding ofzo komt ('Bezig met laden van gegevens...')

Iemand die me kan vertellen hoe 'k dit kan doen ?

[André]

Gaat het halen van de gegevens uit de database traag of gewoon de schermopbouw in je browser. Ik gok het laatste want grote tabellen zijn sowieso al zwaar voor een browser.

[moto-moi]

ScottB schreef op zondag 29 mei 2005 @ 11:18:
Iemand die me kan vertellen hoe 'k dit kan doen ?

OK, heb je een ERD, de query waar het op fout gaat voor ons ?

[Scott]

André schreef op zondag 29 mei 2005 @ 11:21:
Gaat het halen van de gegevens uit de database traag of gewoon de schermopbouw in je browser. Ik gok het laatste want grote tabellen zijn sowieso al zwaar voor een browser.

Ja, denk ik ook inderdaad. Als ik het alleen cache en niet laat zien, dan is de pagina relatief wel snel geladen

moto-moi schreef op zondag 29 mei 2005 @ 11:21:
[...]

OK, heb je een ERD, de query waar het op fout gaat voor ons ?

Heb ik, maar is gewoon een hele simpele query waar ik alle kolommen uitlees:

code:

SELECT
    id,
    bedrijfsnaam,
    bezoekadres,
    bezoekplaats,
    telefoon,
    fax,
    postadres,
    postcode,
    postplaats,
    url,
    geslacht,
    voorletters,
    tussenvoegsel,
    naam,
    email,
    functie,
    bron,
    actieweek,
    actiedag,
    actie,
    opmerkingen,
    followup,
    fu_actieweek,
    fu_actiedag,
    fu_actie
FROM
    sales

[André]

Ik snap niet waarom je alles in 1 keer nodig hebt, kun je niet eerst een voorselectie maken?

[ Voor 17% gewijzigd door André op 29-05-2005 11:32 ]

[Scott]

André schreef op zondag 29 mei 2005 @ 11:32:
Ik snap niet waarom je alles in 1 keer nodig hebt, kun je niet eerst een voorselectie maken?

Ik heb alles nodig, een tabel met daarin alle output, waar een aantal velden aanpasbaar moeten zijn dmv text fields. Soort van phpmyadmin dus, alleen dan wat minder toeters en bellen

[ Voor 18% gewijzigd door Scott op 29-05-2005 11:35 ]

[André]

Maar dat kun je toch opsplitsen in pagina's oid

[Verwijderd]

Dan kan het nooit een handige applicatie zijn. Misschien kun je beter gebruik maken van paging om het systeem beter bruikbaar te maken. Scrollen door 2000 rijen en 25 kolommen is niet handig, dus je moet je afvragen of het vereist is dat alle gegevens op één pagina komen. Ik kan het me niet voorstellen.

[Scott]

Dat is inderdaad een optie, hoewel je dan niet makkelijk kunt zoeken op een bepaald bedrijf, maar ik zal eens kijken of dat handig is

edit:
Is geen vereiste inderdaad, alleen het zoeken wordt daardoor dus iets minder makkelijk, maar goed, dat is het probleem niet zo.

[ Voor 34% gewijzigd door Scott op 29-05-2005 11:40 ]

[ripexx]

ScottB schreef op zondag 29 mei 2005 @ 11:39:
Dat is inderdaad een optie, hoewel je dan niet makkelijk kunt zoeken op een bepaald bedrijf, maar ik zal eens kijken of dat handig is

edit:
Is geen vereiste inderdaad, alleen het zoeken wordt daardoor dus iets minder makkelijk, maar goed, dat is het probleem niet zo.

Zet er dan een fulltext search op de bedrijfsnaam of zo en maak dan gewoon boven de lijst een soort quick search.

[GlowMouse]

ScottB schreef op zondag 29 mei 2005 @ 11:39:
Dat is inderdaad een optie, hoewel je dan niet makkelijk kunt zoeken op een bepaald bedrijf, maar ik zal eens kijken of dat handig is

Misschien niet met ctrl-f, maar met een inputbox is dat toch prima mogelijk?

[ACM]

moto-moi schreef op zondag 29 mei 2005 @ 11:21:
OK, heb je een ERD, de query waar het op fout gaat voor ons ?

Dat is zeer waarschijnlijk irrelevant
Als er 2000 records met 25 velden (als het allemaal integers zijn) opgehaald moeten worden is dat aan pure data al minimaal 2000 * 25 * 4 = 200KB. Er zitten diverse stukken varchars bij dus ik gok dat het zelfs wel wat meer is.
Dan komt er nog een flinke zwik tabel-code omheen, met als gevolg dat de html nog veel groter is dan de data zelf.

De vraag van André is dus het best en dat zal uitgezocht moeten worden. Gebruik timing-functies van (microtime bij php bijv.) om te achterhalen hoelang het ophalen van de gegevens uit de database duurt.
Mocht blijken dat het toch aan mysql ligt, dan kan je diverse oplossingen proberen uit te werken;
- De data op de server in een database opslaan, ipv lokaal, evt via replicatie.
- Een andere vorm van efficientere caching. Bijvoorbeeld een die verandert als je wat verandert, ipv pas opnieuw opgehaald wordt bij een nieuwe request.

Mocht het aan de enorme lap html liggen, zorg er dan in ieder geval voor dat je dat minimaliseert. Gebruik zoveel mogelijk css om de tabel-code zo klein mogelijk te houden.
En mocht het niet de opbouwtijd van de html zelf zijn (lastig te timen), maar de transfer-tijden van de html van je server naar je client, kijk dan in ieder geval nog naar gzip-compressie van de html (bijv via php's ob_start('ob_gzhandler'))

[edit]
Hmm, allemaal reacties geplaatst ondertussen

[Ramon]

misschien kan je ook eens kijken naar het normaliseren van die tabel? Bijvoorbeeld splitsen in bedrijf en persoon en followup? Kan je ook meerdere personen per bedrijf bijhouden ofzo.

[ripexx]

Ramon de Jesus schreef op zondag 29 mei 2005 @ 11:45:
misschien kan je ook eens kijken naar het normaliseren van die tabel? Bijvoorbeeld splitsen in bedrijf en persoon en followup? Kan je ook meerdere personen per bedrijf bijhouden ofzo.

Maak dan ook nog onderscheid tussen bedrijf, functie, persoon afdelingen enz. enz. Je kan het zo gek maken als je wilt maar daarmee is het probleem van 2000 records nog niet opgelost

[Standeman]

Heb je al gekeken in MySQL Control Center (of de console app) hoe lang je query doet. Hier thuis doet een dergelijke query er ongeveer 2 ms over om een soortgelijke query (innoDB table) erover om de data op te halen.

[Scott]

ripexx schreef op zondag 29 mei 2005 @ 11:42:
[...]


Zet er dan een fulltext search op de bedrijfsnaam of zo en maak dan gewoon boven de lijst een soort quick search.

Is een mogelijkheid inderdaad

Ramon de Jesus schreef op zondag 29 mei 2005 @ 11:45:
misschien kan je ook eens kijken naar het normaliseren van die tabel? Bijvoorbeeld splitsen in bedrijf en persoon en followup? Kan je ook meerdere personen per bedrijf bijhouden ofzo.

En wat bereik ik daar dan verder mee ?

ACM schreef op zondag 29 mei 2005 @ 11:43:
[...]

Dat is zeer waarschijnlijk irrelevant
Als er 2000 records met 25 velden (als het allemaal integers zijn) opgehaald moeten worden is dat aan pure data al minimaal 2000 * 25 * 4 = 200KB. Er zitten diverse stukken varchars bij dus ik gok dat het zelfs wel wat meer is.
Dan komt er nog een flinke zwik tabel-code omheen, met als gevolg dat de html nog veel groter is dan de data zelf.

De vraag van André is dus het best en dat zal uitgezocht moeten worden. Gebruik timing-functies van (microtime bij php bijv.) om te achterhalen hoelang het ophalen van de gegevens uit de database duurt.
Mocht blijken dat het toch aan mysql ligt, dan kan je diverse oplossingen proberen uit te werken;
- De data op de server in een database opslaan, ipv lokaal, evt via replicatie.
- Een andere vorm van efficientere caching. Bijvoorbeeld een die verandert als je wat verandert, ipv pas opnieuw opgehaald wordt bij een nieuwe request.

Mocht het aan de enorme lap html liggen, zorg er dan in ieder geval voor dat je dat minimaliseert. Gebruik zoveel mogelijk css om de tabel-code zo klein mogelijk te houden.
En mocht het niet de opbouwtijd van de html zelf zijn (lastig te timen), maar de transfer-tijden van de html van je server naar je client, kijk dan in ieder geval nog naar gzip-compressie van de html (bijv via php's ob_start('ob_gzhandler'))

[edit]
Hmm, allemaal reacties geplaatst ondertussen

Ik gebruik al zo veel mogelijk CSS, enige attribuut is class="summary", omaan te geven welke stijl hij moet hebben.

Ik zal eens kijken of het ligt aan het laden van de pagina, door de tabel plain text op te slaan en te kijken of hij dan nog langzaam laadt.

Standeman schreef op zondag 29 mei 2005 @ 11:47:
Heb je al gekeken in MySQL Control Center (of de console app) hoe lang je query doet. Hier thuis doet een dergelijke query er ongeveer 2 ms over om een soortgelijke query (innoDB table) erover om de data op te halen.

Nee, niet gedaan, zal daar ook eens naar kijken

[edit]
De HTML output is ook traag, dus het heeft eigenlijk niet zo veel met MySQL te maken, maar meer met het laten zien van de data. Denk dat de enige oplossing dan het opdelen in pagina's is, of niet ?

[ Voor 5% gewijzigd door Scott op 29-05-2005 12:16 ]

[ACM]

ScottB schreef op zondag 29 mei 2005 @ 11:56:
De HTML output is ook traag, dus het heeft eigenlijk niet zo veel met MySQL te maken, maar meer met het laten zien van de data. Denk dat de enige oplossing dan het opdelen in pagina's is, of niet ?

ook of vooral?

Anyway, ja het beperken van de hoeveelheid data die naar de client gaat is je enige optie dan. Hoe je dat precies wilt beperken moet je zelf weten. Je kan inderdaad paginering gebruiken, standaard alleen een zoekvenster of "beginletter lijst" tonen. Of eerst alleen de meest opgevraagde of meest recente records tonen, etc.
Wees creatief en pas het zoveel mogelijk op de wensen van je gebruikers aan.

[ Voor 9% gewijzigd door ACM op 29-05-2005 12:26 ]

[Paul]

offtopic:
Ik zou een tabel waar je AL je data in 1x in laat zien geen summary durven noemen

Waar bevind zich die server, waar zit jij te browsen en hoe snel is de connectie daartussen? Je zegt dat de server thuis staat, dus met een gemiddelde ADSL-lijn ben je al 4 seconden aan het uploaden voor die 200kb data, nog zonder de HTML-codes etc mee te tellen...

[Scott]

ACM schreef op zondag 29 mei 2005 @ 12:25:
[...]

ook of vooral?

Anyway, ja het beperken van de hoeveelheid data die naar de client gaat is je enige optie dan. Hoe je dat precies wilt beperken moet je zelf weten. Je kan inderdaad paginering gebruiken, standaard alleen een zoekvenster of "beginletter lijst" tonen. Of eerst alleen de meest opgevraagde of meest recente records tonen, etc.
Wees creatief en pas het zoveel mogelijk op de wensen van je gebruikers aan.

Dan ga ik voor paginering, de anderen zijn niet zo van toepassing hiervoor

Bedankt voor de hulp allemaal !

Paul Nieuwkamp schreef op zondag 29 mei 2005 @ 12:28:

offtopic:
Ik zou een tabel waar je AL je data in 1x in laat zien geen summary durven noemen

Waar bevind zich die server, waar zit jij te browsen en hoe snel is de connectie daartussen? Je zegt dat de server thuis staat, dus met een gemiddelde ADSL-lijn ben je al 4 seconden aan het uploaden voor die 200kb data, nog zonder de HTML-codes etc mee te tellen...

offtopic:
Gaat er om dat ik die tabel een stijl meegeef, naam van die class maaat toch niet uit dan ?

Ik bezoek de server via het netwerk, waarvan de connectie een stuk sneller is dan 200kB. Het wordt wel een probleem als mensen buiten het netwerk de server bezoeken. De upload-snelheid die we (zouden moeten) hebben, is 128 kB/s, dus dat valt nog wel mee

[ Voor 41% gewijzigd door Scott op 29-05-2005 12:38 ]