DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
De connection overhead is er nauwelijks, het is een non-optimalisatie. En wat gebeurt er als je in een script een lock zet in een transactie en dat script stopt er midden in een transactie mee door een fout, en een ander script gaat met die connectie verder?
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Wat is eigenlijk een grote voordeel van mysqli ten opzichte van mysql? Of waarom zou ik mysql niet meer gebruiken maar daarvoor in de plaats mysqli (behalve omdat mysql uitgefaseerd wordt)?
"You know what Hell really is? It's not lakes of burning oil or chains of ice. It's being removed from God's sight."
Je kunt met mysqli gebruik maken van nieuwere features in MySQL zoals transacties en prepared statements.quote:Op zondag 28 oktober 2012 14:24 schreef Devolution het volgende:
Wat is eigenlijk een grote voordeel van mysqli ten opzichte van mysql? Of waarom zou ik mysql niet meer gebruiken maar daarvoor in de plaats mysqli (behalve omdat mysql uitgefaseerd wordt)?
Er vinden geen transacties plaats. Het was mij alleen om de eventuele overhead te doen. Maar aangezien die er niet of nauwelijks is, is er geen reden meer om een verbinding open te houden. In ASP.NET was het overigens vrij makkelijk op te lossen. Daar doe je, indien er fouten optreden gewoon een rollback op de transactie en geef je alles weer vrij. Ik neem aan dat dit in PHP ook wel mogelijk is.quote:Op zondag 28 oktober 2012 10:45 schreef GlowMouse het volgende:
De connection overhead is er nauwelijks, het is een non-optimalisatie. En wat gebeurt er als je in een script een lock zet in een transactie en dat script stopt er midden in een transactie mee door een fout, en een ander script gaat met die connectie verder?
Met PDO of mysqli kan dat, maar met de oude mysql_ functies kun je überhaupt geen transacties doen, dus ook geen rollback.quote:
[..]
Daar doe je, indien er fouten optreden gewoon een rollback op de transactie en geef je alles weer vrij. Ik neem aan dat dit in PHP ook wel mogelijk is.
Maar qua veiligheid is er geen verbetering?quote:Op zondag 28 oktober 2012 14:36 schreef Tijn het volgende:
[..]
Je kunt met mysqli gebruik maken van nieuwere features in MySQL zoals transacties en prepared statements.
Is dat bij mysqli niet meer nodig dan?quote:
"You know what Hell really is? It's not lakes of burning oil or chains of ice. It's being removed from God's sight."
Nou, je zou kunnen zeggen dat de mogelijkheid om mislukte queries te rollbacken in een transactie of het automatisch escapen van variabelen in prepared statements wel een impact hebben op de security. Het is natuurlijk nog steeds mogelijk om onveilige code te schrijven, net zoals het mogelijk is om met de oude mysql-functies veilige code te schrijven, maar je hoeft je met mysqli en PDO misschien in wat minder bochten te wringen om het goed te doen.quote:
[..]
Maar qua veiligheid is er geen verbetering?
Niet als je prepared statements gebruikt en je variabelen via bindParam() in je query laat plaatsen, dan gebeurt dat automatisch.quote:Is dat bij mysqli niet meer nodig dan?
dat kan wel, mysql_query("START TRANSACTION")quote:
[..]
Met PDO of mysqli kan dat, maar met de oude mysql_ functies kun je überhaupt geen transacties doen, dus ook geen rollback.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Handmatig kan je inderdaad van alles. Maar er zijn geen ingebouwde functies voor. Volgens de documentatie wordt het ook niet aangeraden om van nieuwe features op deze manier gebruik te maken.quote:
[..]
dat kan wel, mysql_query("START TRANSACTION")
transacties zijn geen nieuwe features
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ah, inderdaad, dat werd door Innodb gebracht. Maar dan nog wordt volgens de documentatie het sterk afgeraden om MySQL 4.1.3 of later te gebruiken in combinatie met de oude mysql_ functies. Dat is een dusdanig oude versie van MySQL (uit 2004 ofzo?) dat het praktisch voor elke situatie nu niet verstandig is om ermee aan de slag te gaan voor een nieuw project.quote:
transacties zijn geen nieuwe features
Oke, bedankt voor de info. Misschien toch maar eens overschakelen dan 
"You know what Hell really is? It's not lakes of burning oil or chains of ice. It's being removed from God's sight."
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | <?php private function getFileName($digit_number){ $new_file_name = ""; for($i = 0; $i < $digit_number; $i++){ $flag = rand(0,2); switch($flag){ case 0:{ $new_file_name .= chr(rand(48,57)); break; } case 1:{ $new_file_name .= chr(rand(65,90)); break; } case 2:{ $new_file_name .= chr(rand(97,122)); break; } } } return $new_file_name; } ?> |
Code evalueren van anderen, is niet goed voor mijn bloeddruk.
Carpe Libertatem
Ik zou persoonlijk voor PDO gaan, dan heb je gelijk een databaseonafhankelijke abstractielaag.quote:Op maandag 29 oktober 2012 17:47 schreef Devolution het volgende:
Oke, bedankt voor de info. Misschien toch maar eens overschakelen dan
Efficiënte manier om random strings te genereren.quote:Op donderdag 1 november 2012 08:57 schreef Boze_Appel het volgende:
[ code verwijderd ]
Code evalueren van anderen, is niet goed voor mijn bloeddruk.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
quote:Op donderdag 1 november 2012 09:05 schreef mstx het volgende:
[..]
Efficiënte manier om random strings te genereren.
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
quote:
[ code verwijderd ]
Code evalueren van anderen, is niet goed voor mijn bloeddruk.
Je kunt je code natuurlijk ook gewoon voor jezelf houden ik heb anders nog nooit WTF gehoord 
ik heb anders nog nooit WTF gehoord
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Van die code zie je in 10 seconden wat er gebeurt.quote:
[ code verwijderd ]
Code evalueren van anderen, is niet goed voor mijn bloeddruk.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ik zie een verband.quote:
Je kunt je code natuurlijk ook gewoon voor jezelf houden
Kan iemand mij vertellen hoe ik een database met meer dan 10.000 entries kan laten werken met XAMMP? Ik heb de filesize limit al verhoogd in php.ini.
Het probleem is al opgelost. Ik heb de database geleegd en de auto_increment teller gereset. Toen heb ik alles opnieuw naar de database weg laten schrijven en met Chrome ingelogd op MyPhpAdmin. Met Firefox liep de boel dus vast en gaf 'ie een foutmelding dat ik aan de sizelimit zat.quote:
Wat werkt er niet meer (krijg je een error?) en welke database gebruik je?
Wat is de juiste manier om URL's met CodeIgniter te rewriten in htaccess, zonder dat het pad naar m'n CSS-file wordt gerewrite waardoor m'n CSS-file niet correct geladen wordt?
Je kan css bestanden excluden van de mod_rewrite
It was an opportunity to honour our memories and to make room for new ones
Iemand een idee hoe je dit kunt debuggen? Als er nou een query bij zou staan zou het makkelijk zijn. Ik zie ook niks terug in de slow query log.
Ik gebruik ook nooit persistente connecties ofzo.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
De gebruikersnaam 'apache' vind ik raar, gebruik je sql logging voor Apache?
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Oh die gebruiker had ik schijnbaar ook voor mijn applicatie (best slecht). 
Maarja, met een andere user het zelfde probleem, de apache user doet nu niks meer.
Misschien zit er ook wel gewoon iets fout in mijn mysql/apache/php/apc configuratie, maarja, hoe vind je uit wat de oorzaak en wat het gevolg is.
[ Bericht 17% gewijzigd door mstx op 05-11-2012 12:41:14 ]
Maarja, met een andere user het zelfde probleem, de apache user doet nu niks meer.
Misschien zit er ook wel gewoon iets fout in mijn mysql/apache/php/apc configuratie, maarja, hoe vind je uit wat de oorzaak en wat het gevolg is.
[ Bericht 17% gewijzigd door mstx op 05-11-2012 12:41:14 ]
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Ik zou toch eens zoeken naar persistent connections. Juist als je die maar op een enkele pagina gebruikt, heb je grote idle times bij je connections zoals je nu ziet.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
"Sleep" betekent dat de connectie idle is... gewoon een connectie die open blijft staan nadat de query is afgehandeld. Dat hoeft dus helemaal geen probleem te zijn, tenzij de connecties niet goed hergebruikt worden en je op den duur tegen de max_connections limiet aanloopt.
Mja het rare is dus dat er op de hele server geen persistent connection wordt gemaakt (tenzij mysqli dit zelf doet zonder dat ik het aangeef). Ik doe zelfs aan het eind van het script voor de zekerheid nog een close().
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Dat blijkt nu het geval te zijn: Warning: mysqli::mysqli(): (08004/1040): Too many connectionsquote:
tenzij de connecties niet goed hergebruikt worden en je op den duur tegen de max_connections limiet aanloopt.
Alles in de process list zit nu te slapen.
Apache doet nu ook niet veel meer, de meeste connecties blijven op "sending reply" staan
Restart Time: Monday, 05-Nov-2012 13:07:20 CET
Parent Server Generation: 0
Server uptime: 18 minutes 32 seconds
Total accesses: 7409 - Total Traffic: 8.8 MB
CPU Usage: u1070.9 s58.36 cu0 cs0 - 102% CPU load
6.66 requests/sec - 8.1 kB/second - 1247 B/request
188 requests currently being processed, 18 idle workers
WRKCWWWWRWWWWWW.WWWWWWW.WRWWWWCWWW_WW._.K_W.WWW.WRW.WWWW.W_WWWKW
_WWWWWK.WWWWWWWR._WK..WWWWWW.WWWWWW.WWWWWWW_WWWW..WKWWWCWW.W..WK
WWW.WWWWWW..WWWWW._WWWWWW.W.W_WWK.WWKRWWRWWW.WWWWWW.WW.WWW__WWWW
WW.WWW_W..WWW._.WWWWWWWWWK__WW..WW.W._WW.W.KW_.WW.W.WW_W.W......
[ Bericht 19% gewijzigd door mstx op 05-11-2012 13:27:06 ]
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Probeer eens mysql.allow_persistent=Off en mysqli.allow_persistent=Off
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Heb het erin gezet (en mysql opnieuw gestart), maakt geen verschil. Ik krijg na 2 minuten alweer "too many connections".quote:Op maandag 5 november 2012 13:26 schreef GlowMouse het volgende:
Probeer eens mysql.allow_persistent=Off en mysqli.allow_persistent=Off
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Kijk dan eens in apache's server-status of er clients verbonden blijven.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ja bijna allemaalquote:
Kijk dan eens in apache's server-status of er clients verbonden blijven.
Restart Time: Monday, 05-Nov-2012 13:07:20 CET
Parent Server Generation: 0
Server uptime: 30 minutes 42 seconds
Total accesses: 10271 - Total Traffic: 12.9 MB
CPU Usage: u1568.03 s77.94 cu0 cs0 - 89.4% CPU load
5.58 requests/sec - 7.2 kB/second - 1314 B/request
250 requests currently being processed, 0 idle workers
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWKWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWCWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW......
Na het restarten zie je alles langzaam in een W'tje veranderen totdat de max_connections van mysql bereikt is.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Dat is dan een groot probleem want elke W kost veel geheugen van Apache ook nog eens. Je kunt met extended server status nog preciezer zien wat elke W betekent.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ik heb het nu zo:quote:
Wat is de juiste manier om URL's met CodeIgniter te rewriten in htaccess, zonder dat het pad naar m'n CSS-file wordt gerewrite waardoor m'n CSS-file niet correct geladen wordt?
<link rel="stylesheet" href="<?php echo base_url() ?>css/stylesheet.css" />
M'n htaccess file rewrite alles met index.php en zet m'n rootmap als base.
Precies wat ik wilde.
Nou ik ben er 5 uur mee bezig geweest, maar eindelijk gevonden waar die sleeping processes vandaan kwamen.
Het bleek te komen door de manier waarop ik user variables opsloeg in APC. Ik heb bijvoorbeeld nieuwsberichten of forum topics die ik met apc_store() opsloeg om te cachen. Eerst deed ik dit allemaal in één grote array met alle items erin (dus $forum=array(1=>'bericht1', 2=>'bericht 2'), $nieuws=array() etc). Nu heb ik ze allemaal hun eigen variabele gegeven. Nu is mijn script ineens 100x zo snel.
Nu ze allemaal apart staan hoeven ze niet meer op elkaar te wachten als 5 mensen tegenlijk 5 verschillende nieuwsberichten lezen en deze tegelijkertijd gecached worden, dan kan het script meteen verder en de mysql connectie sluiten... best stomme fout als je er zo achteraf over nadenkt.
Het bleek te komen door de manier waarop ik user variables opsloeg in APC. Ik heb bijvoorbeeld nieuwsberichten of forum topics die ik met apc_store() opsloeg om te cachen. Eerst deed ik dit allemaal in één grote array met alle items erin (dus $forum=array(1=>'bericht1', 2=>'bericht 2'), $nieuws=array() etc). Nu heb ik ze allemaal hun eigen variabele gegeven. Nu is mijn script ineens 100x zo snel.
Nu ze allemaal apart staan hoeven ze niet meer op elkaar te wachten als 5 mensen tegenlijk 5 verschillende nieuwsberichten lezen en deze tegelijkertijd gecached worden, dan kan het script meteen verder en de mysql connectie sluiten... best stomme fout als je er zo achteraf over nadenkt.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Pagina's deden er dus daadwerkelijk een halve minuut over om te laden, dat zou je sowieso snel door moeten hebben.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ik had het al maanden zo draaien, kun je nagaan.quote:
Pagina's deden er dus daadwerkelijk een halve minuut over om te laden, dat zou je sowieso snel door moeten hebben.
* mstx gaat zich diep schamen
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Zulke dingen kun je via een trace wel snel vinden waarschijnlijk. Htop en s/L zijn je vriend.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
ik weet dat ik hier fout zit maar zou iemand me aub kunnen zeggen hoe ik het volgende bestandje moet downloaden...na de 5sec blijf ik maar wachten
http://www.multiupload.nl/AKATNDA2Q0
http://www.multiupload.nl/AKATNDA2Q0
Chuck Norris threw a grenade & killed 10 people. Then the grenade exploded.
quote:Dit bestand bestaat niet, de toegang tot het volgende bestand is beperkt of het bestand is verwijderd wegens overtreding van het auteursrecht.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Nice dat het gefixt is!quote:Op maandag 5 november 2012 21:56 schreef mstx het volgende:
Nou ik ben er 5 uur mee bezig geweest, maar eindelijk gevonden waar die sleeping processes vandaan kwamen.
Het bleek te komen door de manier waarop ik user variables opsloeg in APC. Ik heb bijvoorbeeld nieuwsberichten of forum topics die ik met apc_store() opsloeg om te cachen. Eerst deed ik dit allemaal in één grote array met alle items erin (dus $forum=array(1=>'bericht1', 2=>'bericht 2'), $nieuws=array() etc). Nu heb ik ze allemaal hun eigen variabele gegeven. Nu is mijn script ineens 100x zo snel.
Nu ze allemaal apart staan hoeven ze niet meer op elkaar te wachten als 5 mensen tegenlijk 5 verschillende nieuwsberichten lezen en deze tegelijkertijd gecached worden, dan kan het script meteen verder en de mysql connectie sluiten... best stomme fout als je er zo achteraf over nadenkt.
quote:Op maandag 5 november 2012 22:13 schreef mstx het volgende:
[..]
Ik had het al maanden zo draaien, kun je nagaan.
* mstx gaat zich diep schamen
Heb je in de afgelopen maanden zo veel meer gebruikers gekregen dat het nu steeds erger werd?
gr gr
