Efficientie en snelheid van mijn script

[Verwijderd]

Ik heb een script dat bezoekers die daarheen komen automatisch naar een andere site wordt gestuurd (een soort roteerscript). Snelheid is van grootste belang met dit script. Dit roteerscript moet een website uit de database kiezen op de volgende gegevens:

1) Random
2) Prioriteit van de website om geladen te worden.
3) Landgericht (de site in de database kan bezoekers van meerdere lanten accepteren)

Aangezien eerst alleen voorwaarde 1 gold had ik het volgende in de query:

PHP:

            ORDER BY 
                rand() 
            LIMIT
                1

Dat werkte perfect om een random rij terug te krijgen. Maar aangezien er nu nog 2 extra selectgegevens bij komen weet ik niet hoe ik het beste kan doen. Ik heb wel een aantal "ideetjes", maar weet niet of ze handig zijn. Ideetjes voor country check:

- landen in apparte tabel gekoppeld met een left join op basis van site_id als het ware (elk land 1 record). Maar met bijv. 150 landen, kost dat veel kracht en is dat dus langzaam?
- de landen serializen in de tabel, alle data uitlezen en in array proppen, unserializen, check doen, klaar
- is er een efficientere oplossing?

Voor de prioriteiten. Ik weet niet precies wat de handigste manier is, maar ik zat zelf te denken dat ik een veld kan maken waarin staat hoe vaak een site geladen moet worden (bijv. 5x zo vaak als standaard wat 1x is, soort selectbox met 2,3,4,5 etc. x normale hoeveelheid). Elke keer als een site geladen is wordt de status opgeteld. Op die manier gaat het script alle records af tot ze allemaal het aantal keer geladen zijn, en dan wordt alles weer naar 0 gezet. Zo krijg je ook een totaal random systeem, maar ook hierbij geldt dat ik niet weet hoeveel snelheid dit kost. Je hebt immers bij elke handeling weer een extra update en zo nu en dan een update van alle records (naar 0). Daarbij vraag ik me af wat er gebeurt wanneer alle sites naar 0 worden gezet, en op dat moment nog 100 andere bezoekers het script opvragen en misschien de query van de reset naar 0 nog niet volledig is uitgevoerd. Is dat een reëel gevaar?

[HawVer]

Wat je kunt doen is een veld toevoegen aan de tabel met de prioriteit. Bijvoorbeeld een site heeft prioriteit van 1-100, 100 hoogste prioriteit en wordt dus vaker geselecteerd. 1 laagste prioriteit.

- Je laat php een random getal genereren van 1 tot 100.
- Vervolgens selecteer je een random site uit de verzameling rijen met prioriteit > dan het gegenereerde getal. Hoe hoger de prioriteit van de site hoe groter de kans is dat hij geselecteerd word. (Niet getest) Zo maar ff brainstormen.. Weet niet of de theorie klopt. Stel je voor dat je de volgende reeks random getallen selecteerd. {10,20,30,40,50,60} En je hebt de volgende verzameling sites (alleen prioriteit) {35, 45, 60}

20 {35, 45, 60}
30 {35, 45, 60}
40 {45, 60}
50 {60}
60 {60}

Zoals je ziet is de kans dat je site met prioriteit 60 statistisch gezien het grootst.

Btw, het hele landen verhaal snap ik niet helemaal. Wat is daar precies de gedachte achter? Je kan toch gewoon een where aan je query toevoegen? Where land='Nederland'

[RobIII]

Voor het "prioriteren" kun je eens kijken in dit topic

Wat betreft die landen zie ik niet in waarom je een left join zou moeten gebruiken. Je kunt een veld toevoegen aan je tabel met land(code) en die toevoegen in je where-clause (zoals hierboven wordt gezegd). Je zou eventueel een landentabel in je DB kunnen opnemen (met landcode -> landnaam) en die zou je dan kunnen (inner) joinen. Qua performance-loss zal dat nihil zijn als je de juiste indexes maakt.

Maar wat ik begrijp uit je verhaal is dat je een soort "doorstuur" pagina aan 't maken bent? Waarom zou die paar milli-seconden een verschil maken? Heb je het over een site met duizenden hits per seconde, dan zou je kunnen gaan optimaliseren, maar als je "maar" een paar honderd (of een paar duizend) hits per uur hebt hoef je je om dit soort "optimalisaties" helemaal niet druk te maken. Die "100 bezoekers" waar je het over hebt, zijn die alle 100 "tegelijk" die pagina aan 't opvragen?

[ Voor 94% gewijzigd door RobIII op 17-08-2006 11:56 ]

[Verwijderd]

RobIII schreef op donderdag 17 augustus 2006 @ 11:51:
Voor het "prioriteren" kun je eens kijken in dit topic

Wat betreft die landen zie ik niet in waarom je een left join zou moeten gebruiken. Je kunt een veld toevoegen aan je tabel met land(code) en die toevoegen in je where-clause (zoals hierboven wordt gezegd). Je zou eventueel een landentabel in je DB kunnen opnemen (met landcode -> landnaam) en die zou je dan kunnen (inner) joinen. Qua performance-loss zal dat nihil zijn als je de juiste indexes maakt.

Ja, nu ik het zo lees klinkt het best stom... Alleen een simpele where werkt niet omdat er meerdere landen geselecteerd kunnen worden. Maar in dat geval kan ik natuurlijk wel de landen opslaan als een string (in een text veld vanwge de lengte van 100 landen bijvoorbeeld), gescheiden door een teken, en dan een LIKE=%||$land||% doen (niet juiste code maar het lijkt me duidelijk wat ik bedoel).

Ik zal het topic eens lezen (ik hadoverigens wel gezocht op tweakers en google maar niet gevonden , stom ). De oplossing van HawVer vind ik ook leuk, ga ik ook even naar kijken!

[RobIII]

Verwijderd schreef op donderdag 17 augustus 2006 @ 11:57:
[...]

Ja, nu ik het zo lees klinkt het best stom... Alleen een simpele where werkt niet omdat er meerdere landen geselecteerd kunnen worden.

Waarom zou dat niet werken?

SQL:

...where landcode in ('nl','be','uk','de') ...

Verwijderd schreef op donderdag 17 augustus 2006 @ 11:57:
Maar in dat geval kan ik natuurlijk wel de landen opslaan als een string (in een text veld vanwge de lengte van 100 landen bijvoorbeeld), gescheiden door een teken, en dan een LIKE=%||$land||% doen (niet juiste code maar het lijkt me duidelijk wat ik bedoel).

Dus een "url" kan aan meerdere landen "gekoppeld" zijn? URL_A is dus bijvoorbeeld voor nl én be? In dat geval kun je het beste je URL een ID geven en een koppeltabel maken met 2 velden (beide primary key): url_id en landcode.

Dan krijg je dus zoiets:

code:

Tabel URLs
*********
ID URL                    Prio
1  http://www.foo.com     10
2  http://www.bar.com     80
3  http://www.google.com  10

Tabel LandCodeURL
*********
Landcode Url_ID
nl       1
be       1
nl       2
uk       3

Op die manier heb je foo.com gekoppeld aan nl en be, bar.com aan enkel nl en google.com enkel aan uk. Vervolgens haal je met je query m.b.v. een inner join de gegevens uit de koppeltabel en urls tabel.

Dit is relatief basic SQL, wellicht dat je je daar nog even in kunt verdiepen

edit:
Lekker eerst

[ Voor 7% gewijzigd door RobIII op 17-08-2006 12:05 ]

[Janoz]

Wil je asjeblieft die ranzigheden achterwege laten? Je hoeft nooit iets met scheidingstekens in 1 veld te stoppen. Dat is vaak een teken van brak db ontwerp. De normale manier voor een M:N relatie is een koppeltabel. Deze kun je gewoon joinen met de orginele tabel.

edit: Wat rob zegt

[ Voor 4% gewijzigd door Janoz op 17-08-2006 12:04 ]

[TeeDee]

Verwijderd schreef op donderdag 17 augustus 2006 @ 11:57:
[...]
Maar in dat geval kan ik natuurlijk wel de landen opslaan als een string (in een text veld vanwge de lengte van 100 landen bijvoorbeeld), gescheiden door een teken, en dan een LIKE=%||$land||% doen (niet juiste code maar het lijkt me duidelijk wat ik bedoel).

Dan moet je een koppeltabel maken. Data gescheiden met een scheidingsteken opslaan doe je praktisch nooit.

edit:
lol, volgens mij is het nu wel duidelijk dat er een koppeltabel gemaakt dient te worden

[ Voor 9% gewijzigd door TeeDee op 17-08-2006 12:05 ]

[TheRookie]

Ik zou dan eerder een koppeltabel maken waar je een site_id en land_id in zet; zijn er meerdere land_id's voor een site van toepassing voeg je meerdere rijen in

[Verwijderd]

haha, ja, nouja dat is wat ik ook vroeg in mijn eerste post met die JOIN Toen jullie begonnen over een simpele where werd ik op het verkeerde been gezet qua gedachten. Daar kwam nog bij dat een country scriptje wat ik net zag met scheidingsrotzooi werkte.

Ik heb me wat onhandig en onjuist uitgedrukt geloof ik, in elk geval zit dit topic vol onzinnigheid van mij op het moment. Gelukkig krikken jullie het niveau nog een beetje omhoog...

[ Voor 10% gewijzigd door Verwijderd op 17-08-2006 12:24 ]

[Verwijderd]

Ik heb nog even gekeken naar die randomnes. Die percentages zijn wel leuk en aardig, maar... misschien niet echt werkbaar. Waarschijnlijk komt het er op neer dat er straks bijvoorbeeld 100 of zelfs 1000 sites in staan die ook nog eens vrij snel veranderen. Vrij ondoenlijk om daar de percentages van op te geven.

Bij de manier van HawVer heb je geen controle over de preciese hoeveelheden...

Is het geen mogelijkheid om grenzen voor de sites te genereren (100% / aantal sites). Stel er zijn 100 sites dan heeft elke site (100% / aantal sites) 1% kans om gekozen te worden, door middel van random getal moet > dan ondergrens en < dan bovengrens.

Op die manier kan ik een site bijv. 10x zo vaak weergegeven laten worden. Met bovenstaand voorbeeld zou het dan 100% / 110 sites worden, waarbij die ene site de onder- en bovengrens krijgt van 10 sites bij elkaar.

De grenzen zouden dan floats worden, en de grenzen zouden bij het verwijderen of toevoegen opnieuw vastgesteld moeten worden.

Klinkt het aardig, of kraam ik opnieuw grote onzin uit?

[ Voor 5% gewijzigd door Verwijderd op 17-08-2006 12:49 ]

[RobIII]

Ik kan er in ieder geval geen touw aan vastknopen. Volgens mij is (o.a.) mijn suggestie in dat topic precies wat je bedoelt

100% van 100 appels opeten is toch 100 appels opeten?
En als je dan 100% van 110 appels opeet, hoeveel heb je er dan op?

En anders, geef eens een real-world voorbeeld van wat je probeert te bereiken in simpele taal?

[ Voor 58% gewijzigd door RobIII op 17-08-2006 12:54 ]

[Verwijderd]

Probability zoals jij die vast stelt in jouw voorbeeld is een handmatig ingevoerd getal. Bij 1000 sites is dat niet handmatig in te voeren, die prohability moet automatisch vastgesteld worden.

Daarbij zou ik niet weten hoe ik bij jouw voorbeeld 1 site ten opzichte van bijvoorbeeld 100 andere sites 10x vaker weergegeven kan worden.

[Verwijderd]

Om in simpele mensentaal wil ik dus uiteindelijk het volgende:

Ik wil per site in kunnen stellen hoeveel vaker hij wordt weergegeven dan normaal.

Bijvoorbeeld er zijn 100 sites. Daarvan wil ik een aantal sites (kan verschillen) vaker weergegeven worden.

Bijvoorbeeld site A laat ik 4x vaker weergegeven worden dan normaal, site B 7x vaker. Dus als elke site 1x is weergegeven is site A 4x weergegeven en site B 7x weergegeven (voor de duidelijkheid, in totaal dus 111x een website bezocht).

[HawVer]

Verwijderd schreef op donderdag 17 augustus 2006 @ 13:06:
Probability zoals jij die vast stelt in jouw voorbeeld is een handmatig ingevoerd getal. Bij 1000 sites is dat niet handmatig in te voeren, die prohability moet automatisch vastgesteld worden.

Daarbij zou ik niet weten hoe ik bij jouw voorbeeld 1 site ten opzichte van bijvoorbeeld 100 andere sites 10x vaker weergegeven kan worden.

Zou op zich wel kunnen. Je stelt per site een max views veld in. Je moet dan per site een counter bijhouden in de database. Als een site aan zijn max count zit mag hij niet meer geselecteerd worden. Je moet dan volstrekt random uit de overgebleven keuzes een site selecteren en zijn counter verhogen. Als alle counters van alle sites gelijk zijn aan hun eigen max view moeten alle counters gereset worden. Maar lijkt me een intensieve oplossing.

[Thekk]

Als je iedere site even veel kans wil geven om geselecteerd te worden kan je waarschijnlijk het beste kiezen voor een database design waarin je aan iedere link een rand() waarde toevoegd. Omdat die waarde in de tabel wordt opgeslagen, hoef je niet tijdens je query voor iedere link weer een kans te berekenen, maar kan je volstaan met één enkele rand() aanroep. Dit scheelt veel tijd als je [b]veel[b] links hebt.
Vervolgens selecteer je aan de hand daarvan de rij die daar het dichtste bij ligt.

Dus:

code:

Tabel URLs
*********
ID URL                    Randval
1  http://www.foo.com     0.xxxx
2  http://www.bar.com     0.yyyy
3  http://www.google.com  0.zzzz

Als je wil dat een link vaker naar voren komt, kan je die rand() waarde in een losse hulptabel die gekoppeld is aan de linkID van je weblinks. In die tabel voer je dan alleen de linkID en een rand() waarde in. Omdat je meerdere rand() waardes aan één linkID kan koppelen, kan je zo bijvoorbeeld 1 waarde aan een link koppelen, en 4 aan en andere, en 7 aan weer een andere. Je kan alleen niet een link 7,1487656 keer zo vaak laten zien.

Dus:

code:

Tabel URLs
*********
ID URL                    
1  http://www.foo.com
2  http://www.bar.com
3  http://www.google.com

Tabel RandURL
UrlID   Randval
1      0.xxx
2      0.yyy
3      0.zzz
3      0.www

Waarbij 3 statistisch gezien twee keer zo vaak wordt getoond als 1 en 2

En je berekening bij je vorige post is niet correct, je hebt dan gemiddeld 109 views gehad (100 + 3 extra + 6 extra)

[ Voor 23% gewijzigd door Thekk op 17-08-2006 13:20 ]

[Verwijderd]

HawVer schreef op donderdag 17 augustus 2006 @ 13:12:
[...]

Zou op zich wel kunnen. Je stelt per site een max views veld in. Je moet dan per site een counter bijhouden in de database. Als een site aan zijn max count zit mag hij niet meer geselecteerd worden. Je moet dan volstrekt random uit de overgebleven keuzes een site selecteren en zijn counter verhogen. Als alle counters van alle sites gelijk zijn aan hun eigen max view moeten alle counters gereset worden. Maar lijkt me een intensieve oplossing.

Ja, die oplossing noemde ik ook in mijn eerste post. Ik voorzie daar dus misschien alleen wat problemen mee aangezien het hier om echt heel grote horden bezoekers gaat.

Met laatstegenoemde voorbeeld van een ondergrens en bovengrens heb je dat probleem niet. De query wordt er amper trager van. Alleen het beheer wordt traag omdat daar de bovengrens en ondergrens moet worden berekent, maar daar heeft alleen de beheerder last van. Alleen het kan best wezen dat ik iets over het hoofd zie met die methode.

[hamsteg]

Verwijderd schreef op donderdag 17 augustus 2006 @ 13:10:
Ik wil per site in kunnen stellen hoeveel vaker hij wordt weergegeven dan normaal.

Bijvoorbeeld er zijn 100 sites. Daarvan wil ik een aantal sites (kan verschillen) vaker weergegeven worden.

Heel simpel ... wel ... een voorbeeld, ik heb een tabel waarbij waarder 100 normaal is (%).

code:

Site 1  |  100  --> cum.totaal = 100
Site 2  |   70  --> cim.totaal = 170
Site 3  |  110  --> cum.totaal = 280 
Site 4  |  170  --> cum.totaal = 450

100+70+110+170 (count query at start initialisatie) = 450 = working range. RAND(working range) --> geeft een waarde binnen deze range. Stel 277, met een query is het nu vrij makkelijk om site 2 te vinden (of locale array met id en cum.totaal als het echt snel moet en Q-sort search methode).

Wil jij Site 4 de kans verdubbelen dan zet je die op 340, de range wordt dan 520 en ziedaar een grotere kans.

[ Voor 4% gewijzigd door hamsteg op 17-08-2006 13:32 ]

[Verwijderd]

Heey, youw methode ziet er super uit Thekk!

Ik wil de methode die ik net had bedacht ook nog even uittekeken. Misschien is het geen goede methode, en is het volslagen onzinnig en nutteloos, maar ik wil hem niet zomaar aan de kant schuiven zonder te weten waarom hij fout is.

In het beheer worden de grenzen telkens opnieuw vastgesteld bij het toevoegen, wijzigen of verwijderen van sites.

Ter voorbeeld, 100 sites, allemaal zelfde hoeveelheid van laten zien:

code:

Tabel URLs
*********
ID URL                    minGrens  Maxgrens
1  http://www.siteA.com     0         1
2  http://www.siteB.com     1         2
3  http://www.siteC.com     2         3
3  http://www.siteD.com     3         4
3  http://www.siteE.com     etc       etc

Ter voorbeeld, 100 sites, allemaal zelfde hoeveelheid van laten zien, maar B en D respectievelijk 4 en 7x meer:

100 / 109 = 0,93xxx

Dus een grens loopt doorgaans van ondergrens + 0,93 = bovengrens. Als een site 4x zo vaak bekeken moet worden krijgt hij de marge van de ondergrens tot 4x0,94 = bovengrens.

code:

Tabel URLs
*********
ID URL                    minGrens  Maxgrens
1  http://www.siteA.com     0         0.93
2  http://www.siteB.com     0.93      4.68
3  http://www.siteC.com     4.68      5.60
4  http://www.siteD.com     5.60      12.32
5  http://www.siteE.com     12.32     etc.

Vervolgens met een random getal van 1 tot 100 dr uithalen met een simpele where:

code:

WHERE
  $randomgetal > minGrens
AND
  $randomgetal < maxGrens

De getallen kloppen trouwens niet helemaal zag ik (die 0,93, fout ingetikt in rekemachine, maar het idee lijkt me duidelijk).

[Thekk]

Verwijderd schreef op donderdag 17 augustus 2006 @ 13:35:
Heey, youw methode ziet er super uit Thekk!

Thanks. Hij werkt wel het beste als je linktabel flink gevuld is...

[.....]

Een probleem bij deze methode is dat je iedere keer als je de kans wil veranderen, je hele tabel moet gaan updaten. En ook als je een nieuwe link toevoegd.
Dat is eigenlijk ook zo bij de oplossing van hamsteggot.

[ Voor 17% gewijzigd door Thekk op 17-08-2006 14:02 ]

[Verwijderd]

beetje offtopic, maar waarom noemen PHP'er zo vaak een SQL probleem ook PHP? (Zie topic title) Is dit omdat PHP/MySQL door velen als 1 geheel wordt gezien ofzo?

(sorry voor dit offtopic bericht, maar een geheel nieuw topic openen voor alleen deze vraag leek me ook weer een beetje overdreven)

[hamsteg]

Thekk schreef op donderdag 17 augustus 2006 @ 13:46:
Dat is eigenlijk ook zo bij de oplossing van hamsteggot.

In dit simpele voorbeeld wel maar ik zou in de interne tabel alles normaliseren naar gemiddeld 100 en deze tabel gebruiken (waarin dus website ID's zijn opgenomen). Elke keer een database volledig updaten is een beetje heel veel zonde van de performance.

Anders gezegd moet je je afvragen hoevaak je een entry toevoegt/waarde verandert. Zolang duurt het updaten van alle entries nu ook weer niet. Default elke nacht even laten uitvoeren is ook een optie om de integriteit van de databse op pijl te houden.

[HawVer]

Verwijderd schreef op donderdag 17 augustus 2006 @ 14:36:
beetje offtopic, maar waarom noemen PHP'er zo vaak een SQL probleem ook PHP? (Zie topic title) Is dit omdat PHP/MySQL door velen als 1 geheel wordt gezien ofzo?

(sorry voor dit offtopic bericht, maar een geheel nieuw topic openen voor alleen deze vraag leek me ook weer een beetje overdreven)

Het is zowel geen php probleem als een mysql probleem. Het probleem zit hem meer in de keuze voor een bepaalde strategie/ontwerp. Pas nadat je een ontwerp/methode goed uitgewerkt hebt, ga je programmeren. In principe zou het programmeren van een leien dakje moeten gaan.

[ Voor 5% gewijzigd door HawVer op 17-08-2006 14:50 ]

[Verwijderd]

Thekk schreef op donderdag 17 augustus 2006 @ 13:46:
[...]

Thanks. Hij werkt wel het beste als je linktabel flink gevuld is...

[...]

Een probleem bij deze methode is dat je iedere keer als je de kans wil veranderen, je hele tabel moet gaan updaten. En ook als je een nieuwe link toevoegd.
Dat is eigenlijk ook zo bij de oplossing van hamsteggot.

Ja, het zal denk ik sneller voorkomen dat er veel links in staan dan weinig, dus dan is jouw oplossing prima.

Wat betreft het updaten, dat vind ik niet zo'n heel groot probleem. Die 2 seconden (of hoe lang bijv. 100/1000 queries ook mag duren) die je moet wachten om een site up te daten is zo'n ramp nog niet op zich. Alleen de clientkant is echt essentieen...

Wat zou aan de clientkant het snelste werken, de methode die ik (of hamsteggot) noemde, of jouw methode? Bij jouw methode moet je wel joinen, ik weet niet in hoeverre dat meer performance kost dan een extra where argument?

[RobIII]

Waarom probeer je het niet gewoon? Maak een test-case en meet het. Maak een test-case van de andere methode en meet wederom. Leg resultaten langs elkaar et voila. Meten is weten
Los daarvan nogmaals: ik zou me niet al te druk maken om een where-clause / join op zo'n simpele tabel als je ook nog eens de juiste indices gebruikt. We kunnen hier niet tijdens het hele developmentproces van project X aan je handje vasthouden

Deze discussie gaat overigens meer richting SEA. Je krijgt daarom ook even een schopje

[ Voor 17% gewijzigd door RobIII op 17-08-2006 15:00 ]

[Verwijderd]

RobIII schreef op donderdag 17 augustus 2006 @ 14:54:
Waarom probeer je het niet gewoon? Maak een test-case en meet het. Maak een test-case van de andere methode en meet wederom. Leg resultaten langs elkaar et voila. Meten is weten
Los daarvan nogmaals: ik zou me niet al te druk maken om een where-clause / join op zo'n simpele tabel als je ook nog eens de juiste indices gebruikt. We kunnen hier niet tijdens het hele developmentproces aan je handje vasthouden.

Ok. Ik weet dat GoT geen kant en klare bouw-mijn-script site is, en in principe ben ik ver genoeg op weg geholpen om wat dingen te proberen nu. Dus bedankt!

[RobIII]

RobIII schreef op donderdag 17 augustus 2006 @ 14:54:
Deze discussie gaat overigens meer richting SEA. Je krijgt daarom ook even een schopje

Euh... schop dus
Moet nog even wennen aan de knopjes

[ Voor 255% gewijzigd door RobIII op 17-08-2006 15:01 ]