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.
Hierbij
| 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 class statsOutputException extends Exception { private $error_id = 0; # intern numeriek id van de fout private $error_vars = array(); # array met fout eigenschappen public function __construct($error_params, $code = 0, Exception $previous = null) { # check of het een array met waarden betreft if(is_array($error_params)) { $this->error_id = isset($error_params['id']) ? $error_params['id'] : null; $this->error_vars = (isset($error_params['vars']) && is_array($error_params['vars'])) ? $error_params['vars'] : array(); }else{ # input is string of int, handel op de normale manier af $this->error_id = $error_params; } # roep Exception contructor aan parent::__construct($this->error_id, $code, $previous); } # geeft de vars terug welke de foutcode aanvullen met eventuele extra gegevens public function getErrorVars() { return $this->error_vars; } } ?> |
Help 
ik heb weer eens iets raars nodig. Het is mij ooit al gelukt, maarja waarom zou je zoiets dan bewaren.
Vanaf een leverancier wordt er naar ons XML gepusht (dmv POST) naar http://server.tld/test.php. Dit gebeurd zonder variable naam.
Hoe kan ik dit met PHP afvangen? Een foreach met alle POSTS vars blijft angstvallig leeg.
Als ik de contents van phpinfo(); naar mijzelf mail krijg ik het volgende:
Dit wil zeggen dat ik met $_POST['<?xml_version'] wel de data op zou kunnen halen, en er later weer '<?xml_version' voor kan plakken maar helemaal netjes lijkt het mij niet.
ik heb weer eens iets raars nodig. Het is mij ooit al gelukt, maarja waarom zou je zoiets dan bewaren.Vanaf een leverancier wordt er naar ons XML gepusht (dmv POST) naar http://server.tld/test.php. Dit gebeurd zonder variable naam.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | <?xml_version "1.0" encoding="UTF-8" ?> <message> <messageheader> <debug>false</debug> <msgtype>incoming</msgtype> <msgversion>1.0</msgversion> <msgidentifier></msgidentifier> <errorcode>0</errorcode> <errorcodedescription>ok</errorcodedescription> <msgdatetime>2014-04-18T11:02:55</msgdatetime> </messageheader> <messagebody> <clip>200</clip> <did></did> <extension>200</extension> <prefix>Roy</prefix> </messagebody> </message> |
Hoe kan ik dit met PHP afvangen? Een foreach met alle POSTS vars blijft angstvallig leeg.
Als ik de contents van phpinfo(); naar mijzelf mail krijg ik het volgende:
Dit wil zeggen dat ik met $_POST['<?xml_version'] wel de data op zou kunnen halen, en er later weer '<?xml_version' voor kan plakken maar helemaal netjes lijkt het mij niet.
file_get_contents("php://input") ?quote:Op vrijdag 18 april 2014 11:06 schreef wobbel het volgende:
Help
Vanaf een leverancier wordt er naar ons XML gepusht (dmv POST) naar http://server.tld/test.php. Dit gebeurd zonder variable naam.
[ code verwijderd ]
Hoe kan ik dit met PHP afvangen? Een foreach met alle POSTS vars blijft angstvallig leeg.
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 was 't!!! Me love u long time
Ik ben op zoek naar een PHP library waarmee ik een soort mini-forumpje kan maken, zonder veel poespas, zoals phpBB.
Een beetje dit idee:
Ik wil het gebruiken als een soort berichtenprikbord waar iedereen berichtjes op kan plaatsen. Dus geen commentsystem.
Een beetje dit idee:
Ik wil het gebruiken als een soort berichtenprikbord waar iedereen berichtjes op kan plaatsen. Dus geen commentsystem.
Waarom gebruik je niet gewoon Disqus zelf?quote:
Ik ben op zoek naar een PHP library waarmee ik een soort mini-forumpje kan maken, zonder veel poespas, zoals phpBB.
Een beetje dit idee:
[ afbeelding ]
Ik wil het gebruiken als een soort berichtenprikbord waar iedereen berichtjes op kan plaatsen. Dus geen commentsystem.
Ongeveer wel ja.quote:Op maandag 21 april 2014 09:35 schreef Swetsenegger het volgende:
Dus eigenlijk wil je een gastenboek?
Omdat daar een heel gebeuren aan vastzit wat ik helemaal niet nodig heb.quote:
[..]
Waarom gebruik je niet gewoon Disqus zelf?
Valt wel mee toch? Gewoon een accountje maken, includen op de pagina waar je het hebben wil en klaar is keesquote:
[..]
Omdat daar een heel gebeuren aan vastzit wat ik helemaal niet nodig heb.
Accountje aanmaken is voor veel mensen een dergelijke grote stap dat ze het maat laten zitten. Leuk voorbeeld is de case van Amazon die het account aanmaken niet meer verplicht stelde vooraf de aankoop.quote:
[..]
Valt wel mee toch? Gewoon een accountje maken, includen op de pagina waar je het hebben wil en klaar is kees
Ik bedoelde de moeite die het kost om het te installeren. Reageren kan volgens mij ook zonder account.quote:Op dinsdag 22 april 2014 09:03 schreef Maringo het volgende:
[..]
Accountje aanmaken is voor veel mensen een dergelijke grote stap dat ze het maat laten zitten. Leuk voorbeeld is de case van Amazon die het account aanmaken niet meer verplicht stelde vooraf de aankoop.
Dat is gewoon niet wat ik zoek. Ik heb zelf inmiddels al een code geschreven. Kostte uiteindelijk minder moeite dan een geschikte library vinden.quote:
[..]
Valt wel mee toch? Gewoon een accountje maken, includen op de pagina waar je het hebben wil en klaar is kees
quote:
[..]
Dat is gewoon niet wat ik zoek. Ik heb zelf inmiddels al een code geschreven. Kostte uiteindelijk minder moeite dan een geschikte library vinden.
Ik betwijfel het, maar goed dat je voorzien bent nu 
Interessante praatjes zijn datquote:
https://www.destroyallsoftware.com/talks/boundaries
Ik zit al een tijd met mijn handen in het haar betreft de FOK!vriendjes module welke ik sinds kort in het FOK!stats script heb zitten. Het probleem is dat deze erg traag is, het probleem zit in het PHP script welke blijkbaar struggles heeft met de grote hoeveelheid data welke verwerkt moet worden.
Het script doet het volgende:
1. Haal alle topic-id's op waar de ingevoerde gebruiker heeft gereageerd
2. Haal alle posts behorende bij de topic-id's op in delen van 32 topics, dit omdat Sphinx is ingesteld op max 10.000 resultaten
3. Loop over alle posts en voeg de bijbehorende topic-id's toe aan een array welke de unieke topic's per gebruiker gevat.
Uit bovenstaande stappen hou je uiteindelijk een lijst over van alle topics waar andere gebruikers samen met de ingevoerde gebruiker hebben gereageerd.
Zie het volgende stukje code, de array $resultaat["matches"] (afkomstig uit Sphinx) bevat alle unieke topic-id's waar de ingevoerde gebruiker gereageerd heeft.
Iemand een idee hoe ik het script sneller kan maken? Ik heb er nu een limiet van een maand op zitten omdat het anders veel te traag wordt. Het idee is de topics te verkrijgen waar je samen met iemand hebt gepost. Als je vaak in dezelfde topics als de ingevoerde gebruiker post zul je hoger in de lijst van die gebruiker komen te staan.
Het script doet het volgende:
1. Haal alle topic-id's op waar de ingevoerde gebruiker heeft gereageerd
2. Haal alle posts behorende bij de topic-id's op in delen van 32 topics, dit omdat Sphinx is ingesteld op max 10.000 resultaten
3. Loop over alle posts en voeg de bijbehorende topic-id's toe aan een array welke de unieke topic's per gebruiker gevat.
Uit bovenstaande stappen hou je uiteindelijk een lijst over van alle topics waar andere gebruikers samen met de ingevoerde gebruiker hebben gereageerd.
Zie het volgende stukje code, de array $resultaat["matches"] (afkomstig uit Sphinx) bevat alle unieke topic-id's waar de ingevoerde gebruiker gereageerd heeft.
| 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 26 27 28 29 30 31 32 33 34 35 36 37 38 | <?php if(!empty($resultaat["matches"])) { $current_count = 0; $topic_ids = array(); $users_topics = array(); $this->cl->resetGroupBy(); # loop over de gevonden topic-id's foreach($resultaat["matches"] as $mId => $mData) { $current_count++; $pCounts = $mData['attrs']; $topic_ids[] = $pCounts['topic_id']; # verwerk het in stukken van 32 topics zodat het max uit de volgende query nooit boven de 10.000 (max Sphinx) uitkomt met 310 posts per topic gerekend if(count($topic_ids) == 32 || ($current_count == $total_found && !empty($topic_ids))) { $this->cl->resetFilters(); $this->cl->SetFilter("topic_id", $topic_ids); $topic_ids = array(); $this->cl->SetLimits(0, 10000, 10000); $resultaat = $this->cl->Query('', $this->config['indices']); $total_query_time += $resultaat["time"]; if(!empty($resultaat["matches"])) { # loop over de teruggegeven posts en voeg de topic-id's toe aan de array welke de unieke topics per gebruiker bevat, dit wordt later dvm de count functie toegevoegd aan de lijst welke wordt weergegeven in de tool # dit stuk is erg traag en doet er enkele seconden over om een lijst van 15.000 posts te verweken (ingevoerde gebruiker heeft in dit geval in 50 topics gepost) foreach($resultaat["matches"] as $mId => $mData) { if($mData['attrs']['auteur_id'] != $auteurId) { if(!isset($users_topics[$mData['attrs']['auteur_id']][$mData['attrs']['topic_id']])) { $users_topics[$mData['attrs']['auteur_id']][$mData['attrs']['topic_id']] = 1; } } } } } } } ?> |
Iemand een idee hoe ik het script sneller kan maken? Ik heb er nu een limiet van een maand op zitten omdat het anders veel te traag wordt. Het idee is de topics te verkrijgen waar je samen met iemand hebt gepost. Als je vaak in dezelfde topics als de ingevoerde gebruiker post zul je hoger in de lijst van die gebruiker komen te staan.
Wat is precies de bottleneck? Om wat voor orde van grootte gaat het in die loops? Zegt bijv. de xdebug profiler iets zinnigs?
Bij dit stuk gaat het traag:quote:
Wat is precies de bottleneck? Om wat voor orde van grootte gaat het in die loops? Zegt bijv. de xdebug profiler iets zinnigs?
| 1 2 3 4 5 6 7 8 9 | <?php foreach($resultaat["matches"] as $mId => $mData) { if($mData['attrs']['auteur_id'] != $auteurId) { if(!isset($users_topics[$mData['attrs']['auteur_id']][$mData['attrs']['topic_id']])) { $users_topics[$mData['attrs']['auteur_id']][$mData['attrs']['topic_id']] = 1; } } } ?> |
Bovenstaande voegt de teruggegeven data uit Sphinx toe aan de array waar de topics per gebruiker staan. Het gaat hier om losse posts, als een gebruiker in bijvoorbeeld 50 topics heeft gepost binnen een gekozen periode dan komt dat neer op ongeveer 15050 posts, ervan uitgaande dat er binnen elk topic 301 posts (incl. OP) staan.
Er zijn in dit geval dus 15050 loops nodig om alles bij langs te gaan, het meest trage is de isset en het toevoegen van de gegevens aan de array. Als dit dus op een andere, snellere manier zou kunnen dan zou dat een grote winst zijn aangezien ik de maximaal te selecteren periode dan kan ophogen, dit is nu een maand.
De overige stats worden allemaal door Sphinx zelf gegenereerd en dat gaat veel sneller. Deze statistiek is echter niet volledig te doen in Sphinx omdat ik op twee waarden moet groeperen, namelijk user_id en topic_id, dit omdat de topic-id's slechts één keer per gebruiker mogen worden geteld.
Een andere optie welke ik heb overwogen is het toevoegen van een gecombineerde waarde (user_id+topic_id) aan de index en daarop groeperen in de Sphinx query. Deze methode maakt de index echter significant groter en kost meer geheugen waar ik al niet teveel van heb in mijn server.
xdebug heb ik nog niet geprobeerd en heb ik ook geen ervaring mee. Ik ga daar ff naar kijken.
| 1 2 3 4 5 6 7 8 9 | <?php foreach($resultaat["matches"] as $mId => $mData) { if($mData['attrs']['auteur_id'] != $auteurId) { if(!isset($users_topics[$mData['attrs']['auteur_id']][$mData['attrs']['topic_id']])) { $users_topics[$mData['attrs']['auteur_id']][$mData['attrs']['topic_id']] = 1; } } } ?> |
Hier vallen me een paar dingen op. Om te beginnen ben ik benieuwd wat er in $auteurId staat en waarom er een != wordt gebruikt voor die vergelijking. Verder heb je de isset()-check niet nodig. Je set de waarde op 1, en als die toevallig al geset was, verandert er niets. En je benadert (ook zonder isset()) $mData['attrs']['auteur_id'] meerdere keren. Niet fout, maar ik zou er een variabele van maken (en dat waarschijnlijk ook doen voor $mData['attrs']['topic_id']), al was het maar voor een betere leesbaarheid.
Ik denk dat in het eerste if statement met de $auteurId wordt gekeken of de post niet van degene zelf is.quote:
[ code verwijderd ]
Hier vallen me een paar dingen op. Om te beginnen ben ik benieuwd wat er in $auteurId staat en waarom er een != wordt gebruikt voor die vergelijking. Verder heb je de isset()-check niet nodig. Je set de waarde op 1, en als die toevallig al geset was, verandert er niets. En je benadert (ook zonder isset()) $mData['attrs']['auteur_id'] meerdere keren. Niet fout, maar ik zou er een variabele van maken (en dat waarschijnlijk ook doen voor $mData['attrs']['topic_id']), al was het maar voor een betere leesbaarheid.
Die lijkt mij onhandig. De enkele keer dat ie nuttig is, weegt niet op tegen de keren dat ie niet nuttig is. Mijn idee is om die eruit te halen en eventueel na de foreach loop die ene entry uit $users_topics ($users_topics[$auteurId]) te halen.
[ Bericht 19% gewijzigd door Maringo op 26-04-2014 11:03:51 ]
Kan je deze logica niet veel beter in je SQL oplossen, dat lijkt me vele malen sneller dan het oplossen in PHP.quote:Op vrijdag 25 april 2014 22:56 schreef bondage het volgende:
Het script doet het volgende:
1. Haal alle topic-id's op waar de ingevoerde gebruiker heeft gereageerd
2. Haal alle posts behorende bij de topic-id's op in delen van 32 topics, dit omdat Sphinx is ingesteld op max 10.000 resultaten
3. Loop over alle posts en voeg de bijbehorende topic-id's toe aan een array welke de unieke topic's per gebruiker gevat.
In theory there is no difference between theory and practice. In practice there is.
In $auteurId staat het id van de user welke de post heeft geplaatst, aangezien ik de posts van degene waar op wordt gezocht wil negeren (wat Maringo al aangaf) gebruik ik die vergelijking.quote:
[ code verwijderd ]
Hier vallen me een paar dingen op. Om te beginnen ben ik benieuwd wat er in $auteurId staat en waarom er een != wordt gebruikt voor die vergelijking. Verder heb je de isset()-check niet nodig. Je set de waarde op 1, en als die toevallig al geset was, verandert er niets. En je benadert (ook zonder isset()) $mData['attrs']['auteur_id'] meerdere keren. Niet fout, maar ik zou er een variabele van maken (en dat waarschijnlijk ook doen voor $mData['attrs']['topic_id']), al was het maar voor een betere leesbaarheid.
Die isset is idd niet nodig, dom dat ik me dat niet eerder had gerealiseerd aangezien ik heel goed weet dat het in dit geval geen effect op de resulterende array heeft. Ik haal deze sowieso weg.
De waarden in $mData['attrs']['auteur_id'] en $mData['attrs']['topic_id'] zet ik in een variable, zelfs al levert het maar weinig op ben ik al blij.
In ieder geval heel erg bedankt voor het meedenken.
Dank. Ik ga het ff aanpassen en checken of het winst oplevertquote:Op zaterdag 26 april 2014 10:36 schreef Maringo het volgende:
Mijn idee is om die eruit te halen en eventueel na de foreach loop die ene entry uit $users_topics ($users_topics[$auteurId]) te halen.
Geprobeerd, met de volgende query:quote:
[..]
Kan je deze logica niet veel beter in je SQL oplossen, dat lijkt me vele malen sneller dan het oplossen in PHP.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | SELECT COUNT(*), naam FROM ( SELECT fok_user.naam, `fok_post`.auteur FROM `fok_post` RIGHT JOIN ( SELECT DISTINCT topicid FROM `fok_post` WHERE `auteur` = 128465 AND `fok_post`.`tijdstip` BETWEEN UNIX_TIMESTAMP('2014-04-01 00:00:01') AND UNIX_TIMESTAMP('2014-04-26 23:59:59') AND `fok_post`.`year` = 2014 ) AS t ON (`fok_post`.topicid = t.topicid) JOIN fok_user ON `fok_post`.auteur = fok_user.id WHERE `fok_post`.auteur != 128465 GROUP BY `fok_post`.auteur, `fok_post`.topicid ) AS u GROUP BY auteur ORDER BY COUNT(*) DESC LIMIT 100 |
Helaas een stuk trager dan mijn PHP oplossing
[ Bericht 61% gewijzigd door bondage op 26-04-2014 16:11:06 ]
Ahja, je wilt een overzicht van vriendjes maken. Hoe moet ik dat zien? Een lijst van users die in dezelfde topics gepost hebben?quote:Op zaterdag 26 april 2014 16:03 schreef bondage het volgende:
[..]
In $auteurId staat het id van de user welke de post heeft geplaatst, aangezien ik de posts van degene waar op wordt gezocht wil negeren (wat Maringo al aangaf) gebruik ik die vergelijking.
Die isset is idd niet nodig, dom dat ik me dat niet eerder had gerealiseerd aangezien ik heel goed weet dat het in dit geval geen effect op de resulterende array heeft. Ik haal deze sowieso weg.
De waarden in $mData['attrs']['auteur_id'] en $mData['attrs']['topic_id'] zet ik in een variable, zelfs al levert het maar weinig op ben ik al blij.
In ieder geval heel erg bedankt voor het meedenken.
Klopt. Zo is dit mijn lijstje wat ie eens op verzoek maakte:quote:
[..]
Ahja, je wilt een overzicht van vriendjes maken. Hoe moet ik dat zien? Een lijst van users die in dezelfde topics gepost hebben?
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 142 Rezania 139 d4v1d 120 Amarantha 118 FL_Freak 118 Lt.Surge 103 SgtPorkbeans 96 LittleBrownie 96 Flippiee 95 gianni61 94 Fopje 91 BBQSausage 85 Bitterlemon 84 Snowbells 74 Roburtt 72 HeaN82 |
getallen zijn het aantal topics.
Exactquote:
[..]
Ahja, je wilt een overzicht van vriendjes maken. Hoe moet ik dat zien? Een lijst van users die in dezelfde topics gepost hebben?
Ik heb je query wat herschreven, zonder subqueries en right joins. Ongetest, uiteraard.quote:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | SELECT count(DISTINCT friend_post.topic_id) cnt, u.naam FROM fok_user u INNER JOIN fok_post search_user_post ON search_user_post.auteur = 128465 AND search_user_post.tijdstip BETWEEN UNIX_TIMESTAMP('2014-01-01 00:00:01') AND UNIX_TIMESTAMP('2014-04-26 23:59:59') AND search_user_post.year = 2014 INNER JOIN fok_post friend_post ON friend_post.auteur = u.id AND friend_post.auteur != 128465 AND friend_post.topic_id = search_user_post.topic_id GROUP BY u.naam ORDER BY cnt DESC LIMIT 100; |
Oeh, ik ga hem ff testen.quote:
SELECT count(DISTINCT friend_post.topic_id) cnt, u.naam
FROM fok_user u
INNER JOIN fok_post search_user_post
ON search_user_post.auteur = 128465
AND search_user_post.tijdstip BETWEEN UNIX_TIMESTAMP('2014-01-01 00:00:01') AND UNIX_TIMESTAMP('2014-04-26 23:59:59')
AND search_user_post.year = 2014
INNER JOIN fok_post friend_post
ON friend_post.auteur = u.id
AND friend_post.auteur != 128465
AND friend_post.topic_id = search_user_post.topic_id
GROUP BY u.naam
ORDER BY cnt DESC
LIMIT 100;
