[PHP / MySQL] Too Many Connections bij 2+ bezoekers

[Cheater]

Hoe kan het komen dat als er 2 bezoekers in een PHP systeem zitten, de MySQL processenlijst vol komt te met processen 'sleep'. Bij 1 bezoeker, blijft de proceslijst netjes schoon. Maar bij 2 bezoekers begint hij vol te lopen.

Het gaat om een systeem waarbij een refresh van 2 seconden is verwerkt. De output naar de browser is minimaal. Ik heb al de regel mysql_close() in het script gezet.

Maar wat ik dus zo raar vindt is, hoe kan het dat bij 1 bezoeker de processenlijst netjes leeg blijft, en bij 2 bezoekers vol begint te lopen?
Kan het zijn dat ik de verbinding van een andere bezoeker sluit? Ik gebruik namelijk geen reference in de mysql_close() ... zoals: mysql_close($link);

[Saeverix]

de oorzaak zal vast zijn: crappy coding. dit is meestal het geval bij zulk soort fouten.
ik zou je code eens gaan debuggen...

[Zr40]

Dat je geen link identifier opgeeft maakt niet uit. PHP gebruikt dan de laatst geopende link die binnen het huidige script geopend is. Daarnaast sluit PHP geopende links als het einde van het script bereikt is.
Wanneer er diverse slapende processen in de lijst staan, krijgen de gebruikers dan te maken met timeouts?

[Cheater]

Zr40 schreef op zaterdag 15 januari 2005 @ 11:21:
Wanneer er diverse slapende processen in de lijst staan, krijgen de gebruikers dan te maken met timeouts?

Nope...

[Cheater]

Ik merk dat als ik alleen op de site zit, en ik druk bij die pagina (waarbij deze problemen ontstaan) 20 keer op F5, dan zijn er ook ineens 20 verbindingen actief. Als ik dit bij de index doe (waar ook een connectie wordt gemaakt) krijg ik bij 20 refreshes maar uiteindelijk 1 verbinding te zien, (maar wel met een ProcesID die 20 getallen hoger ligt)

[Zr40]

Gebruik je toevallig ergens mysql_pconnect()?

quote: http://nl3.php.net/manual/en/function.mysql-pconnect.php

Using persistent connections can require a bit of tuning of your Apache and MySQL configurations to ensure that you do not exceed the number of connections allowed by MySQL.

[ Voor 74% gewijzigd door Zr40 op 15-01-2005 11:40 . Reden: Quote van PHP-documentie toegevoegd ]

[djluc]

Je hebt toch wel in my.ini een instelling staan dat er meer dan 2 mogen komen?

[PanMan]

pconnect, zou ook mijn eerste gok zijn..
Anders moet je toch ff wat relevante stukken code posten.

[Verwijderd]

lijkt idd met de persistent connecties te maken te hebben.

Ik heb zelf een ssortgelijke foutmelding gehad, daar was de oplossingen om het maximale aantal connections van MySQL aan te passen.

in mijn geval kon Apache 512 processen draaien, en MyQSL 100 connecties tegelijk open hebben, de oplossing was om het aantal connections van MySQL ,standaard 100 geloof ik, op te hogen tot 514.
Dus hoger dan het aantal processen dat Apache kon draaien.

Dus zet het aantal maximale connecties in MySQL hoger en test nog eens.

[Cheater]

Ik gebruik nooit Persistent Connections.... nog nooit gedaan ook niet.

[Cheater]

Ik weet niet of het hier aan ligt maar:

Het script gebruikt een queries IN while lussen. Dit gaat wel tot 4 lagen diep:

code:

function get_toernooien() {
  $toernooi_query = "SELECT id,naam,begindatum,land,plaats FROM toernooien ORDER BY id";
  $toernooi_result = mysql_query($toernooi_query);
  $toernooi_aantal = mysql_num_rows($toernooi_result);
  if ($toernooi_aantal > 0) {
    while ( list ( $d_t_id,$d_toernooi_naam,enzovoorts, ) = mysql_fetch_row ( $toernooi_result ) )
    { 
      $wedstrijd_query = "SELECT id, now_live, enzovoorts FROM toernooi_game WHERE toernooi_id = $d_t_id";
      $wedstrijd_result = mysql_query($wedstrijd_query);
      $wedstrijd_aantal = mysql_num_rows($wedstrijd_result);
      
      if ($wedstrijd_aantal > 0) {
        while ( list ( $d_w_id,$d_now_live,enzovoorts, ) = mysql_fetch_row ( $wedstrijd_result ) )
        {
          $set_query = "SELECT id, enz FROM toernooi_game_sets WHERE game_id = $d_w_id ORDER BY id";
          $set_result = mysql_query($set_query);
          $set_aantal = mysql_num_rows($set_result);  
          if ($set_aantal > 0) {
            while ( list ( $d_set_id, $d_speler1_legs, $d_speler2_legs, ) = mysql_fetch_row ( $set_result ) )
            {
              $leg_query = "SELECT leg_id, enz WHERE set_id = $d_set_id ORDER BY leg_id,volgnummer";
              $leg_result = mysql_query($leg_query);
              $leg_aantal = mysql_num_rows($leg_result);
              if ($leg_aantal > 0) {
                while ( list ( $d_leg_id, enzovoorts, ) = mysql_fetch_row ( $leg_result ) )
                {  
                  
                }
                mysql_free_result($leg_result);
              }
            }
            mysql_free_result($set_result);
          }
        }
        mysql_free_result($wedstrijd_result);
      }
    }
    mysql_free_result($toernooi_result);
  }
  return $toernooien;
}

Ik heb de mysql_free_results er maar bij gezet, want ik ben een beetje ten einde raad... Is dit gewoon te zwaar voor PHP ofzo? De pagina wordt om de 2 seconden gerefresht (dat is perse nodig, maar kan in het ergste geval maximaal naar 3 seconden verhoogd worden).

Er worden allerlei gegevens in een 'tot wel' 12 dimensionele array opgeslagen.
Voorbeeld:
$toernooien['toernooi'][$h]['wedstrijd'][$i]['set'][$j]['leg'][$k]['worp'][$l]['aantal_worpen'][0]
Hier zou het getal 3 in kunnen staan.

In elke array diepte worden weer verschillende gegevens opgeslagen die nodig zijn. Nu worden enkel en alleen een paar gegevens weergegeven op het scherm, maar straks moeten er eigenlijk ook grafieken uit getekend kunnen worden.

Misschien dat iemand mij nu raad kan geven?

[ Voor 16% gewijzigd door Cheater op 16-01-2005 00:51 ]

[PanMan]

Probeer eens uit te leggen wat je wilt bereiken? Ik denk dat het er aan ligt dat je om de 2 sec refresht. W.s. is PHP dan nog niet helemaal klaar, oid, en blijft hij ahw draaien? Waarom is om de 2 sec nodig? En wat is de rendertijd van deze pagina?
En, om de 2 sec een nieuwe grafiek maken lijkt me al helemaal niet bevorderlijk voor je systeem (wat als er nog meer dan 2 users komen?)

[Cheater]

PanMan schreef op zondag 16 januari 2005 @ 01:16:
Probeer eens uit te leggen wat je wilt bereiken?

Ik ben bezig met een dart-uitslag systeem. Bezoekers van de site kunnen de score van een dartwedstrijd live volgen.

Ik denk dat het er aan ligt dat je om de 2 sec refresht. W.s. is PHP dan nog niet helemaal klaar, oid, en blijft hij ahw draaien?

Wat is 'ahw'?

Waarom is om de 2 sec nodig?

Om de score zo accuraat mogelijk te houden. Er wordt nogal snel gegooid in een prof dartwedstrijd.

En wat is de rendertijd van deze pagina?

Geen Oftewel, ongeveer 30 regels aan javascript worden in de pagina gezet om de content te vullen. Verder blijft het een blanco pagina.

En, om de 2 sec een nieuwe grafiek maken lijkt me al helemaal niet bevorderlijk voor je systeem (wat als er nog meer dan 2 users komen?)

Het is ook niet de bedoeling dat een grafiek om de 2 secs opnieuw geladen wordt. dat is voor Single view only (dus zonder refresh)

[ Voor 4% gewijzigd door Cheater op 16-01-2005 04:08 ]

[Verwijderd]

ORDER BY ID
is niet echt nodig. De database pakt standaard altijd de fysieke volgorde van de tabel.

while (list( $d_t_id,$d_toernooi_naam,enzovoorts,) = mysql_fetch_row ( $toernooi_result ))
Misschien dat mysql_fetch_assoc() een meer optimale benadering is van de rijen.
while ( $row=mysql_fetch_assoc( $toernooi_result ) )

Trouwens, je roept nu 4 verschillende queries aan die opvolgend steeds informatie ophalen.
Is één enkele query met meerdere JOINS niet optimaler? En dus een stuk sneller? MySQL moet dat zeker aankunnen.

return $toernooien;
12-dimensionaal...? Zit je elke keer weer de gehele dartdatabase in deze array in te lezen?

AHW = als het ware...

[PanMan]

Cheater schreef op zondag 16 januari 2005 @ 04:07:
[...]
Ik ben bezig met een dart-uitslag systeem. Bezoekers van de site kunnen de score van een dartwedstrijd live volgen.
[...]
Wat is 'ahw'?
Als het ware.
[...]
Om de score zo accuraat mogelijk te houden. Er wordt nogal snel gegooid in een prof dartwedstrijd.
[...]
Geen Oftewel, ongeveer 30 regels aan javascript worden in de pagina gezet om de content te vullen. Verder blijft het een blanco pagina.
[...]

Het is ook niet de bedoeling dat een grafiek om de 2 secs opnieuw geladen wordt. dat is voor Single view only (dus zonder refresh)

Ik heb een boel opmerkingen
Ten eerste: Volgens mij laad je veel te veel gegevens: Je hebt zeker geen 12 dimensionale array nodig om de gegevens van EEN wedstrijd in bij te houden. Wellicht dat je die wel nodig hebt voor een grafiek, maar dan kan je daar beter een andere pagina voor maken. Deze pagina zou volgens mij gewoon in 1 of 2 simpele array's moeten kunnen.
Met rendertijd bedoelde ik rendertijd op de server, hoe lang duurt het om deze pagina te genereren? Dat is eenvoudig te meten met PHP zelf.
Ten derde: Hoe snel staan de gegevens in die DB? Als dat niet live gebeurd, kan die 2 sec vertraging ook wel wat omhoog: Als elke beurt 15 sec duurt om in te voeren, is die 2 sec ook minder relevant.

Maar, belangrijkste is denk ik toch dat je w.s. (WaarSchijnlijk ) te veel gegevens ophaalt. Kan je niet gewoon met iets als "select * from wedstrijd_gooien where wedstrijdid=123" de voor jou relevante gegevens ophalen? Dan moet je later een uitgebreidere pagina maken voor je graffiek, maar daar is het ook niet zo erg als de bezoeker 1 sec oid moet wachten. (en die grafiek kan je later wellicht cachen).

[Janoz]

Dus, je voert om de 20 sec per bezoeker toernooien x wedstrijden x sets x legs queries los op de db en vraagt je af waar de performance problemen vandaan komen?

Misschien is het een goed idee om eens een willekeurige database tutorial erbij te pakken en eens te kijken bij het hoofdstuk joins. Al deze gegevens zijn namelijk ook in 1 query op te halen.

[djluc]

Janoz schreef op zondag 16 januari 2005 @ 14:26:
Dus, je voert om de 20 sec per bezoeker toernooien x wedstrijden x sets x legs queries los op de db en vraagt je af waar de performance problemen vandaan komen?

Toch zie ik geen verband tussen een too many connections melding en vele queries uitvoeren. Ik ga er hierbij wel vanuit dat de parsetime van de pagina's niet langer is dan 2 seconden. Misschien zou de TS dat sowieso eens kunnen meten?

[Cheater]

Kees Netelvrees schreef:
ORDER BY ID
is niet echt nodig. De database pakt standaard altijd de fysieke volgorde van de tabel.

Uiteraard. dat komt neer op Sorting, while already being sorted. Zal in het vervolg eraan denken.

Kees Netelvrees screef:
while (list( $d_t_id,$d_toernooi_naam,enzovoorts,) = mysql_fetch_row ( $toernooi_result ))
Misschien dat mysql_fetch_assoc() een meer optimale benadering is van de rijen.
while ( $row=mysql_fetch_assoc( $toernooi_result ) )

Ik zal kijken of ik het kan toepassen.

Kees Netelvrees screef:
Trouwens, je roept nu 4 verschillende queries aan die opvolgend steeds informatie ophalen.
Is één enkele query met meerdere JOINS niet optimaler? En dus een stuk sneller? MySQL moet dat zeker aankunnen.

Zeker zeker, maar als ik dit in een LIJST zou zien, krijg ik dan niet:

code:

----------------------------------------------------------------------------------------------------------------
| toernooi_id | gegeven  | wedstrijd_id | gegevens  | set_id | gegevens  | leg_id | gegevens | worp | gegevens |
| 1           | LakeSide | 1            | set_stand | 1      | leg_stand | 1      | iets     | 1    | iets     |
| 1           | LakeSide | 1            | set_stand | 1      | leg_stand | 1      | iets     | 1    | iets2    |
| 1           | LakeSide | 1            | set_stand | 1      | leg_stand | 1      | iets     | 1    | iets3    |
| 1           | LakeSide | 1            | set_stand | 1      | leg_stand | 1      | iets     | 1    | iets4    |
| 1           | LakeSide | 1            | set_stand | 1      | leg_stand | 1      | iets     | 2    | iets     |
| 1           | LakeSide | 1            | set_stand | 1      | leg_stand | 1      | iets     | 2    | iets2    |
| 1           | LakeSide | 1            | set_stand | 1      | leg_stand | 2      | iets2    | 1    | iets     |
| 1           | LakeSide | 1            | set_stand | 1      | leg_stand | 2      | iets2    | 1    | iets2    |
| 1           | LakeSide | 1            | set_stand | 1      | leg_stand | 2      | iets2    | 1    | iets     |
| 1           | LakeSide | 1            | set_stand | 2      | leg_stand | 1      | iets     | 1    | iets     |
| 1           | LakeSide | 1            | set_stand | 2      | leg_stand | 1      | iets     | 1    | iets2    |
| 1           | OpenNL   | 1            | set_stand | 1      | leg_stand | 1      | iets     | 1    | iets     |
----------------------------------------------------------------------------------------------------------------

En roep ik zo niet weer het probleem van inconsistensie op? Ik dacht hier toen straks nog even aan, en dacht bij mezelf: ach, inconsistentie maakt niet zo heel veel uit zolang het maar IN de code gebeurd, en niet als het opgeslagen wordt (in mysql).

Kees Netelvrees screef:
return $toernooien;
12-dimensionaal...? Zit je elke keer weer de gehele dartdatabase in deze array in te lezen?

Jazeker. Wat op zich geen probleem moet zijn aangezien het maar 4 tabellen zijn. (1 klein tabelletje waar de toernooi-info instaat (er staan hier na 1 jaar ongeveer 10 rows in voor 10 toernooien))

PanMan schreef:
Volgens mij laad je veel te veel gegevens: Je hebt zeker geen 12 dimensionale array nodig om de gegevens van EEN wedstrijd in bij te houden.

Leesfout: ALLE toernooien met hun wedstrijden, met hun sets, met hun legs, met hun worpen... worden ingeladen in deze 12 dimensionale array.

PanMan schreef:
Deze pagina zou volgens mij gewoon in 1 of 2 simpele array's moeten kunnen.

Dat kan hij ook, maar deze code is 1 functie die voor meteen alles gebruikt kan worden. Want als ik later wat meer info bij m'n pagina wil plaatsen (die ik uit de database moet halen, en vervolgens berekenen) ben ik meer tijd kwijt dan dit in 1 keer goed doen.

PanMan schreef:
Met rendertijd bedoelde ik rendertijd op de server, hoe lang duurt het om deze pagina te genereren?

Ok... miscommunicatie. Ik noem dit namelijk parsetime, zoals m'n medetweakers dit doen.

PanMan schreef:
Hoe snel staan de gegevens in die DB? Als dat niet live gebeurd, kan die 2 sec vertraging ook wel wat omhoog: Als elke beurt 15 sec duurt om in te voeren, is die 2 sec ook minder relevant.

Dit gebeurd dus wel live. Er is 1 persoon die op het moment dat de worp is gegooid deze score meteen intypt. Dit is voor de bezoeker dan ook direct te zien (dmv de 2sec refresh) Nu ik dit zo simpel zeg denk je... waarom dan zo'n code die alles eruit haalt? Nou: stel ik wil het gemiddelde over alle toernooien laten zien van een bepaalde darter?

Janoz schreef:
Dus, je voert om de 20 sec per bezoeker toernooien x wedstrijden x sets x legs queries los op de db en vraagt je af waar de performance problemen vandaan komen?

2 seconden .... Het lijkt zo vanzelfsprekend he, dat de performance zo drastisch omlaag gaat. Maar als je wat verder denkt: waarom zou PHP/MySQL geen 150 queries aankunnen? Het is trouwens niet toernooien x wedstrijden x sets x legs. Want dat is het aantal rows, in het resultaat als je al deze queries zou verpakken in 1 querie. Het feitelijke aantal queries is: query_toernooien (1) + aantal_toernooien + aantal_wedstrijden | aantal_sets queries.
Wat op dit moment neerkomt op: 2 + 23 + 95 = 120 queries
Op mijn werk doe ik een INSERT query wel 300 keer, zonder moeite.

djluc schreef:
Toch zie ik geen verband tussen een too many connections melding en vele queries uitvoeren.

Ik dus ook niet, maar ondanks die gedachte had ik toch de 'mysql_free_result($resource);' toegevoegd.

djluc schreef:
Ik ga er hierbij wel vanuit dat de parsetime van de pagina's niet langer is dan 2 seconden. Misschien zou de TS dat sowieso eens kunnen meten?

Bij 1 bezoeker van het systeem WEL. Dan is hij snel. Bij 2 bezoekers is de parsetime langer dan 2 seconden. Toch snap ik het niet. Als ik als enkele bezoeker in het systeem de F5 knop in blijf drukken (dus constantly refresh) dan komt er niet meer dan 1 proces in het processenlijstje te staan (exclusief de 'show proceslist'). Als ik 2 browsers doe: 1 browser laat het systeem via de 2sec refresh verversen, en de andere doe ik met de F5 constantly refresh. Dan krijg ik bij 20 refreshes (bij die F5 manier) ook 20 processen die even actief blijven. Dit mag dus niet.

[ Voor 8% gewijzigd door Cheater op 17-01-2005 03:02 ]

[Verwijderd]

Leesfout: ALLE toernooien met hun wedstrijden, met hun sets, met hun legs, met hun worpen... worden ingeladen in deze 12 dimensionale array.

Ik zou de website bezoeker(s) vooraf gewoon dwingen één bepaalde wedstrijd te kiezen, en daarvan dan de uitslagen weer te geven. Dat scheelt al een boel data om op te hoesten.

waarom dan zo'n code die alles eruit haalt? Nou: stel ik wil het gemiddelde over alle toernooien laten zien van een bepaalde darter?

Dan maak je daar toch een aparte query voor, en dan nog alleen wanneer dit gevraagd wordt door de bezoeker. Nu haal je continue -alles- uit de database, en laat je waarschijnlijk ook nog elke keer door PHP het gemiddelde berekenen. Terwijl je dit rekenen ook nog door de database-server kan laten doen (als hij tenminste er de tijd en ruimte voor krijgt).

[PanMan]

Cheater schreef op maandag 17 januari 2005 @ 02:35:
Leesfout: ALLE toernooien met hun wedstrijden, met hun sets, met hun legs, met hun worpen... worden ingeladen in deze 12 dimensionale array.
[.....]
Dat kan hij ook, maar deze code is 1 functie die voor meteen alles gebruikt kan worden. Want als ik later wat meer info bij m'n pagina wil plaatsen (die ik uit de database moet halen, en vervolgens berekenen) ben ik meer tijd kwijt dan dit in 1 keer goed doen.

Ik zou het systeem nooit zo opbouwen. Je kan wel alles wat je wil uit de DB trekken, omdat je het misschien wel ooit nodig zou hebben. Maar dat is onzin. Weet je wat, misschien wil je ook ooit iets met postcode's doen, haal ook ff fijn alle postcodes van nederland op

Maar zeker bij een pagina die elke 2 sec wordt gerefresth zou ik Veeeel minder gegevens ophalen: Gewoon wat je NU nodig hebt voor die pagina. Mocht je dat ooit meer willen maken, dan doe je dat dan maar, zorg je dat je dan meer gegevens ophaalt. Niet nu eerst alles ophalen, en dan maar een klein deel gebruiken. Zeker niet bij een pagina die elke 2 sec wordt opgeroepen.
En ik zou mensen verplichten 1 wedstrijd te kiezen, en die dan live te doen. Niet ELKE pagina van je site met uitslagen om de 2 sec te refreshen, omdat er misschien wel een wedstrijd nu bezig is. Dus 1 pagina met een live wedstrijd. En verder gewoon andere pagina's met historische gegevens, grafieken, gemiddelden, etc.
Just my 2 cents....

[Cheater]

Ik heb wat testmetingen gedaan, en ik heb de query aangepast.
Het is nu 1 query die 3 joins uitvoert...

Uiteindelijk, de parsetime is nu gemiddeld 1,3 seconde.
Maar ik heb meer testen gedaan:

Dezelfde data + testen voer ik uit op:
www.worlddartsplaza.nl: 1,3 seconde (gemiddeld)
www.cheater.nl 0,6 seconde (gemiddeld)
www.clan-league.com 2 seconde (gemiddeld)

worlddartsplaza en clan-league benaderen de mysql database lokaal. cheater gaat via een subdomein van cheater.nl

Maar weet je wat ik nou zo vind, ... als ik 10 keer op F5 druk, dan duurt de parsetime geen 1,3 seconde, maar 13 seconden!!!
What the hell... waardeloos gewoon. Het zou ook betekenen, dat als in die 1,3 seconden 100 bezoekers komen, de site plat ligt vanwege teveel connecties naar de mysql database. Ook al zoiets waardeloos. Dat je script niet te lang duurt omdat het anders te lang kan duren voor de bezoeker, alla.

Lokaal duurt de parsetime overigens 0,015 seconde.

[Verwijderd]

Cheater schreef op donderdag 20 januari 2005 @ 21:57:
Lokaal duurt de parsetime overigens 0,015 seconde.

Simpel, omdat alles in je lokale diskcache zit... Daar zit geen grammetje internet-verbinding bij.

[Cheater]

Verwijderd schreef op donderdag 20 januari 2005 @ 22:02:
Simpel, omdat alles in je lokale diskcache zit... Daar zit geen grammetje internet-verbinding bij.

Je motivatie is niet correct
Je motivatie geeft aan dat parsetime, de tijd van parsen + request from en/of response to client is.
Parsetime is de tijd die de server erover doet om het script, van het moment dat de request binnen is, TOT de output begint , te parsen

[Skaah]

Wat je zou kunnen doen, is controleren of er iets verandert is (in de database), dus of er weer een worp is geweest in jouw geval.
HTTP heeft hiervoor een mechanisme ingebouwd, wat je zou kunnen gebruiken.

Voeg een TIMESTAMP kolom toe aan je worpentabe:

code:

ALTER TABLE worpen ADD COLUMN worp_ts TIMESTAMP;

MySQL vult deze automagisch wanneer je een INSERT of UPDATE statement uitvoert.
Eerst controleer je wanneer de laatste worp ingevoerd is.

code:

SELECT worp_ts FROM worpen ORDER BY worp_ts DESC LIMIT 1;

Maak daar een Unixtimestamp van en ram dat getal in deze funtie:

PHP:

        /**
         * Controleer of we de pagina weer moeten opbouwen, of dat deze pagina
         * nog beschiktbaar is bij de client.
         * Indien de pagina nog beschikbaar is bij de client, wordt het script afgebroken.
         *
         * Note: overgenomen van www.php.net
         *
         * @param int timestamp Verplicht. De (unix)timestamp waarop één van de pagina's is gewijzigd.
         * @return void
         * @access public
         */
        function handle304($timestamp)
        {
                // Note that this is not a RFC 822 date (the tz is always GMT)
                $tsstring = gmdate("D, d M Y H:i:s ", $timestamp) . "GMT";

                // Check if the client has the same page cached
                if (isset($_SERVER["HTTP_IF_MODIFIED_SINCE"]) && ($_SERVER["HTTP_IF_MODIFIED_SINCE"] == $tsstring))
                {
                        header("HTTP/1.1 304 Not Modified");
                        exit();
                }

                // Inform the user agent what is our last modification date
                else
                {
                        header("Last-Modified: " . $tsstring);
                }
        }

Wat ik hier ook denk: heb je wel indexen op je FK?

[Cheater]

Skaah schreef op vrijdag 21 januari 2005 @ 09:13:
Wat ik hier ook denk: heb je wel indexen op je FK?

Ik denk dat ik me diep ga schamen .... op geen enkele ID kolom stond een Index gezet... maar dan alsvolgt... wat zijn de gevolgen als je dat niet hebt?

Wat is FK trouwens?


Edit:
Trouwens... er stond dit:

code:

Sleutelnaam Type     Kardinaliteit  Veld 
PRIMARY     PRIMARY  95             id

Zit er dan nou wel of geen Index op die kolom?

Nu ik op de Index heb geklikt bij het veld ID, komt er bij te staan (in phpmyadmin):

code:

Sleutelnaam Type     Kardinaliteit  Veld 
PRIMARY     PRIMARY  95             id  
id          INDEX    95             id

[ Voor 39% gewijzigd door Cheater op 22-01-2005 01:19 ]

[Arjan A]

Cheater schreef op zaterdag 22 januari 2005 @ 01:02:
[...]
Wat is FK trouwens?

Foreign Key

En zoals al eerder gesteld in dit topic: ga je inlezen.

Ik vind het prima als je vragen stelt, en ik vind het leuk dat je je mindere onderkent in deze materie. Maar je lijkt me pienter genoeg om met een *beetje* zelfstudie ver genoeg te komen.

[Cheater]

Beetje jammer, dat ik zo'n reactie krijg, aangezien dit soort problemen ook kunnen ontstaan bij ervaren gebruikers... ik ben wel bekend met de materie, maar nog nooit gebruik van gemaakt. het blijft over het algemeen vrij easy. En dit is ook nog vrij easy, alleen het probleem zit in de weg.

[J3roen]

Cheater schreef op zaterdag 22 januari 2005 @ 01:44:
Beetje jammer, dat ik zo'n reactie krijg, aangezien dit soort problemen ook kunnen ontstaan bij ervaren gebruikers... ik ben wel bekend met de materie, maar nog nooit gebruik van gemaakt. het blijft over het algemeen vrij easy. En dit is ook nog vrij easy, alleen het probleem zit in de weg.

Spijt me zeer, maar ik vind ook dat er al genoeg informatie is gegeven.
Je wekt dit dus niet bij alleen 1 persoon op.

[Cheater]

Nou wat mij opvalt is dat iedereen komt met... haal niet zoveel data op...

WTF? kan mysql / php -> INTERN <- geen 2000 rows verwerken?
Ik hoef alleen rekening te houden dat ik niet beneden de (request_time + parsetime + response_time + render_time) ga zitten met m'n refresh. Dus als ik op 5 seconden ga zitten, vind ik het abnormaal als het dan nog niet goed werkt.

Ik vind het ook belachelijk dat als ik bij een wat zwaardere pagina 100 keer refresh, de site eruit ligt... echt compleet waardeloos

my 2 cents

[Hagar]

Dat is juist wat we proberen duidelijk te maken.
Je moet mysql "intern" de benodigde rows laten selecteren/verwerken en daarna met php deze presenteren.

Het is nou eenmaal zo dat mysql dat het beste doet omdat het daarvoor gemaakt is.

[Cheater]

Hagar schreef op zaterdag 22 januari 2005 @ 03:12:
Dat is juist wat we proberen duidelijk te maken.
Je moet mysql "intern" de benodigde rows laten selecteren/verwerken en daarna met php deze presenteren.

Het is nou eenmaal zo dat mysql dat het beste doet omdat het daarvoor gemaakt is.

MySQL kan niet alle bewerkingen die ik met de data doe, doen...
Maar ik weet het goed gemaakt... ik ga de gemiddelden wel in de database opslaan samen met nog 30 andere dingen die ik berekende aan de hand van de gegevens die er nu in staan....

Blijkbaar mag je niet colY * colX , maar moet ik het antwoord ervan al opgeslagen hebben en alleen het antwoord ophalen anders krijg ik teveel dataload

[Sfynx]

Ik denk dat ik me diep ga schamen .... op geen enkele ID kolom stond een Index gezet... maar dan alsvolgt... wat zijn de gevolgen als je dat niet hebt?

Je id-velden zijn al keys, namelijk je primary keys. Maar als je in queries refereert naar andere velden in bv. de WHERE-clause, bv. bij:

SELECT * FROM blaat WHERE veld = 456;

gaat dat bij een wat grotere tabel voor een performance penalty zorgen zonder index op de kolom 'veld'. Er is dan namelijk geen 'register in het boek' aanwezig zodat de databaseserver zeg maar van A naar Z moet bladeren door de tabel heen i.p.v dat ie meteen een stuk kan skippen. En dat is maar 1 van de vele dingen waarvoor indexes worden gebruikt, zie ook http://dev.mysql.com/doc/mysql/en/MySQL_indexes.html Een goed database design met de indexes op de juiste plek is erg belangrijk voor de performance van een drukbezochte site.

Als je vervolgens ook voor elke pageview alleen de info uit de database haalt die op die pagina moet worden weergegeven, met als het even kan 1 slimme query die de informatie in zodanige hapklare brokken aanlevert dat je PHP er niet nog eens overheen moet 'rekenen', is het al aardig voor elkaar.

Een parsetime van 0,1 seconde voor een pagina op een redelijk snelle server met 1 gebruiker is al veel eigenlijk, het moet vermenigvuldigd met het aantal gelijktijdige gebruikers nog steeds acceptabel zijn.