mysqlnd verbinding maken is veel trager dan libmysql

[mookie]

Lang verhaal kort: een website die draait op
- windows server 2003 met apache 2.2 en php 5.2 en mysql 5.1 maakt gebruik van libmysql
zet ik over naar
- windows server 2012 met apache 2.4 en php 5.6.2 en mariadb 10 en maakt gebruikt van mysqlnd

Na wat testen blijkt het dat verbinding maken met een mysql server via mysqlnd vele malen trager is dan via libmysql.

Hoe getest? Een pagina gemaakt die:
new mysqli, mysqli->close, new mysqli, mysqli->close, unset(mysqli), mysql_connect, mysql_select_db, mysql_close aanroept
Vooraf en achteraf de tijd bepaalt met microtime(true)
Vervolgens bovenstaande verhaal 4 keer doet (1x mysql5.1 IP, 1x mariadb10.0.14 IP, 1x mysql5.1 DNS, 1x mariadb10.0.14 DNS)

Getest in de volgende setups:
originele server met php 5.2.17 (libmysql)
Originele server met php 5.3.29 (mysqlnd)
Nieuwe server met php 5.2.17 (libmysql)
Nieuwe server met php 5.3.29 (mysqlnd)
Nieuwe server met php 5.5.14 (mysqlnd)
Nieuwe server met php 5.6.2 (mysqlnd)
windows XP computer met php 5.2.17 (libmysql)
windows xp computer met php 5.3.29 (mysqlnd)
windows 7 computer met php 5.2.17 (libmysql)
windows 7 computer met php 5.3.29 (mysqlnd)

Uit alle testen komt het volgende naar voren:

php 5.2 met libmysql: altijd onder de 0,002 seconden, vaak zelfs onder de 0,001 seconden
php hoger dan 5.2 met mysqlnd: een enkele keer rond de 0,002 seconden, bijna altijd 0,015 seconden

Dat is toch 10 tot 15 keer trager. Ik zou ook niet weten waarom want mysqlnd zou veel efficienter moeten zijn.
Ik kan er ook niets over terugvinden op internet.

Ik kan me ook niet voorstellen dat een dergelijk verschil nooit is opgevallen...

Ik heb geen mogelijkheid om een linux variant te testen.
Is er iemand in de gelegenheid om ook eens te testen hoelang het duurt om een database verbinding te maken en dat te posten?
(wel mysql uiteraard).

[RobIII]

mookie schreef op donderdag 13 november 2014 @ 10:09:
Dat is toch 10 tot 15 keer trager. Ik zou ook niet weten waarom want mysqlnd zou veel efficienter moeten zijn.
Ik kan er ook niets over terugvinden op internet.

Ik vind de test(s) nogal karig; wie zegt (zonder de internals van PHP te kennen) of "Connect" (eender welke manier) wel daadwerkelijk een complete connectie inc. alle ceremonie opzet en 't niet gewoon uitstelt tot bijv. de eerste daadwerkelijk uitgevoerde query of niet? En is de ene niet met TLS en de andere zonder? En zo zijn er nog wel 15 factoren te verzinnen die kunnen meespelen in dit geheel (bijv; doe afzonderlijke en eerlijke tests, niet beide (of meer) tests achter elkaar; isoleer ze*). Ik zou dat eerst eens allemaal gaan bedenken / meten en niet te snel tot conclusies komen

* Je zult de tests moeten isoleren; doe je dat niet dan krijgt de eerste test (bijv) de kosten van DNS lookups erbij geschoven terwijl de andere tests profiteren van cached DNS gegevens en zo ook met "warme TCP connecties", "warme executie environments" en ga zo maar door. Als je meet, meet dan eerlijk. En wéét wat je meet.

[ Voor 21% gewijzigd door RobIII op 13-11-2014 10:36 ]

[MSalters]

Afgezien daarvan is het realistisch dat de nieuwe code beter geoptimaliseerd is.

Nu denk je misschien, beter? De code is trager!. Dat klopt voor het voorbeeld. Maar die code is al snel genoeg. Optimalisatie is vaak een kwestie van trade-offs, en dan is het niet erg om concessies te doen op gebieden waar je ruime marges had.

[mookie]

Hmm.. ik had eerst een openings post van 3 kantjes.
Dat leek me nogal saai en ingewikkeld te lezen dus heb het nogal ver gestript.

Maar laat ik voorop stellen dat ik nogal wat getest heb om het te isoleren.

Ik heb iig ook direct via het IP adres gedaan zodat DNS geen roet in het eten kon gooien, al blijkt dat dat niet echt voor vertraging zorgt.
Op DNS naam gaat praktisch net zo snel als met het IP adres.

Verders heb ik bij mysqli eerst connect en close gedaan en dat daarna nogmaals om te kijken of de verbinding echt wordt gesloten en of hij niet de 2de keer gewoon een oude verbinding hergebruikt.
Dit is niet het geval, zie ik ook terug op de server.
Iedere verbinding is een nieuwe schone verbinding.
De tweede verbinding heeft dus ook geen voordeeltjes zoals caches of al openstaande verbindingen.

Verders goed idee dat libmysql misschien niet de volledige verbinding opzet.
Dat had ik echter ook al getest door een "zware" query uit te voeren en de resultset in een array te plaatsen.
Zowel bij libmysql als bij mysqlnd duurt de query uitvoeren en in de array plaatsen altijd even lang, namelijk 0,034 seconden
Het verschil in verbindings tijden blijft echter zichtbaar.

mysql en mysqli settings zijn (voor zover dat mogelijk is) ten alle tijde hetzelfde.

Ik zie enkel de connect die meer tijd nodig heeft.
Wat zou ik verders nog kunnen testen?

[RobIII]

mookie schreef op donderdag 13 november 2014 @ 14:23:
Wat zou ik verders nog kunnen testen?

Nog 1001 dingen. Was de load op de MySQL bak ten tijde van de tests bij beide tests gelijk? Heb je mogelijk network congestion? Waarom een "zware" query en niet gewoon een "select version()"-achtig iets om variaties daarin zoveel mogelijk uit te sluiten? En zo kan ik nog wel wat zaken verzinnen...

Maar belangrijker is het geheel in perspectief te zien en in context te zetten en eens te beginnen bij 't begin (zie ook MSalters' post); is die '0,015sec' dan een probleem ofzo? Boeit 't dat je schijnbaar op manier A iets tragere connecties hebt dan op manier B (die dan mogelijk vervolgens op andere fronten weer meer winst oplevert)? Is het een bottleneck? Zijn we iets concreets aan 't oplossen of enkel die "tijd" naar beneden aan 't werken "omdat het kan"? M.a.w. Is er een echt issue? En zonder (de code van) je test(s) te kunnen zien en zonder diepgaande informatie/kennis over je netwerk setup, instellingen etc. etc. blijft 't toch altijd (deels) gokken. Maar begin dan in eerste plaats eens met aangeven waarom we hier überhaupt mee bezig zijn

mookie schreef op donderdag 13 november 2014 @ 14:23:
Hmm.. ik had eerst een openings post van 3 kantjes.
Dat leek me nogal saai en ingewikkeld te lezen dus heb het nogal ver gestript.

Maar laat ik voorop stellen dat ik nogal wat getest heb om het te isoleren.

Leuk, maar als je dan vervolgens die informatie achterwege laat (of stript) gaan wij hier vervolgens al die dingen die je "getest hebt om het te isoleren" nogmaals aandragen. Daarmee verdoe je niet alleen je eigen tijd maar ook de onze. Liever dat je verteld wat je al uitgesloten hebt (en hoe) zodat we daar onnodige tijd in investeren.

mookie schreef op donderdag 13 november 2014 @ 14:23:
Op DNS naam gaat praktisch net zo snel als met het IP adres.

Dit soort opmerkingen dus; ik snap wel wat je bedoelt, maar "praktisch net zo snel" is nogal afhankelijk van je (zoals ik eerder in deze post aangaf) perspectief. Het verschil tussen 0.0003s en 0.0004s is "maar" 0.0001s en dus "praktisch net zo snel". Enig idee hoe lang 0.0001s voor een CPU is? Dat is een f*ckin' eeuwigheid. En dan is 't dus opeens niet "praktisch net zo snel". (En het is een verschil van 25%, toch best aanzienlijk)

mookie schreef op donderdag 13 november 2014 @ 14:23:
Iedere verbinding is een nieuwe schone verbinding.

Nogmaals; ik ben niet heel erg bekend met PHP internals (laat staan de "windows build" ervan), maar ook hier mis ik onderbouwing (zijn MySQL/TCP/... - connection pool (-achtige) zaken (op PHP niveau, maar bijv. ook op MySQL driver niveau danwel "onderaan" op OS niveau e.d.) uitgesloten bijvoorbeeld?).

En over hoeveel samples hebben we 't eigenlijk? Zijn die metingen allemaal "eenmalig" (of in een lusje van 10? 100? 1.000.000?). En hoe zijn die bevindingen/,etingen dan geïnterpreteerd? Misschien is http://zedshaw.com/archiv...-or-i-will-kill-them-all/ wel eens 't lezen waard

[ Voor 47% gewijzigd door RobIII op 13-11-2014 15:00 ]

[mookie]

Nog 1001??? Dan ben ik nog lang bezig

Ten eerste wil ik even aangeven dat het erg lastig is om een goede openings post te maken waar mensen op reageren.
Maak je het een lang verhaal dan haken mensen af, maak je het een kort verhaal dan word er vaak gezegd dat je weinig onderzoek hebt gedaan en dergelijke.
Ik zelf heb ook het idee dat des te meer informatie ik geef, des te meer mensen ook in een bepaalde richting gaan denken.
Dit terwijl ik graag wil dat iedereen hier vers tegenaan kijkt zonder al vooraf beinvloed te worden door een overvloed aan informatie.

Laat ik voorop stellen dat ik al lang aan het testen ben (meerdere dagen) en vind dat ik nogal uitgebreid heb getest.
Door dat vele testen weet ik ook wat er precies sneller en wat er trager is geworden.
Daar komt dan uiteindelijk uit dat puur de verbinding opzetten met de mysql server (het inloggen) trager is geworden.

Alle testen zijn uiteraard meerdere malen uitgevoerd om zo tot gemiddeldes en min/max waardes te komen.
Alle testen zijn voor zover mogelijk met gelijke parameters gedaan, en waar telkens slechts 1 onderdeel veranderd en niet 2.

Hoe ik het ook wend of keer, eigenlijk komt er altijd hetzelfde uit naar voren.

Namelijk (zoals wel in de openings post vermeld): libmysql heeft zo'n 0,001 tot 0,002 (zie de dubbele 00 na de komma) nodig en mysqlnd heeft zo'n 0,002 tot 0,015 nodig.

Zoals je zelf ook al aangeeft, millisecondes zijn een eeuwigheid voor een processor.
Vandaar ook dat ik me afvraag wat er gebeurt en of ik er iets tegen kan doen.

Tevens zit libmysql bijna altijd onder de 0,002 en slechts een enkele keer net erboven maar nooit boven de 0,003
Mysqlnd daarintegen zit een enkele keer rond de 0,002 maar heel vaak rond de 0,015

Waarom gaat het soms wel in 0,002 seconden???
Ik kan er niets over vinden. Niets over hoe ik kan testen waar het aan ligt.

Dus:

Is die 0,015 sec een probleem dan? Is er een echt issue? waarom we hier überhaupt mee bezig zijn...
Het probleem is niet hoe lang het duurt, het probleem is dat ik niet weet waarom het zo lang duurt en daarmee de vraag of ik er iets aan kan doen.

Maar als je dan vervolgens die informatie achterwege laat...
Dat is een beetje mijn manier om mensen niet vooraf in een bepaalde richting te duwen.

Maar "praktisch net zo snel" is nogal afhankelijk...
Ik heb express geen getallen gegeven en "praktisch net zo snel" gezegd omdat als ik getallen ga geven mensen vaak de neiging hebben om af te dwalen.
Praktisch net zo snel betekent in dit geval dat er niets over te zeggen valt.
Als ik de test meerdere malen draai dan komt daaruit dat soms DNS naam sneller is dan rechstreeks met het IP adres.
Net nog een paar keer getest, en dan krijg ik min/max met DNS 0,01481/0,01545 en met IP adres 0,01494/0,01540

Omtrendt je linkje: hier ben ik wel mee bekend en heb dan ook een hekel aan algemene statistieken danwel halfbakken tests.
Ik heb daar naar mijn weten geen last vast.
Ik heb een test gemaakt die ontdaan is van allerlei opsmuk en alleen dat test wat ik wil.
Die test voer ik elke keer hetzelfde uit met slechts 1 gewijzigde parameter (enkel computer veranderen, enkel libmysql/mysqlnd veranderen, enkel PHP versie veranderen)
Na het meerdere malen uitvoeren komt daar gemiddeldes, min en max waardes uit.
Met name die min en max waardes zijn bijzonder.
Daaruit blijkt namelijk dat libmysql soms iets trager is, maar eigenlijk altijd snel.
En daaruit blijkt dat mysqlnd eigenlijk bijna altijd traag is, maar toch heel af en toe snel kan zijn.

Nog als laatste toe te voegen:
Ik heb met wireshark meerdere malen het netwerk verkeer vastgelegd.
Daaruit blijkt dat met libmysql het "login" pakketje vrij snel verstuurd wordt, terwijl bij mysqlnd daar een vertraging in zit.
(Tests zijn uiteraard meerdere malen uitgevoerd)

code:

LIBMYSQL:
No.     Time           Source                Destination           Protocol Length Info
     26 *REF*          172.22.6.1            172.22.1.120          TCP      62     5494 > mysql [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
     27 0.000086000    172.22.1.120          172.22.6.1            TCP      62     mysql > 5494 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
     28 0.000114000    172.22.6.1            172.22.1.120          TCP      54     5494 > mysql [ACK] Seq=1 Ack=1 Win=65535 Len=0
     29 0.000320000    172.22.1.120          172.22.6.1            MySQL    120    Server Greeting proto=10 version=5.1.30-community
     30 0.000372000    172.22.6.1            172.22.1.120          MySQL    128    Login Request user=myuser db=mydatabase
     31 0.000527000    172.22.1.120          172.22.6.1            MySQL    65     Response OK
     32 0.000627000    172.22.6.1            172.22.1.120          MySQL    59     Request Quit
     33 0.000656000    172.22.6.1            172.22.1.120          TCP      54     5494 > mysql [FIN, ACK] Seq=80 Ack=78 Win=65458 Len=0
     34 0.000704000    172.22.1.120          172.22.6.1            TCP      60     mysql > 5494 [FIN, ACK] Seq=78 Ack=80 Win=65456 Len=0
     35 0.000713000    172.22.6.1            172.22.1.120          TCP      54     5494 > mysql [ACK] Seq=81 Ack=79 Win=65458 Len=0
     36 0.000757000    172.22.1.120          172.22.6.1            TCP      60     mysql > 5494 [ACK] Seq=79 Ack=81 Win=65456 Len=0

code:

MYSQLND
No.     Time           Source                Destination           Protocol Length Info
     32 *REF*          172.22.6.1            172.22.1.120          TCP      62     enc-eps-mc-sec > mysql [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
     33 0.000086000    172.22.1.120          172.22.6.1            TCP      62     mysql > enc-eps-mc-sec [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
     34 0.000114000    172.22.6.1            172.22.1.120          TCP      54     enc-eps-mc-sec > mysql [ACK] Seq=1 Ack=1 Win=65535 Len=0
     35 0.000333000    172.22.1.120          172.22.6.1            MySQL    120    Server Greeting proto=10 version=5.1.30-community
     36 0.010536000    172.22.6.1            172.22.1.120          MySQL    128    Login Request user=myuser db=mydatabase
     37 0.010665000    172.22.1.120          172.22.6.1            MySQL    65     Response OK
     38 0.010830000    172.22.6.1            172.22.1.120          MySQL    59     Request Quit
     39 0.010886000    172.22.6.1            172.22.1.120          TCP      54     enc-eps-mc-sec > mysql [FIN, ACK] Seq=80 Ack=78 Win=65458 Len=0
     40 0.010910000    172.22.1.120          172.22.6.1            TCP      60     mysql > enc-eps-mc-sec [FIN, ACK] Seq=78 Ack=80 Win=65456 Len=0
     41 0.010920000    172.22.6.1            172.22.1.120          TCP      54     enc-eps-mc-sec > mysql [ACK] Seq=81 Ack=79 Win=65458 Len=0
     42 0.010952000    172.22.1.120          172.22.6.1            TCP      60     mysql > enc-eps-mc-sec [ACK] Seq=79 Ack=81 Win=65456 Len=0

Zo zie je bij libmysql dat (in deze voorbeelden) pakket 30 zo goed als onmiddelijk na de server greeting wordt verstuurd.
Bij mysqlnd zie je dat pakket 36 een vertraging heeft van 0,010203

Ik heb deze test meerdere malen gedaan en kwam heel vaak aan die 0,01 vertraging.
Maar soms niet, en dat vind ik vreemd... en ik zou het graag oplossen...

En, omdat het wellicht gewoon iets is in de windows versie van PHP, vraag ik me af of iemand het op een linux systeem zou kunnen testen...

[RobIII]

offtopic:
Zou je niet na elke zin op enter willen drukken?
Laat tekstomloop aan 't forum over a.u.b.
Het leest nogal vervelend.

mookie schreef op donderdag 13 november 2014 @ 16:45:
En, omdat het wellicht gewoon iets is in de windows versie van PHP, vraag ik me af of iemand het op een linux systeem zou kunnen testen...

Dat wil ik wel, maar dan had ik graag je code gezien wil ik een vergelijkbaar iets kunnen produceren

[Gomez12]

mookie schreef op donderdag 13 november 2014 @ 16:45:
Dus:

Is die 0,015 sec een probleem dan? Is er een echt issue? waarom we hier überhaupt mee bezig zijn...
Het probleem is niet hoe lang het duurt, het probleem is dat ik niet weet waarom het zo lang duurt en daarmee de vraag of ik er iets aan kan doen.

De belangrijkere vraag lijkt mij echter of er een probleem is...

Tot in details focussen is heel leuk, maar ook heel vaak compleet zinloos.
Wat is de totale tijd, dat lijkt me veel relevanter dan een kunstmatig deeltje wat wellicht niet boeiend is.

Wellicht dat een mysqlnd een stuk meer setup costs heeft maar dat de query-overdracht en de result-overdracht daardoor weer sneller is.
Als ik data over een socket moet gooien dan is die verbinding ook sneller geopend als ik hem zonder iets open dan wanneer ik bijv ga aankondigen dat ik met gzipped data ga komen, maar als ik in de praktijk door het gzippen tijd bespaar dan zijn de extra setup costs niet meer relevant.

Je geeft zelf al aan dat de query tijd in jouw metingen gelijk blijven, oftewel ik gok dat het gewoon iets meer startup costs vs sneller transport is.
En dat je je nu gewoon zit te focussen op iets wat totaal niet relevant is aangezien het in het huidige totaal niets uitmaakt en ik vermoed dat het bij een grotere query / resultaat in je voordeel gaat zijn.

[mookie]

De belangrijke vraag staat duidelijk in mijn openings post.

Het is naar mijn mening namelijk zowiezo nooit zinloos om op details te focussen of die proberen te begrijpen.

En wat dan als ik jou de totale pagina parse tijd vertel?
Gaan we dan discussieren over wat een acceptabele tijd is?

En wat dan nog? Wat als ik dat gewoon wil weten, zelfs indien er wel of geen probleem is?
Ik zit hier toch niet te posten omdat anderen mij dan misschien lekker interessant vinden?
Ik weet toch zeker zelf wel wat de vraag is?
Ik weet toch zeker zelf wel of ik pindakaas lekker vind of niet, ongeacht wat de rest van de aardse bevolking daarvan vind, ongeacht of je er langer door gaat leven, ongeacht allerlei andere niet relevante parameters?

Ik vind het gewoon vies en wil graag weten waarom en wil dan liever geen advies over waarom ik het misschien toch maar moet accepteren en gewoon moet eten.
In het beste geval kom je aanzetten met een ander product dat ik wel lekker vind en toch dezelfde eigenschappen heeft.

Ik heb "iets" gemaakt dat voornamelijk data ophaalt uit een database, veelal kleine resultsets, en daar vervolgens nog wat abracadabra mee doet in PHP alvorens het naar de browser te sturen.
Het grote voordeel van mysqlnd is dat het in de zend engine draait.
Daardoor kun je het geheugengebruik beter in de hand houden, en tevens heb je geen dubbel geheugen nodig omdat je stukken data zowel via de libmysql library gealloceerd hebt en zowel in zend gealloceerd hebt.
Ik heb daar echter helemaal geen voordeel aan omdat ik, zoals gezegd, zeer kleine resultsets heb. (dus onder de 100 regels met een maximale grootte van 35KB).

Helemaal aan het begin van de hoofdpagina neem ik de tijd op met microtime(true) en helemaal aan het einde doe ik dat nog eens om het verschil te berekenen en dat output ik dan als laatste nog even naar de browser.
Daarin viel mij op dat mijn pagina's die normaal zo rond de 0,006 tot 0,008 seconden laden, nu ineens in 0,03 tot 0,031 seconden laden.
(Ik include een stuk uit een andere website die ook verbinding met een mysql db maakt en op dezelfde server draait, dus krijg er meteen 2 x 0,015 seconden bovenop)

Dat ben ik gaan uitzoeken en heb allerlei onderdelen los gemeten en kwam er op uit het puur en alleen in het "connect" gedeelte van de mysqlnd driver zit.
Dit is dan ook het enige stukje dat trager is geworden, de rest is hetzelfde gebleven, ofwel verwaarloosbaar (dat is in mijn definitie, alles onder de 0,001 seconden meer of minder)

Ik vraag me dan ook af waarom de mysqlnd driver er langer over doet om het "login" pakketje te versturen, en al helemaal omdat hij dat soms in 0,002 seconden kan maar er meestal 0,015 seconden over doet.
En aangezien er wat minder mensen zijn die het op windows draaien vroeg ik mij af of het onder linux anders werkt.

Testcode:

code:

<?php
echo "mysql client version: ".mysql_get_client_info()."<br>\n";   
echo "software version: ".phpversion()."<br>\n";   

$time_delta = microtime(true);
$mysqli = new mysqli('127.0.0.1', 'jegebruiker', 'jewachtwoord', 'mysql');
$deltat=microtime(true) - $time_delta;
echo "$deltat";

$mysqli->close();
unset($mysqli);
?>

[RobIII]

mookie schreef op donderdag 13 november 2014 @ 21:17:
Het is naar mijn mening namelijk zowiezo nooit zinloos om op details te focussen of die proberen te begrijpen.

En wat dan nog? Wat als ik dat gewoon wil weten, zelfs indien er wel of geen probleem is?

Ik vind het gewoon vies en wil graag weten waarom en wil dan liever geen advies over waarom ik het misschien toch maar moet accepteren en gewoon moet eten.

Jee, even rustig aan zeg...
Weet je, als je 't precies wil weten, en dat wil je klaarblijkelijk; wat let je dan om 't gewoon zelf tot op de bodem uit te zoeken? Kun je lekker helemaal tot op 't bot uitzoeken wat A wél doet en B niet doet waardoor er zo'n enorm verschil in zit. Wanna see how deep the rabbithole goes?
Nogmaals: wat boeit het? A is snel, B niet. Wil je snel dan gebruik je A. Wil je beter/uitgebreider/veiliger/whatever dan gebruik je B. Je maakt gewoon je afweging / tradeoffs en kiest daarna iets en ... move on.

Dat je niet te horen krijgt wat je graag wil horen wil niet zeggen dat niemand je hier probeert te helpen. We investeren allemaal tijd in het lezen van je relaas en investeren ook nog eens tijd om te reageren. Wees blij dat je iemand hebt om eens mee te klankborden i.p.v. jezelf brullend armen zwaaiend op de vloer te gooien.

mookie schreef op donderdag 13 november 2014 @ 21:17:
Testcode:

...dat is A. Waar is B?
Daarbij beweerde je eerder nog heel anders/uitgebreider/beter getest te hebben dan een enkele meting. Deze "test" lijkt werkelijk nergens op (of: waarom toon je deze code en niet je échte code waarmee je de meting gedaan hebt?). En als je de test X (100, 1000, whatever) keren gedraaid hebt dan mag ik hopen dat je dat in een lus (for/while/...) hebt gedaan en niet door X keer die PHP aan te roepen (waardoor je telkens een nieuwe/schone omgeving hebt per executie i.t.t. die code in een lus uit te voeren). En ik mis daarbij dus ook bijvoorbeeld een "warmup" (of ramp-up) ronde(s) die je niet laat meetellen. En al datzelfde geldt voor B ook uiteraard.

mookie schreef op donderdag 13 november 2014 @ 21:17:
Het grote voordeel van mysqlnd is dat het in de zend engine draait.
Daardoor kun je het geheugengebruik beter in de hand houden, en tevens heb je geen dubbel geheugen nodig omdat je stukken data zowel via de libmysql library gealloceerd hebt en zowel in zend gealloceerd hebt.

Nou; daar heb je al een wezenlijk verschil. En misschien betaal je bij A dus (initieel) wat 'administratiekosten' (setup/initialize/younameit voor, o.a., malloc's maar bijv. ook andere (interne) structuren en dingen zoals, nogmaals bijvoorbeeld, (interne) connection pools opzetten etc.) tijdens een connect() die je bij B mogelijk niet betaalt. Who. Cares. A doet wat 'ie moet doen en B doet ook wat 'ie moet doen. Tenzij je in de sourcecode van PHP gaat rommelen en de zooi zelf gaat compileren zul je er genoegen mee moeten nemen dat het gewoon is wat het is. Je kunt, los van voorgenoemde, niet even "je arm in A/B steken" en daarmee de internals overtuigen sneller hun werk te doen. Beide A en B zijn, vanuit jouw oogpunt, gewoon een black box. Het enige dat mogelijk iets uitmaakt is de environment om A en B optimaliseren zodat A en/of B beter aansluiten / minder werk hebben o.i.d. maar dat is, tenzij je de source in duikt, voornamelijk gezond verstand en daarna gewoon koffiedik kijken.

Maar goed; jij je zin. Ik heb je code ge-copy/pasted en uitgevoerd op een Linux bak. Uitkomst?

mysql client version: 5.5.40

software version: 5.5.18-1~dotdeb.1

0.111226797104

Happy?

Hee; als ik 't nog een keer doe krijg ik:

mysql client version: 5.5.40

software version: 5.5.18-1~dotdeb.1

0.000828981399536

No shit sherlock De eerste keer was m'n VM nog aan 't wakker worden, de tweede keer was de VM wakker, Apache warm, MySQL warm, etc. etc.

En dit krijg ik in een lus van 1000 x:

mysql client version: 5.5.40

software version: 5.5.18-1~dotdeb.1

0.000593900680542
0.000843048095703
0.000385999679565
0.000229120254517
0.000209093093872
0.000210046768188
0.000207901000977
0.000188827514648
0.000291109085083
...
0.000336885452271
0.000256061553955
0.000225067138672
9.20295715332E-5
0.000283002853394
0.000322818756104
0.000226020812988
0.000202894210815
0.000453948974609
0.000344038009644
0.000319957733154
0.000277042388916
0.000576019287109
0.00761389732361
0.00221610069275
0.00022292137146
0.00596714019775
0.00043511390686
0.000306129455566
0.0002760887146
0.000309944152832
0.000264883041382
0.00105595588684
0
0.00648593902588

En dat ziet er zo uit:


Los van het, eerder aangehaalde, Programmers Need To Learn Statistics zie je dat de tijden hier ook wild uiteen lopen. Soms heb je de GC die even binnen komt fietsen om z'n werk te doen, soms heb je een TCP pakketje dat opnieuw verzonden moet worden, soms heb je een MySQL die nog even bezig is met 100 oude connecties op te ruimen om plek te maken voor nieuwe, soms betaal je weer voor een OS dat je nét wat langer "weg-scheduled" dan de iteratie ervoor, soms moet PHP even de output buffer flushen etc. etc. Hence de "uitschieters" in bovenstaand grafiekje.

Wat ben je nu wijzer geworden? Niet veel volgens mij (los van dat ik geen code van B heb om voor je te draaien om die resultaten voor jezelf met mijn A resultaten te vergelijken...)

Tot slot herhaal ik mezelf nog een keer:

RobIII schreef op donderdag 13 november 2014 @ 16:49:

offtopic:
Zou je niet na elke zin op enter willen drukken?
Laat tekstomloop aan 't forum over a.u.b.
Het leest nogal vervelend.

[ Voor 82% gewijzigd door RobIII op 13-11-2014 22:20 ]

[Cartman!]

Puur op gevoel zeg ik dat A veel sneller is dan B omdat ie zo "dom" is. Druk maken om parsetijden is heel normaal maar in de meeste gevallen kun je enorme winst op heel andere plekken halen, probeer te cachen of zet er een reverse proxy voor. Als ruwe snelheid en lage latencies echt belangrijk is dan denk ik dat PHP niet het geschikte platform is maar kun je beter kijken naar bijvoorbeeld NodeJS of Go.

[mookie]

ok, sorry voor die reactie maar het is nogal frustrerend om telkens te worden aangepraat dat het wellicht maar zo is en dat ik dan verderop wel ergens een voordeeltje zal behalen wat in mijn specifieke geval helemaal niet is of ik in ieder geval niet kan ontdekken omdat die voordelen nergens bechreven staan.
De testcase zoals ik hem neerzet is namelijk helemaal zoals het in mijn geval gaat.

- Het wordt in mijn pagina nergens in een lus meerdere malen herhaalt
- Gewoon op F5 drukken ipv een lus, zo gaat het in de werkelijkheid
- Het enige wat er gebeurt is dat er 2 of 3 keer verbinding wordt gemaakt en verbroken met de database, zoals ik in eerste instantie ook in mijn testscript had staan, al blijkt daar geen voordeel uit te halen zoals een warme start waarbij er nog een oude verbinding wordt hergebruikt, daarom heb ik dat in dit script eruit gehaald.

Dus, nogmaals excuus maar het voelt voor mij nogal zoals in het pindakaas voorbeeldje.

Had tevens je comment over enters niet gelezen, ik zal erop letten. Het is overigens grammatisch gezien prima om een entertje te geven na een punt, voor mij een nogal natuurlijk gevoel en gaat automatisch, maar het leest inderdaad prettiger om dat niet te doen.

Goede tip, die link naar de source code, had er al niet eens meer aan gedacht dat het opensource is en dat ik daar wellicht iets in vind. ik zie dat van libmysql ook gewoon de source code beschikbaar is, wellicht dat ik daar mijn magische antwoord in vind.

Over het testscript: de A en B zit in de library waarmee de mysqli library is gelinked/gecompiled. Je draait het script in een PHP versie waarbij de mysqli API is gelinked met de mysqlnd driver/library of je draait het script in een PHP versie waarbij de mysqli API is gelinked met de libmysql driver/library.

Daarom is het ook weinig keuze voor mij. De laatste windows PHP versies zijn gewoon gecompiled met mysqlnd, en ik kan nergens een versie vinden die is gecompiled met libmysql, denk ook niet dat ik het zelf kan en weet niet eens wat ik dan allemaal voor moois mis.

In mijn geval draai ik het script dus met PHP 5.2.17 waarin libmysql wordt gebruikt en ik draai het in PHP 3.x 5.x en 6.x waarin mysqlnd wordt gebruikt.
Dit lijkt ook het enige verschil te maken.
Of je de mysql_* of de mysqli_* API gebruikt maakt geen verschil, en of je apache 2.2 of 2.4 gebruikt maakt geen verschil, en of je windows XP, 2003, 2012 of windows 7 gebruikt 32bit of 64bit maakt geen verschil.

Nogmaals, het gaat niet om de snelheid maar om het waarom. En zodra ik weet waarom, dan is het ook makkelijker om het te accepteren. Want misschien heeft het wel andere voordelen... hetgene ik nu nog niet kan zeggen want het enige voordeel wat telkens genoemd wordt is het betere geheugen management en dat is in mijn geval specifieke geval op dit moment niet relevant.

Je kunt het script overigens ook gewoon via de command line draaien. Ik heb het meerdere malen getest en de resultaten zijn bij mij hetzelfde als wanneer ik het via apache draai. Dus als iemand in de gelegenheid is om het op een linux omgeving te draaien en mij de uitkomst kan meededelen dan graag.

Ik zie net dat je het hebt uitgevoerd, dank daarvoor. Het script zegt "mysql client version: 5.5.40". Dat betekent dat je mysqli API in je PHP is gelinked met de libmysql library. Anders zou er namelijk mysqlnd in de naam van de client staan. Tevens is de laatste mysqlnd driver versie 5.0.11
(Nu mis jij dus al die mooie nieuwe memory management features )

Ben je toevallig in de gelegenheid om het te testen op een PHP installatie die met mysqlnd is gelinked/gecompiled?

[RobIII]

mookie schreef op donderdag 13 november 2014 @ 22:17:
Ik zie net dat je het hebt uitgevoerd, dank daarvoor. Het script zegt "mysql client version: 5.5.40". Dat betekent dat je mysqli API in je PHP is gelinked met de libmysql library. Anders zou er namelijk mysqlnd in de naam van de client staan. Tevens is de laatste mysqlnd driver versie 5.0.11
(Nu mis jij dus al die mooie nieuwe memory management features )

Ok; even pauze. Ik was in de veronderstelling dat de één (bij wijze van) MySQLi was en de ander MySQLnd en dus de één iets zou doen als in je gegeven script en de ander weer "op zijn eigen manier" zou doen (zoals MySQL dat doet of PDO ofzo). Daarom vroeg ik ook naar "het andere script" voor "B". Maar ik begrijp hieruit dus dat je voor beiden 'tzelfde script gebruikt maar dat 't MySQLi/MySQLnd verhaal dus afhankelijk is van de onderliggende driver / waarmee PHP gecompiled/gelinked/whatever is en 't script dus voor A en B hetzelfde is? Want ik heb werkelijk geen idee hoe ik die andere methode dan zou kunnen testen (lees: hoe ik A door B vervang). Maar als 't op dat soort dingen aankomt ben ik echt een n00b (en is PHP echt een puinhoop IMHO).
Dus voor mijn idee: je gebruikt in allebei de gevallen MySQLi (en dus dezelfde code) maar de onderliggende "driver" verschilt bij A en B? Of hebben we 't nu over "MySQLi v.s. MySQL-achtigs" (waarbij die laatste dan niet de deprecated MySQL is maar de "nd"-versie ofzo).

Neemt niet weg dat de strekking van 't verhaal 'tzelfde blijft IMHO

mookie schreef op donderdag 13 november 2014 @ 22:17:
Ben je toevallig in de gelegenheid om het te testen op een PHP installatie die met mysqlnd is gelinked/gecompiled?

Als ik zou weten hoe? Ik kom niet heel veel verder dan apt-get install <somepackage>

[ Voor 20% gewijzigd door RobIII op 13-11-2014 22:38 ]

[mookie]

Zoals je hierboven inderdaad zegt. Ik heb helemaal niets aan mijn code veranderd, ik heb enkel een nieuwe versie van PHP gebruikt. En die versie (voor windows) wordt standaard gecompiled met mysqlnd. hierzo zie je dat je tijdens compile time kunt kiezen, maar ik kan dat dus niet. Anders had ik wel even de "windows PHP versie die met libmysql is gecompiled" gedownload en gebruikt.

Maar jij lijkt nogal handig met linux en ook een beetje met PHP. Dus misschien snap jij wat er op die pagina staat en kun je PHP het even opnieuwe compilen of gewoon een andere package (heet dat zo in linux?) installeren... ofzoiets...

In het kort bevat PHP vele "extensies" wat hun benaming voor een API is. Om te praten met Mysql heb je de mysql_* functies, de mysqli_* functies, PDO en ODBC. Deze API's gebruiken echter altijd een externe library. Dit is oftewel LIBMYSQL (originele C library vanuit mysql AB destijds, nu vanuit Oracle) of je gebruikt MYSQLND hetgeen speciaal voor PHP is ontwikkeld.
PHP (voor windows) 5.2 is met libmysql gecompiled, PHP (voor windows) 5.3 en hoger is met mysqlnd gecompiled. Daarom gebruik ik verschillende PHP versies, maar eigenlijk gaat het enkel om de library die is gebruikt tijdens het compilen.

Daarom merk ik ook geen verschil met mysql_* functies of met mysqli_* functies qua tijd. Er onstaat enkel een verschil als je een andere library gebruikt waar ik in mijn (windows) geval geen keuze over heb.

[ Voor 37% gewijzigd door mookie op 13-11-2014 22:41 ]

[RobIII]

mookie schreef op donderdag 13 november 2014 @ 22:35:
Zoals je hierboven inderdaad zegt. Ik heb helemaal niets aan mijn code veranderd, ik heb enkel een nieuwe versie van PHP gebruikt.

Heb je 't hier nou over iets als 5.2 v.s. 5.3? Of over iets als 5.3 met driver X en 5.3 met driver Y gecompiled/linked/whathaveyou? Want 't eerste is natuurlijk sowieso appels en peren.

mookie schreef op donderdag 13 november 2014 @ 22:35:
Maar jij lijkt nogal handig met linux en ook een beetje met PHP. Dus misschien snap jij wat er op die pagina staat en kun je PHP het even opnieuwe compilen of gewoon een andere package (heet dat zo in linux?) installeren... ofzoiets...

Check even mijn edit van mijn vorige post

mookie schreef op donderdag 13 november 2014 @ 22:35:
Daarom merk ik ook geen verschil met mysql_* functies of met mysqli_* functies qua tijd. Er onstaat enkel een verschil als je een andere library gebruikt waar ik in mijn (windows) geval geen keuze over heb.

Mja, het wordt nu een beetje "de lamme leidt de blinde" vrees ik, maar je zegt zelf al geen keuze te hebben. En als het inderdaad "driver X" v.s. "driver Y" is dan speelt er nog steeds hetzelfde verhaal dat ik steeds aanhaal; ze hebben allebei hun internals en dus doen allebei iets anders en 't is dus ook heel goed verklaarbaar is waarom X sneller is dan Y (of andersom). Maar het is dan ook gewoon wat 't is; daar doe je bar weinig aan want die internals zijn en blijven internals. En je hebt geen keus... (volgens eigen zeggen)

[ Voor 73% gewijzigd door RobIII op 13-11-2014 22:44 ]

[Gomez12]

mookie schreef op donderdag 13 november 2014 @ 22:17:
ok, sorry voor die reactie maar het is nogal frustrerend om telkens te worden aangepraat dat het wellicht maar zo is en dat ik dan verderop wel ergens een voordeeltje zal behalen wat in mijn specifieke geval helemaal niet is of ik in ieder geval niet kan ontdekken omdat die voordelen nergens bechreven staan.

Of ik snap even iets niet, of je moet het voordeel toch wel ergens zien.
Je zegt een verschil in connectie tijd te zien, maar geen verschil in query tijd.

En schijnbaar meet je die op verschillende manieren (connectie tijd met wireshark, query tijd met php microtime) oftewel in je php microtime zit je connectie tijd toch verstopt?

Maar ik begrijp nu ook dat je het over 2 verschillende library's hebt (dat was me niet even duidelijk) dan wordt het helemaal een black box op windows.
Dan kunnen er ook nog dingen meetellen als hoe de library gecompileerd is (met debug info of niet, met extra optimalisaties of niet, met wellicht een andere compiler, wellicht met 64-bit uit etc etc)

En daarnaast benoem je zelf al een rits verschillen die voor tijdsverschillen zullen zorgen (simplistisch gezegd zal elke letter verandering in source zorgen voor een tijdsverschil, of dat over het totaal positief of negatief is valt niet te zeggen, maar dat er een tijdsverschil is is bijna zeker)

En dan heb je nog dat er vanwege het feit dat het een andere library is dat er andere keuzes gemaakt kunnen zijn (bijv bij die mysql_client_info kan er vroeger gekozen zijn om wat extra dingen in te laden zodat die al lekker in de cache zaten die bij de nieuwe niet meer in de cache staan).

Daarnaast heb je nog dat met een andere library bijv je on-access virusscanner wellicht net iets meer moeite heeft om de hash te berekenen.

Het is allemaal net niks op zichzelf, maar tel er 3 of 4 bij elkaar op en wellicht dat daar je factor 10 inzit. Wellicht dat het er ook maar 1 is, en dan heb je daarbovenop nog de eerder genoemde algemene dingen.

Waar RobIII eerder bij dezelfde library al zei dat er 1001 dingen speelden, bij 2 verschillende library's met grofweg dezelfde versie ga je richting de 1 miljoen en 1, bij 2 library's met totaal verschillende doelstellingen / versies / sources (waar we het hier over hebben getuige jouw eerder genoemde lijstje van voordelen van ga je weer naar een veelvoud daarvan

Goede tip, die link naar de source code, had er al niet eens meer aan gedacht dat het opensource is en dat ik daar wellicht iets in vind. ik zie dat van libmysql ook gewoon de source code beschikbaar is, wellicht dat ik daar mijn magische antwoord in vind.

Compile eerst de source maar eens met exact dezelfde compiler en exact dezelfde settings, zeer waarschijnlijk is dat slechts een fractie van jouw tijdsprobleem, maar het is wel supersimpel te testen.
Zeer waarschijnlijk zit het grootste gedeelte van je vraag gewoon in de source, in de delen die je eerder al zelf noemt.
Bijv. minder geheugen gebruik betekent over het algemeen vaker flushen en flushen kost simpelweg ook tijd

Daarnaast zullen er nog andere dingen veranderd zijn die meer tijd kosten, en daarnaast zullen er dingen geoptimaliseerd zijn die minder tijd kosten.

Je krijgt niet een betere integratie met Zend zonder dat er ergens minimaal een check extra moet komen (of Zend er uberhaupt is) en die check kost al tijd, die tijd kan je grofweg weer terugwinnen door optimalisaties in je source. Maar de netto som gaat nooit 0 zijn op het niveau waar jij het bekijkt.

Oftewel ik vermoed dat er simpelweg vanwege de extra functionaliteiten er tijdverlies is (extra functionaliteiten zijn niet gratis qua tijd) maar dit valt heel erg moeilijk te kwantificeren omdat er ergens anders weer tijdswinst is door optimalisaties.
En dan praat ik enkel nog over de mysql-library, jij hebt het ook nog eens over een andere php-versie erbovenop. Wellicht dat je 100 ms verliest enkel in de mysql-library op de nieuwe functionaliteit, maar win je 49 msec in de mysql-library vanwege optimalisaties en 49 msec in de php-versies, waardoor het netto verlies is 2 msec.

In het heel kort gezegd : Andere binary levert andere tijd op. Wil je dat verschil achterhalen binnen een combinatie van 2 binary's (php en mysql) met andere functionaliteiten dan ga je bijna praten over per source-regel (waarbij je dus alle regels pakt) profilen en daar wens ik je veel succes mee als de regels simpelweg verschillend zijn.

In mijn geval draai ik het script dus met PHP 5.2.17 waarin libmysql wordt gebruikt en ik draai het in PHP 3.x 5.x en 6.x waarin mysqlnd wordt gebruikt.
Dit lijkt ook het enige verschil te maken.
Of je de mysql_* of de mysqli_* API gebruikt maakt geen verschil, en of je apache 2.2 of 2.4 gebruikt maakt geen verschil, en of je windows XP, 2003, 2012 of windows 7 gebruikt 32bit of 64bit maakt geen verschil.

Harde conclusie : Je test verkeerd. Al je verschillende versies maken tijdsverschil. Wellicht niet in de orde van grootte die jij zoekt, maar ze maken tijdsverschil want ze zijn simpelweg verschillend.

Nogmaals, het gaat niet om de snelheid maar om het waarom. En zodra ik weet waarom, dan is het ook makkelijker om het te accepteren. Want misschien heeft het wel andere voordelen... hetgene ik nu nog niet kan zeggen want het enige voordeel wat telkens genoemd wordt is het betere geheugen management en dat is in mijn geval specifieke geval op dit moment niet relevant.

Wat denk je dat er gebeurt met "beter" geheugenmanagement? Over het algemeen betekent het gewoon meer checks en balances in de source, waardoor op sommige gebieden het geheugen beter uitgelijnd wordt (/sneller) en het eerder vrijgegeven kan worden en op andere gebieden pakt het net even verkeerd uit en gaat het langzamer.

Ik zie net dat je het hebt uitgevoerd, dank daarvoor. Het script zegt "mysql client version: 5.5.40". Dat betekent dat je mysqli API in je PHP is gelinked met de libmysql library. Anders zou er namelijk mysqlnd in de naam van de client staan. Tevens is de laatste mysqlnd driver versie 5.0.11
(Nu mis jij dus al die mooie nieuwe memory management features )

Gewoon even ter beeldvorming, die 2 extra letters op het scherm zetten is al een tijdsverschil.Het zit niet op het niveau wat jij zoekt, maar een paar 1000x dat soort extra dingen in interne dingen en wellicht dat je wel in de buurt komt.

Ook als ik in je wireshark kijk dan zie ik bijv ook 2 verschillende poorten om op te connecten, die enc-eps-mc-sec als ik die heel snel door google gooi dan is die secure transport, wellicht dat die opnieuw geinitialiseerd wordt bij een connect wat ook weer tijd kost om te initialiseren.

In wezen als ik een lijstje zou moeten maken van eerst onderzoeken naar later onderzoeken :
- Source code (is wel het moeilijkste en meeste werk maar het meest waarschijnlijke omdat simpelweg de features anders zijn)
- Compiler (is zo ongeveer het makkelijkste)
- Load op allebei de momenten
- Netwerk stack om te zien of het wel / niet opnieuw initialiseren bij een connect nog van invloed is (maar dit zou mogelijk ook vanuit source code geinitieerd worden en niet direct vanuit netwerk stack)
En dan beland je in een shitzooi omdat je dan gaat praten over combinaties van allerlei dingen die op zichzelf allemaal onder je threshold blijven maar als er vanwege een oostenwind net bij de nieuwe versie 1000 van die achter elkaar vallen ze toch je over de threshold heenbrengen

[Elijan9]

Misschien ben ik in de war, maar LibMySQL werkt compleet zonder client/server, toch? Dat wil zeggen, de library leest/schrijft direct naar de databasefiles, zonder dat er een echte daemon nodig is, alles vindt plaats binnen één en dezelfde applicatie? Uiteraard gaat dat tot enkele millisecondes sneller: er hoeft geen server te draaien, er hoeft geen verbinding te worden opgebouwd tussen client en server (dit wordt gesimuleerd), enzovoort. Het grote nadeel is alleen wel dat er ook maar één instantie kan lezen/schrijven naar de onderliggende database files en ook niets bij geschaald kan worden... Wat dat betreft lijkt LibMySQL nog het meest op SQLite qua beperkingen.

.Edit: Laat maar, ik was in de war met libmysqld.

[ Voor 5% gewijzigd door Elijan9 op 14-11-2014 13:05 ]