[PHP] PDO->prepare() duurt ruim 1 seconde

[digital-IMEI]

Hi allen,

Ik zit met een uitdaging waar ik niet in verder kom en totaal niet weet waar ik moet zoeken.
Op m'n W7 machine heb ik XAMPP geïnstalleerd voor het nodige test en ontwikkelwerk in PHP + MySQL maar sinds enkele dagen is zowel alles wat ik doe traag en dan bedoel ik echt traag! (tientallen seconden om een pagina te genereren). Aangezien het zo traag is icm met een nieuwe laptop (Q3612QM + SSD) weet ik eigenlijk zeker dat het in de software zit maar ik weet niet waar ik moet zoeken en moet troubleshooten.

Ik heb het volgende:

PHP:

class Database{ 
    public static function siteDatabase(){
        try{
            return new PDO("mysql:host=". DATABASE_HOST .";dbname=". DATABASE_SITE ."",DATABASE_USERNAME, DATABASE_PASSWORD);
        }
        catch(PDOException $ex){
            echo 'Connection failed: ' . $ex->getMessage();
        }
    }
}

*even alle crap weg gelaten

Als ik dan het volgende uitvoer, ongeacht de inhoud van de query duurt het ruim 1 seconde:

PHP:

$query = Database::siteDatabase()->prepare($select);

Ik heb dit online (hosting) getest en daar draait alles prima en kost het 0,001 seconde.

Waar het iets mee te maken kan hebben is dat ik een nieuwe XAMPP installatie op een kale W7 heb gedaan en vervolgens de MySQL databases uit een backup in terug heb gezet (de files terug geplaatst), alleen heb ik dit probleem pas sinds enkele dagen en heeft het daarvoor met dezelfde setup prima gewerkt....

Is er ergens een log of iets wat ik kan aanzetten om te loggen, zodat ik kan terug vinden waarom de prepare zo`n vertraging oplevert?

disclaimer: tijden zijn gemeten in PHP microtime()

2e disclaimer: Ik ben nog niet lang bezig met OOP en PDO dus feedback omtrent een betere aanpak oid is natuurlijk ook welkom

[ Voor 34% gewijzigd door digital-IMEI op 14-08-2012 23:16 . Reden: aangevuld ]

[Xanland]

Dus alleen als je die regel uitvoert dan doe je er al 1 seconde over...?
Zo niet, probeer over kleinere stukjes waar die regel code staat te kijken hoelang het duurt.

Hoe complex is btw de select? Als het een zeer complexe is of er een klein foutje inzit kan de tijd al flink oplopen. Daarbij als je variablen in die select gebruikt, kan je dat beter overlaten aan bindParam.

[ Voor 41% gewijzigd door Xanland op 14-08-2012 23:26 . Reden: Meh, toch bindParam. ]

[Verwijderd]

Duurt de prepare zo lang of de connect die je uitvoert in siteDatabase()? Dus wat als je

PHP:

$start = microtime(true);
$pdo = Database::siteDatabase();
$instanceCreated = microtime(true);
$query = $pdo->prepare($select);
$finished = microtime(true);

doet en vervolgens kijkt wat instanceCreated - start en query - instanceCreated is?

Overigens kun je beter je PDO instance ergens bewaren, nu verbind je elke keer opnieuw met de database als je een nieuwe query prepared, terwijl je verbinding gewoon gedurende de request actief blijft.

Lees ook de reacties in dit topic eens door, kheb daar een behoorlijk compleet voorbeeld voor PDO gebruik gepost.

[eek]

Ben je misschien lokaal met je live database aan het praten?

[Gomez12]

Probeer eens op een andere manier met je mysql te verbinden en het zelfde uit te voeren (bijv navicat oid)
Voor hetzelfde geld zit er iets vreemds in je mysql instellingen van je xampp.

[digital-IMEI]

Xanland schreef op dinsdag 14 augustus 2012 @ 23:23:
Dus alleen als je die regel uitvoert dan doe je er al 1 seconde over...?
Zo niet, probeer over kleinere stukjes waar die regel code staat te kijken hoelang het duurt.

Yup, komt echt door deze regel, heb alles er tussenuit gehaald (helaas).

Hoe complex is btw de select? Als het een zeer complexe is of er een klein foutje inzit kan de tijd al flink oplopen. Daarbij als je variablen in die select gebruikt, kan je dat beter overlaten aan bindParam.

Standaard gebruik ik inderdaad bindParam maar de inhoud van de select maakt geen noemenswaardig verschil, een standaard "select id" duurt al 1.01514sec.

code:

SELECT `T0`.`page_id` FROM `dbo.core.url` AS T0

Verwijderd schreef op woensdag 15 augustus 2012 @ 01:10:
Duurt de prepare zo lang of de connect die je uitvoert in siteDatabase()? Dus wat als je

PHP:

$start = microtime(true);
$pdo = Database::siteDatabase();
$instanceCreated = microtime(true);
$query = $pdo->prepare($select);
$finished = microtime(true);

doet en vervolgens kijkt wat instanceCreated - start en query - instanceCreated is?

Yes, hier had ik zelf nog niet aan gedacht en blijkt dus ook dat het probleem is. De vertraging zit dus niet in de prepare mare in het connecten.

PHP:

$pdo = Database::siteDatabase();

duurt 1.02833sec en de select maar 0.00007sec.

Overigens kun je beter je PDO instance ergens bewaren, nu verbind je elke keer opnieuw met de database als je een nieuwe query prepared, terwijl je verbinding gewoon gedurende de request actief blijft.

Lees ook de reacties in dit topic eens door, kheb daar een behoorlijk compleet voorbeeld voor PDO gebruik gepost.

Ga ik me in verdiepen, dank!

eek schreef op woensdag 15 augustus 2012 @ 06:43:
Ben je misschien lokaal met je live database aan het praten?

Nop, dubbel gecheckt, echt lokaal.

Gomez12 schreef op woensdag 15 augustus 2012 @ 07:43:
Probeer eens op een andere manier met je mysql te verbinden en het zelfde uit te voeren (bijv navicat oid)
Voor hetzelfde geld zit er iets vreemds in je mysql instellingen van je xampp.

Dit was ik in de OP vergeten te vermelden, met Navicat werkt alles gewoon prima zonder enige vertraging, ook als ik complexere queries uitvoer krijg ik vrijwel een instant result.

Hoe nu verder te borduren op de vertraging tijdens het connecten naar de DB?

[Manuel]

Wat is de waarde van DATABASE_HOST? Als het localhost is vervang het dan eens door '127.0.0.1'.

[digital-IMEI]

Manuel schreef op woensdag 15 augustus 2012 @ 12:10:
Wat is de waarde van DATABASE_HOST? Als het localhost is vervang het dan eens door '127.0.0.1'.

uh?! Ik las je post en dacht echt "ag, kleine moeite om te proberen"

Nu kom ik dus gewoon op 0.01596sec totaal?! Where did it go wrong???

Thanks in ieder geval!

[johnkeates]

Lijkt er op dat je een DNS timeout krijgt en dat ie daarna pas automatisch naar 127.0.0.1 gaat.
Misschien dat ie eerst ::1 probeert, en als dat niet lukt, dat ie dan pas verder wil.

[ Voor 31% gewijzigd door johnkeates op 15-08-2012 12:39 ]

[CH4OS]

DNS zou het an sich niet mogen zijn; op alle PC's is een hosts-file aanwezig, waarin sowieso localhost verwijst naar 127.0.0.1, waarbij de inhoud van de hosts file altijd voor gaat op DNS. Daarnaast is een DNS timeout standaard altijd 1 minuut (zover ik weet).

Enige wat ik me dus kan bedenken is een vreemde hosts file, waarin dus de koppeling localhost en 127.0.0.1 niet gelegd is.

[ Voor 19% gewijzigd door CH4OS op 15-08-2012 13:45 ]

[Kalentum]

CptChaos schreef op woensdag 15 augustus 2012 @ 13:08:
Enige wat ik me dus kan bedenken is een vreemde hosts file, waarin dus de koppeling localhost en 127.0.0.1 niet gelegd is.

In de standaard Windows 7 hosts file wordt die koppeling niet meer gelegd. Als ik op de command line "ping localhost" doe, vertaalt windows localhost als "::1" en waarschijnlijk luistert mysql daar niet op.

[CH4OS]

Omdat in Windows 7 IPv6 het standaard protocol is (default staan IPv4 en IPv6 aan), ook die staat gedefinieerd in de hosts file.

[Manuel]

Het hangt er compleet vanaf of MySQL alleen op '127.0.0.1' luistert of ook op '::1'. Met rutgerw dus.

[digital-IMEI]

johnkeates schreef op woensdag 15 augustus 2012 @ 12:39:
Lijkt er op dat je een DNS timeout krijgt en dat ie daarna pas automatisch naar 127.0.0.1 gaat.
Misschien dat ie eerst ::1 probeert, en als dat niet lukt, dat ie dan pas verder wil.

rutgerw schreef op woensdag 15 augustus 2012 @ 14:01:
[...]
In de standaard Windows 7 hosts file wordt die koppeling niet meer gelegd. Als ik op de command line "ping localhost" doe, vertaalt windows localhost als "::1" en waarschijnlijk luistert mysql daar niet op.

Dit is inderdaad het geval geweest. Waarom het in eerste instantie heeft gewerkt blijft voor mij een raadsel...

Nu wil ik nog wel eens wat aanpassingen doen in m`n hosts file maar kan me niet herinneren dat ik localhost heb aangepast/toegevoegd.
Het begin van m`n hosts file is

code:

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#   127.0.0.1       localhost
#   ::1             localhost

Mijn inziens niets spannends, wat ook volgens Microsoft zou moeten kloppen

Een snelle check bij MySQL toont inderdaad aan dat IPv6 standaard inderdaad niet werkt

The default MySQL server configuration permits only IPv4 connections, so the server must be configured for IPv6 connections. To permit IPv6 connections in addition to or instead of IPv4 connections, start the server with an appropriate --bind-address option. See Section 5.1.4, “Server System Variables”.

bron

[Matis]

Een hash (#) voor de regel houdt normaliter in dat heel de volgende regel commentaar is.
In de hostfile die je hierboven laat zien, zou ik de hash voor 127.0.0.1 localhost weghalen.

Al werk ik eigenlijk altijd met 127.0.0.1 ipv localhost. Op mijn bedrijfsnetwerk wil localhost soms wel eens vertaald worden naar www.localhost.com

[Otherside1982]

Matis schreef op donderdag 16 augustus 2012 @ 08:23:
Een hash (#) voor de regel houdt normaliter in dat heel de volgende regel commentaar is.
In de hostfile die je hierboven laat zien, zou ik de hash voor 127.0.0.1 localhost weghalen.

Al werk ik eigenlijk altijd met 127.0.0.1 ipv localhost. Op mijn bedrijfsnetwerk wil localhost soms wel eens vertaald worden naar www.localhost.com

Heb je de commentaar regel boven "# 127.0.0.1 localhost" ook gelezen? "#Localhost name resolution is handled within DNS".
Probleem zal dus inderdaad veroorzaakt worden doordat localhost eerst naar IPv6 ::1 vertaald wordt, en MySQL daar niet op luistert.

[CH4OS]

Sowieso, localhost wíl je niet via je DNS resolven, daar krijg je juist problemen van (zoals deze), omdat je juist af gaat wijken van de standaard.