meerdere php requests en sql queries
Ik ben een app developer en gebruik php->sql zodat gebruikers informatie kunnen toevoegen en ophalen.
Nu gebruikte ik eerder per sql query een apart php script.
Echter heb ik nu een manier gevonden waarop ik automatisch in php een juiste query kan generen
en ik dus maar 1 script nodig heb om al mijn quaries uit te krijgen (wat mij een hoop tijd scheelt, omdat ik niet per query een nieuw script hoef te schrijven wat die uitvoert).
Alleen wil ik dit nu in al mijn apps gebruiken, voor elke knop die iets doet waarvoor sql nodig is.
De informatie word dan wel uit verschillende tabels gehaald, maar alle requests worden gegeneerd en doorgestuurd via 1 php script. (als ik informatie terug wil ontvangen, gaat dit via een echo, die ik in mijn app weer omzet in de juiste elementen)
Oftewel dit kan dus betekenen dat ik 100 requests tegelijk krijg op hetzelfde php script.
Nu mijn vraag: als 100 mensen tegelijk informatie opvragen, via hetzelfde php script, wat een echo geeft van de informatie, gaat dit dan door elkaar lopen? kan dit? levert het wel problemenen op als 100 mensen tegelijk iets schrijven via hetzelfde php script etc?
Hoop dat het een beetje duidelijk is wat bedoel :)
http://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html
Maar dat ligt uiteraard aan je server, hoe die instellingen staan en hoeveel die aankunnen.
Peter Flos op 13/10/2014 14:42:48:
Als 100 mensen 100 query's op eenzelfde seconde proberen te verkrijgen is de kans groot dat je SQL Server down gaat. Je zult (in de meeste gevallen) een error krijgen met To Many Connections:
http://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html
Maar dat ligt uiteraard aan je server, hoe die instellingen staan en hoeveel die aankunnen.
http://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html
Maar dat ligt uiteraard aan je server, hoe die instellingen staan en hoeveel die aankunnen.
maar het maakt verder niet uit of dit allemaal via 1 php scripts verloopt of via een aantal verschillende php scripts?
Hoe is het dan mogelijk dat stel je heb 1mil gebruikers (i wish), die allemaal door pagina's aan t bladeren zijn op je app (waarvan de informatie allemaal via queries gehaalt moet worden) dat het dan alsnog blijft draaien?
- Er zijn 100 mensen
- Er zijn 20 pagina's
- Er zijn 50 standaard query's, waarbij er op elke pagina nog 10 nodig zijn
Dan krijg je dit:
(50 + 10) x 100
Anders krijg je:
100 x 100
Stel, even als voorbeeld. Het is een app waarbij je een Account hebt, en er een Premium is (Denk aan Spotify), met een verloop datum.
Op de pagina met Volgers hoef je niet met een Query te achterhalen of iemand premium heeft, omdat je die informatie daar niet gebruikt.
Als iets 1 miljoen gebruikers heeft, zal die het niet snel met 1 Server redden.
Toevoeging:
Zie ook wat Aar zegt, dat is ook een oplossing.
Gewijzigd op 13/10/2014 15:06:18 door Peter Flos
Ik zeg altijd: haal niet meer op dan nodig is. Als je 100 requests nodig hebt, heb je die gewoon nodig. Als je er 20 nodig hebt maar er 100 gebruikt, dan is het zonde dat je server ervan traag (kan) worden.
Oké, maar dat bedoelde ik niet. Ik bedoelde dus... op een normale site, bijv. zoals deze... hoeveel database-requests worden er dan gedaan. Wat is gemiddeld? Praat je over 1 tot 10, of eerder 30 tot 50? Ik kan me voorstellen dat als je 50 requests per keer doet dat je site dan traag wordt? Of niet? Dus vandaar mijn vraag of er een soort van "maximum" is om te voorkomen dat je je eigen site onderuit trekt.
Peter Flos op 13/10/2014 15:05:51:
Uiteraard maakt dat wel uit. Zie het onderstaande voorbeeld:
- Er zijn 100 mensen
- Er zijn 20 pagina's
- Er zijn 50 standaard query's, waarbij er op elke pagina nog 10 nodig zijn
Dan krijg je dit:
(50 + 10) x 100
Anders krijg je:
100 x 100
Stel, even als voorbeeld. Het is een app waarbij je een Account hebt, en er een Premium is (Denk aan Spotify), met een verloop datum.
Op de pagina met Volgers hoef je niet met een Query te achterhalen of iemand premium heeft, omdat je die informatie daar niet gebruikt.
Als iets 1 miljoen gebruikers heeft, zal die het niet snel met 1 Server redden.
Toevoeging:
Zie ook wat Aar zegt, dat is ook een oplossing.
- Er zijn 100 mensen
- Er zijn 20 pagina's
- Er zijn 50 standaard query's, waarbij er op elke pagina nog 10 nodig zijn
Dan krijg je dit:
(50 + 10) x 100
Anders krijg je:
100 x 100
Stel, even als voorbeeld. Het is een app waarbij je een Account hebt, en er een Premium is (Denk aan Spotify), met een verloop datum.
Op de pagina met Volgers hoef je niet met een Query te achterhalen of iemand premium heeft, omdat je die informatie daar niet gebruikt.
Als iets 1 miljoen gebruikers heeft, zal die het niet snel met 1 Server redden.
Toevoeging:
Zie ook wat Aar zegt, dat is ook een oplossing.
ok oftewel een server kan het niet aan als er simpelweg teveel queries zijn?
Hoe doet een druk bezocht forum dit dan bijvoorbeeld?
Maar goed als dat gewoon een hardware limiet is kan ik er niet zoveel aan doen, ik wil voornamelijk zorgen dat mijn scripts niet voor problemen gaan zorgen later.
even terug komend op mijn php vraag:
stel je doet exact even veel queries, heeft het nut om deze te verdelen over zeg 10 scripts of kan ik zonder problemen alles via 1 php script dit oplossen? (kon dit niet uit je antwoord opmaken)
Het scheelt me namelijk veel werk (anders moet ik voor elke query een apart php script maken).
(als ik het via een script doe kan ik namelijk variable doorsturen vanwaaruit hij in php automatisch de juiste query statement maakt)
Je moet proberen met zo min mogelijk queries zoveel mogelijk van de gewenste data binnen te halen.
Dus een echt Maximum is er niet, omdat dat afhangt van het aantal gebruikers op je site.
Een server kan het niet aan als het volgens de server overschreden wordt. Ik heb het zelf eens meegemaakt; via een cronjob 20 queries elke seconde uitvoeren en 15 gebruikers online aan het klikken. 50% van de tijd kreeg ik een melding met To Many Connections, de andere 50% niet. Zodoende kwam ik tot de conclusie dat het ligt aan wanneer je klikt.
Het maakt niet uit of je het volgende doet:
function_1.php
Code (php)
1
2
3
2
3
<?php
$CountIfExist = mysqli_query($con,"SELECT id FROM users WHERE id = '1'");
?>
$CountIfExist = mysqli_query($con,"SELECT id FROM users WHERE id = '1'");
?>
function_2.php
Code (php)
1
2
3
2
3
<?php
$CountUsers = mysqli_query($con,"SELECT id FROM users");
?>
$CountUsers = mysqli_query($con,"SELECT id FROM users");
?>
functions.php
Of dat je doet:
functions.php
Code (php)
1
2
3
4
2
3
4
<?php
$CountIfExist = mysqli_query($con,"SELECT id FROM users WHERE id = '1'");
$CountUsers = mysqli_query($con,"SELECT id FROM users");
?>
$CountIfExist = mysqli_query($con,"SELECT id FROM users WHERE id = '1'");
$CountUsers = mysqli_query($con,"SELECT id FROM users");
?>
Dat maakt geen enkel verschil. Wat wel een verschil maakt is dit:
function_2.php
Code (php)
1
2
3
2
3
<?php
$CountUsers = mysqli_query($con,"SELECT id FROM users");
?>
$CountUsers = mysqli_query($con,"SELECT id FROM users");
?>
Of:
function_2.php
Code (php)
1
2
3
2
3
<?php
$CountUsers = mysqli_query($con,"SELECT * FROM users");
?>
$CountUsers = mysqli_query($con,"SELECT * FROM users");
?>
In voorbeeld 1 haalt de Query enkel het ID op, in voorbeeld 2 haalt de Query alles op.
Oké, thanks :)
Peter Flos op 13/10/2014 14:42:48:
Als 100 mensen 100 query's op eenzelfde seconde proberen te verkrijgen is de kans groot dat je SQL Server down gaat.
Ik denk dat je MySQL onderschat. ;-)
Een van onze servers heeft de afgelopen 7,5 maand gemiddeld (!) meer dan 400 queries per seconde verwerkt. En ik praat dan niet eens over een erg zware server; hij is 6 jaar oud en qua performance en geheugen vergelijkbaar met mijn laptop. En eigenlijk is die database niet eens de hoofdtaak van die server, maar meer iets wat 'ie erbij doet.
(ik had het toen getest door de Cron, maar laat ik nu niet de webwinkel uit de lucht gaan halen ;))
Ozzie PHP op 13/10/2014 15:31:22:
Wat bedoel je met 1 script en 10 scripts? Wat versta jij onder een script?
Je moet proberen met zo min mogelijk queries zoveel mogelijk van de gewenste data binnen te halen.
Je moet proberen met zo min mogelijk queries zoveel mogelijk van de gewenste data binnen te halen.
Ik vraag me gewoon af of als je, zegt, 1000 requests tegelijk krijgt op 1 php script of het php script dat aankan (of dat het beter is om te verdelen over een aantal php scripts).
oftewel hoeveel requests kan 1 php script tegelijk aan?
als 1000 mensen tegelijk via 1 php script een query doen is dat een probleem?
moet ik dat dan opdelen in meerdere php scripts waar dat kan?
het is vast een enorme noob vraag, maar het is wel belangrijk.
vervolg vraag:
hoe het bij mij nu zit:
app -> php script -> sql database -> php script (echo informatie) -> app
maar levert dit geen problemen op, waarbij bij de ene persoon de informatie terug krijgt van iemand anders zijn php request/echo.
Gewijzigd op 13/10/2014 16:24:29 door wout boer
Wout boer op 13/10/2014 15:55:29:
Ik vraag me gewoon af of als je, zegt, 1000 requests tegelijk krijgt op 1 php script of het php script dat aankan (of dat het beter is om te verdelen over een aantal php scripts).
Zo werkt niet niet. Een request komt binnen op je webserver. Die start vervolgens een proces/child/worker waarin hij voor die betreffende request het PHP-script uitvoert.
Als er dus 100 requests tegelijk voor hetzelfde script binnenkomen, zullen er 100 processen draaien die elk afzonderlijk het script uitvoeren. Je hoeft er dus in principe geen rekening mee te houden dat je script "het aankan".
Althans... er zijn wel kleine dingetjes waar je rekening mee moet houden. Als je script tijdelijk iets in een tussenbestandje schrijft moet je dat niet /tmp/tmpfile noemen, want dan zitten die 100 scripts elkaar wel in de weg. Dat valt echter eenvoudig op te lossen door in dit soort gevallen altijd een unieke naam te gebruiken. PHP heeft daar zelfs de functies tmpfile() en tempnam() voor.
Zelf werk ik voor een webshop die heel veel query's gebruikt uiteraard. Het meeste is op te lossen met caching. Productpagina's kunnen zo goed als compleet gecached worden. Net als overzichtspagina's. Elke keer als een gebruiker een pagina ophaalt wordt er gekeken of de cache ouder is als 24 uur. Is dit niet het geval dan wordt de gecachde inhoud geserveerd door de server. Is dit wel het geval dat worden er een serie query's gedaan en wordt het resultaat opgeslagen in de cache. Hierdoor wordt de database zo min mogelijk belast.
Zoals ik eerder aangaf is het ook belangrijk welke query's je uitvoert. Als ik bijvoorbeeld de volgende query uitvoer:
SELECT * FROM `orders`
Dan kan dat makkelijk enkele tientallen minuten duren omdat die database ongelovelijk veel regels bevat.
SELECT `id` FROM `orders`
Deze query is vele malen sneller.
Belangrijk is en blijft dat je alleen informatie ophaalt die je gaat gebruiken. Veel beginners maken snel fouten met SELECT * FROM omdat ze dan alle informatie ophalen uit een regel terwijl dit vaak niet nodig is.
Mijn laatste puntje is: hergebuik
Als je data meerdere keren op een pagina nodig hebt en je wilt geen gebruik maken van cache sla deze info dan bijvoorbeeld op in een array zodat je de query niet opnieuw hoeft te doen.
Jr Melgert op 13/10/2014 16:51:06:
Ik begrijp niet waarom er mensen hier praten over een aantal query's op een pagina. Dat is echt totaal irrelevant.
Niet mee eens. Elke query die je uitvoert geeft een bepaalde overhead, zoals het compileren en optimaliseren van je query. Jij doet het voorkomen alsof je alle wereldproblemen kan oplossen door een wildcard te vervangen door een paar veldnamen, maar dat is slechts een deel van het geheel. Als je een slecht gekozen index op een tabel hebt, is dat vaak veel bepalender voor de performance van je database. En zo kan ik nog wel een stuk of twintig dingen opnoemen waar je rekening mee zou moeten houden.
Wel is het zo dat een select * een van de eenvoudigste dingen is om op te optimaliseren. Het maakt bovendien je code inzichtelijker als je expliciet aangeeft welke velden je ophaalt. Maar die extreme snelheidswinsten die jij noemt, haal je alleen maar als je erg grote rijen hebt waar je maar relatief weinig velden van gebruikt.
Goed plan Peter. Wanneer begin je eraan? Ik ben er ook wel benieuwd naar.
Goed zo.