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.
quote:Op dinsdag 22 april 2014 19:51 schreef pascal08 het volgende:
[..]
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;
Ik heb de twee query's getest met het volgende resultaat (uiteraard SQL_NO_CACHE toegevoegd):
Jouw query:
Weergave van records 100 - 99 ( 100 totaal, query duurde 0.8366 sec)
Mijn query:
Weergave van records 100 - 99 ( 100 totaal, query duurde 4.1594 sec)
Die van jou is een stuk sneller. Ik ga even testen over langere periodes. Als dit goed werkt kan ik dit beter gebruiken dan de PHP oplossing.
[ Bericht 7% gewijzigd door bondage op 26-04-2014 18:18:21 ]
Jouw query:
Weergave van records 100 - 99 ( 100 totaal, query duurde 0.8366 sec)
| 1 2 3 4 | id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE search_user_post ref topicid,tijdstip,auteur,year auteur 4 const 12009 Using where; Using temporary; Using filesort 1 SIMPLE friend_post ref topicid,auteur topicid 4 fokstats.search_user_post.topicid 100 Using where 1 SIMPLE u eq_ref PRIMARY PRIMARY 4 fokstats.friend_post.auteur 1 |
Mijn query:
Weergave van records 100 - 99 ( 100 totaal, query duurde 4.1594 sec)
| 1 2 3 4 5 6 | id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY <derived2> ALL NULL NULL NULL NULL 2919 Using temporary; Using filesort 2 DERIVED <derived3> ALL NULL NULL NULL NULL 110 Using temporary; Using filesort 2 DERIVED fok_post ref topicid,auteur topicid 4 t.topicid 100 Using where 2 DERIVED fok_user eq_ref PRIMARY PRIMARY 4 fokstats.fok_post.auteur 1 3 DERIVED fok_post ref tijdstip,auteur,year auteur 4 12008 Using where; Using temporary |
Die van jou is een stuk sneller. Ik ga even testen over langere periodes. Als dit goed werkt kan ik dit beter gebruiken dan de PHP oplossing.
[ Bericht 7% gewijzigd door bondage op 26-04-2014 18:18:21 ]
Is het niet sowieso handiger om zoveel mogelijk het ophalen van de juiste data door een database engine te laten doen ipv dat ik PHP na te gaan bootsen? De database engine zal hierin bijna altijd sneller zijn, tenzij je 10 subqueries ofzo gebruikt.
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
De rest van de stats worden gegenereerd door Sphinx, echter heeft Sphinx niet de mogelijkheid om op meerdere velden te groeperen. Als ik dit volledig in Sphinx zou kunnen doen zou het een stuk sneller gaan.quote:
Is het niet sowieso handiger om zoveel mogelijk het ophalen van de juiste data door een database engine te laten doen ipv dat ik PHP na te gaan bootsen? De database engine zal hierin bijna altijd sneller zijn, tenzij je 10 subqueries ofzo gebruikt.
Maar ik realiseer me nu dat ik dit beter op kan lossen dmv een query ipv de data door php te laten verwerken.
Een andere optie is een betere server aanschaffen, daar heb ik echter op dit moment geen geld voor
Voer je die query uit op een 'eigen' server? Als in een database-server die je zelf beheert en waar je indexen kunt aanpassen? Dan moet er nog wel wat snelheidswinst te behalen zijn.quote:
[..]
De rest van de stats worden gegenereerd door Sphinx, echter heeft Sphinx niet de mogelijkheid om op meerdere velden te groeperen. Als ik dit volledig in Sphinx zou kunnen doen zou het een stuk sneller gaan.
Maar ik realiseer me nu dat ik dit beter op kan lossen dmv een query ipv de data door php te laten verwerken.
Een andere optie is een betere server aanschaffen, daar heb ik echter op dit moment geen geld voor
Jup, is mijn eigen server. Dit zijn de velden en indexen die ik momenteel heb:quote:
[..]
Voer je die query uit op een 'eigen' server? Als in een database-server die je zelf beheert en waar je indexen kunt aanpassen? Dan moet er nog wel wat snelheidswinst te behalen zijn.
Hmm... year heeft een kardinaliteit van 1. Heb je alleen posts uit 2014 in de database staan?quote:
[..]
Jup, is mijn eigen server. Dit zijn de velden en indexen die ik momenteel heb:
[ afbeelding ]
[ afbeelding ]
Dat viel mij ook al op idd. Er staat 6 jaar aan data in die tabel.quote:
[..]
Hmm... year heeft een kardinaliteit van 1. Heb je alleen posts uit 2014 in de database staan?
Is het overigens erg dat id een int(15) is? Ik heb deze database ooit van iemand overgenomen en hier niet bij stilgestaan, ik weet echter dat een gewone int niet tot 15 gaat.
Mooiquote:
[..]
Dat viel mij ook al op idd. Er staat 6 jaar aan data in die tabel.
Dan zou ik de index "auteur" wijzigen en er "year" als tweede kolom aan toevoegen. Een index mag namelijk meer dan 1 kolom bevatten (Je zou ook nog in plaats van "year" de kolom "tijdstip" kunnen toevoegen, maar ik vermoed dat het verschil vrij klein is terwijl de index veel groter kan worden.)
Nee, dat getal maakt alleen uit als je zerofill gebruikt. En dat wil je niet (want voorloopnullen toevoegen hoort de database niet te doen).quote:Is het overigens erg dat id een int(15) is? Ik heb deze database ooit van iemand overgenomen en hier niet bij stilgestaan, ik weet echter dat een gewone int niet tot 15 gaat.
Dank, ik ga die twee indices even combineren en de query dan nogmaals testen. Ik gebruik geen zerofill dus dat is dan geen probleem gelukkig.quote:
[..]
Mooi
(Je zou ook nog in plaats van "year" de kolom "tijdstip" kunnen toevoegen, maar ik vermoed dat het verschil vrij klein is terwijl de index veel groter kan worden.)
[..]
Nee, dat getal maakt alleen uit als je zerofill gebruikt. En dat wil je niet (want voorloopnullen toevoegen hoort de database niet te doen).
Wat is eigenlijk het voordeel van het combineren van die twee?
Volgens mij kun je year beter helemaal uit de query halen en gewoon zorgen dat je tijdstippen nooit meerdere jaren overspannen.
Als ik year uit de query haal en vervolgens dit jaar uitdraai duurt de query een stuk langer dan met year erin. Blijkbaar heeft de index voor dat veld wel effect. Ik had het primair toegevoegd voor het indexeringsproces omdat er per jaar een losse Sphinx index wordt gemaakt, op deze manier hoeft niet steeds alle data opnieuw verwerkt te worden. Dmv het year veld en bijbehorende index is ook die query een stuk sneller.quote:
Volgens mij kun je year beter helemaal uit de query halen en gewoon zorgen dat je tijdstippen nooit meerdere jaren overspannen.
Dan wil je wel heel zeker weten dat er een index op (auteur, tijdstip) wordt gebruikt. En ik weet niet hoe goed MySQL omgaat met een index die als range wordt gebruikt (BETWEEN) in combinatie met een andere index. Hoe beperkter het resultaat van een index is, hoe beter.quote:
Volgens mij kun je year beter helemaal uit de query halen en gewoon zorgen dat je tijdstippen nooit meerdere jaren overspannen.
Je maakt het MySQL op die manier makkelijker om twee kolommen te gebruiken in een index, waardoor de resultaatset kleiner wordt. En dat helpt weer om de snelheid omhoog te krijgenquote:
[..]
Dank, ik ga die twee indices even combineren en de query dan nogmaals testen. Ik gebruik geen zerofill dus dat is dan geen probleem gelukkig.
Wat is eigenlijk het voordeel van het combineren van die twee?
MySQL wordt ook wel beter in het combineren van twee losse indexen, maar dat levert volgens mij nog niet hetzelfde resultaat op.Overigens is een index op (auteur, year) ook nog steeds te gebruiken als index op auteur maar het is niet te gebruiken als index op year. Als je die ook los nodig hebt, moet je daar dus een aparte index voor maken / houden.
Duidelijk.quote:
[..]
Je maakt het MySQL op die manier makkelijker om twee kolommen te gebruiken in een index, waardoor de resultaatset kleiner wordt. En dat helpt weer om de snelheid omhoog te krijgen
Overigens is een index op (auteur, year) ook nog steeds te gebruiken als index op auteur maar het is niet te gebruiken als index op year. Als je die ook los nodig hebt, moet je daar dus een aparte index voor maken / houden.
En de year index heb ik inderdaad nodig aangezien die ook in de query van de Sphinx indexer wordt gebruikt. Ik ga nu de bestaande index op auteur verwijderen en van year en auteur een gecombineerde index maken. De losse year index laat ik gewoon staan. Ik post straks de resultaten incl. de output van EXPLAIN. Het aanpassen van de index gaat wel ff duren aangezien het om een erg grote tabel gaat.
Edit: ik kan blijkbaar de bestaande auteur index gewoon wijzigen. Heb year toegevoegd, de server is nu ff bezig.
Omdat ik soms zo loop te miepen over tests:
In theory there is no difference between theory and practice. In practice there is.
quote:
Omdat ik soms zo loop te miepen over tests:
[ afbeelding ]
Wat moet dit voorstellen
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
100% code coverage! (dit laat Devel::Cover zien en aangezien er weinig perl mensjes zijn ging ik de PHP mensjes spammenquote:
)[ Bericht 17% gewijzigd door slacker_nl op 30-04-2014 17:58:32 ]
In theory there is no difference between theory and practice. In practice there is.
Ziet er wel leuk uit, die statistiekenquote:
[..]
100% code coverage! (dit laat Devel::Cover zien en aangezien er weinig perl mensjes zijn ging ik de PHP mensjes spammen
Maar wat is er zo bijzonder aan die test met als time 85.9? Die duurt wel erg lang.
Dat is 000-package.t, daarin worden de volgende zaken getest:quote:
[..]
Ziet er wel leuk uit, die statistieken
Maar wat is er zo bijzonder aan die test met als time 85.9? Die duurt wel erg lang.
1) MANIFEST file ok
2) Modules compilen ok
3) POD (documentatie) syntax ok
4) POD coverage ok (dus doc je ook al je functies)
5) Compilen je scripts ok
Die duren wat langer, echt niet zo spannend allemaal. Dat zijn eigenlijk release-only tests.
In theory there is no difference between theory and practice. In practice there is.
Dan snap ik wel dat die tests ook lang duren (in ieder geval in verhouding).quote:
[..]
Dat is 000-package.t, daarin worden de volgende zaken getest:
1) MANIFEST file ok
2) Modules compilen ok
3) POD (documentatie) syntax ok
4) POD coverage ok (dus doc je ook al je functies)
5) Compilen je scripts ok
Die duren wat langer, echt niet zo spannend allemaal. Dat zijn eigenlijk release-only tests.
Hmm, de query is met deze nieuwe index trager geworden. Hij duurde eerst 0,83 seconden, nu 3,46. Ik heb exact dezelfde parameters gebruikt als de vorige keer toen de indices nog niet gecombineerd waren.
Dit is de explain:
Ik heb de query van Light gebruikt aangezien die sowieso al sneller was dan die van mij.
FORCE INDEX gebruiken misschien?
Dit is de explain:
Ik heb de query van Light gebruikt aangezien die sowieso al sneller was dan die van mij.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | SELECT count(DISTINCT friend_post.topicid) 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-04-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.topicid = search_user_post.topicid GROUP BY u.naam ORDER BY cnt DESC LIMIT 100; |
FORCE INDEX gebruiken misschien?
Hmm... da's wel onverwacht... het (geschatte) aantal rijen voor de eerste query gaat van 12.000 naar 2.400 en toch is de query veel trager...quote:
Hmm, de query is met deze nieuwe index trager geworden. Hij duurde eerst 0,83 seconden, nu 3,46. Ik heb exact dezelfde parameters gebruikt als de vorige keer toen de indices nog niet gecombineerd waren.
Dit is de explain:
[ afbeelding ]
Ik heb de query van Light gebruikt aangezien die sowieso al sneller was dan die van mij.
[ code verwijderd ]
FORCE INDEX gebruiken misschien?
Jup, ik snap er ook niets vanquote:
[..]
Hmm... da's wel onverwacht... het (geschatte) aantal rijen voor de eerste query gaat van 12.000 naar 2.400 en toch is de query veel trager...
Ik ga voor de zekerheid toch ff FORCE INDEX proberen.
Ik kan me niet voorstellen dat dat helpt, omdat de juiste index al wordt gebruikt.quote:
[..]
Jup, ik snap er ook niets van
Zou een gecombineerde index op topic_id en auteur misschien een optie zijn?quote:
[..]
Ik kan me niet voorstellen dat dat helpt, omdat de juiste index al wordt gebruikt.
Dat lijkt me niet nuttig, in ieder geval niet in die volgorde.quote:
[..]
Zou een gecombineerde index op topic_id en auteur misschien een optie zijn?
Heeft de table collation invloed op de gegevens die in de velden staat? Stel dat de table collation op latin1_swedish_ci staat maar de velden in de tabel op utf8_unicode_ci, heeft dit dan gevolgen?
De documentatie zegt hier het volgende over:
De documentatie zegt hier het volgende over:
Dit doet mij vermoeden dat het alleen om een standaardwaarde gaat en dit verder geen invloed heeft op de data in de tabel.quote:The table character set and collation are used as default values for column definitions if the column character set and collation are not specified in individual column definitions. The table character set and collation are MySQL extensions; there are no such things in standard SQL.
Ik heb alle bedrijven dat wel eens horen zeggen. Maar nog nooit een bedrijf tegengekomen die het geheel volgens het boekje heeft geïmplementeerd. Jammer hoor. Het scheelt zoveel in tijd en kwaliteit.quote:Op maandag 5 mei 2014 22:06 schreef TwenteFC het volgende:
Oh god, heb een boek gekocht over Test driven development, gaat het dan toch nog gebeuren?
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Krijg binnenkort de kans om een gehele shop vanaf scrap op te zetten, waarbij de oude database slechts als api wordt gebruikt.quote:
[..]
Ik heb alle bedrijven dat wel eens horen zeggen. Maar nog nooit een bedrijf tegengekomen die het geheel volgens het boekje heeft geïmplementeerd. Jammer hoor. Het scheelt zoveel in tijd en kwaliteit.
Ik weet hoe rampzalig niet geteste spaghetticode is, wil het dus deze keer meteen "goed" doen.Dat het tijd bespaart wil er bij de hogere heren nog niet in, maar heb als excuus gebruikt dat dit verplicht is voor mijn opleiding. (deeltijd hbo).
Ja dan is het zeker een goed voornemen om tests te schrijven. Heb het zelf vaak genoeg in projecten geprobeerd erdoorheen te krijgen, maar dan komt er een deadline om de hoek kijken en krijgt het geen prioriteit meer enzo.quote:
[..]
Krijg binnenkort de kans om een gehele shop vanaf scrap op te zetten, waarbij de oude database slechts als api wordt gebruikt.
Dat het tijd bespaart wil er bij de hogere heren nog niet in, maar heb als excuus gebruikt dat dit verplicht is voor mijn opleiding. (deeltijd hbo).
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Hier net zo, een klein bedrijf waar we eigenlijk meer misbruikt worden als helpdesk dan dat we daadwerkelijke nieuwe webapplicaties opzetten.quote:
[..]
Ja dan is het zeker een goed voornemen om tests te schrijven. Heb het zelf vaak genoeg in projecten geprobeerd erdoorheen te krijgen, maar dan komt er een deadline om de hoek kijken en krijgt het geen prioriteit meer enzo.
Prioriteit ligt blijkbaar bij het verminderen van het aantal klikjes dat een inkopertje moet doen
.
Wat dus soms ook een ramp is, omdat de code een ramp is. Oorspronkelijk gemaakt door een 16 jarige als bijbaantje 10 jaar geleden.
Ik voel je. Dat heb ik ook vaker meegemaakt. Met alle drama zoals security issues en jankende klanten eromheen. Maar dat is nu voorbijquote:
Ik probeer dat soort shit van me af te schuiven. Ga maar eerst investeren in fatsoenlijke software.
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Ok, de enige andere optie die ik kan bedenken is dat ik een snellere server nodig heb en dat de huidige gewoon niet voldoet om dit soort statistieken uit te draaien. In ieder geval bedankt voor het meedenkenquote:
[..]
Dat lijkt me niet nuttig, in ieder geval niet in die volgorde.
Dat herken ik, zo hebben wij 2 sites onder onze hoeden gekregen die zijn gebouwd door een gast in Bangladesh...quote:
Toen ik voor het eerst een problemen moest oplossen kwam ik al code tegen welke niks met de site te maken hadden en allemaal uit een ander project van deze gozer kwam.
Lezen? Of daadwerkelijk TDD gaan gebruiken?quote:
Oh god, heb een boek gekocht over Test driven development, gaat het dan toch nog gebeuren?
In theory there is no difference between theory and practice. In practice there is.
En is de database wel op orde? Als dat namelijk ook niet op orde is loop je alsnog tegen allerlei shit aan, tenzij je wat handige mappers gaat maken, maar dan moet je maar zien of dat ook performed. Overigens snap ik niet waarom bedrijven nog steeds hun eigen webshops ontwikkelen, het is duur in onderhoud, en je haalt nooit de kwaliteit die bestaande software levert.quote:
[..]
Krijg binnenkort de kans om een gehele shop vanaf scrap op te zetten, waarbij de oude database slechts als api wordt gebruikt.
Dat het tijd bespaart wil er bij de hogere heren nog niet in, maar heb als excuus gebruikt dat dit verplicht is voor mijn opleiding. (deeltijd hbo).
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Zo herkenbaar... 
al meerdere sites compleet opnieuw geschreven (eigen code) omdat a. of de code verouderd was, of b. niet leesbaar, of c. extreem ingewikkeld voor simpele toepassingen of een combinatie van alle 3 
Voordeel is wel dat de code gelijk up to date is, je niet steeds je hoeft in te lezen in de 'oude' code.
scheelt soms erg veel tijd/stress/frustraties om gewoon overnieuw te beginnen dan door te gaan op andermans werk
al meerdere sites compleet opnieuw geschreven (eigen code) omdat a. of de code verouderd was, of b. niet leesbaar, of c. extreem ingewikkeld voor simpele toepassingen of een combinatie van alle 3 Voordeel is wel dat de code gelijk up to date is, je niet steeds je hoeft in te lezen in de 'oude' code.
scheelt soms erg veel tijd/stress/frustraties om gewoon overnieuw te beginnen dan door te gaan op andermans werk
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Helemaal mee eens, maar helaas mag ik het niet herbouwen van mijn baas... kost te veel tijd.quote:
Voordeel is wel dat de code gelijk up to date is, je niet steeds je hoeft in te lezen in de 'oude' code.
En grootte kans dat hij het dan niet meer snapt
Beidequote:
[..]
Lezen? Of daadwerkelijk TDD gaan gebruiken?
In eerste instantie voor een eigen thuisprojectje zodat ik er vast aan kan wennen en daarna op het werk.De database is ook pure troep, maar daar gooien we gewoon een api service tegenaan.quote:
[..]
En is de database wel op orde? Als dat namelijk ook niet op orde is loop je alsnog tegen allerlei shit aan, tenzij je wat handige mappers gaat maken, maar dan moet je maar zien of dat ook performed. Overigens snap ik niet waarom bedrijven nog steeds hun eigen webshops ontwikkelen, het is duur in onderhoud, en je haalt nooit de kwaliteit die bestaande software levert.
Dus de database van het nieuwe product kan ik ook zelf opzetten.
En dat bestaande software dezelfde kwaliteit levert dat is niet helemaal waar, wij zullen sowieso functionaliteit gaan missen of welke niet volledig aan onze wensen voldoen.
En daarbij krijg je met bestaande software vaak het zelfde als wat we nu hebben; troep.
Moet je eens kijken hoeveel Magentodevelopers er gevraagd worden om van alles te herschrijven omdat Magento apenballen zuigt.quote:
[..]
Overigens snap ik niet waarom bedrijven nog steeds hun eigen webshops ontwikkelen, het is duur in onderhoud, en je haalt nooit de kwaliteit die bestaande software levert.
De grootste reden voor eigen webshopsoftware is vaak omdat ze allerlei dingen erin willen hebben die niet met plugins te regelen is en niet standaard in de shops zit, dus dan kan je bestaande code gaan hacken waarvan steeds nieuwe updates komen of een net framework pakken en vanaf daar aan de slag gaan. Bovendien hebben ze vaak al hun eigen facturatiesysteem, dus heel dat stuk heb je niet nodig.
Carpe Libertatem
En je bent nog min of meer afhankelijk van een externe partij ook. Nooit leuk.quote:Op dinsdag 6 mei 2014 18:51 schreef Boze_Appel het volgende:
[..]
Moet je eens kijken hoeveel Magentodevelopers er gevraagd worden om van alles te herschrijven omdat Magento apenballen zuigt.
De grootste reden voor eigen webshopsoftware is vaak omdat ze allerlei dingen erin willen hebben die niet met plugins te regelen is en niet standaard in de shops zit, dus dan kan je bestaande code gaan hacken waarvan steeds nieuwe updates komen of een net framework pakken en vanaf daar aan de slag gaan. Bovendien hebben ze vaak al hun eigen facturatiesysteem, dus heel dat stuk heb je niet nodig.
Je kunt toch zelf initiatief tonen als je het zo'n leuk project vind om in je eigen tijd het zelf te schrijven? en dan eventueel verkopen (of via half jaar betaald vakantie, ken een persoon die zo een lange tijd vrij was op de kosten van de baas!, betaald vakantie dus.) ? neem aan dat het idee vrij te gebruiken is?! staat dan ook zeer goed op je cvquote:
[..]
Helemaal mee eens, maar helaas mag ik het niet herbouwen van mijn baas... kost te veel tijd.
En grootte kans dat hij het dan niet meer snapt
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Mijn baas snapt ook niet wat ik doe, maakt ook niet uit, ik mag zelf bepalen waar ik aan werk. Als ik maar oplever wat er wordt gevraagd.quote:
[..]
Helemaal mee eens, maar helaas mag ik het niet herbouwen van mijn baas... kost te veel tijd.
En grootte kans dat hij het dan niet meer snapt
In n vrijetijd ben ik druk met mn eigen sites ;-)quote:
[..]
Je kunt toch zelf initiatief tonen als je het zo'n leuk project vind om in je eigen tijd het zelf te schrijven? en dan eventueel verkopen (of via half jaar betaald vakantie, ken een persoon die zo een lange tijd vrij was op de kosten van de baas!, betaald vakantie dus.) ? neem aan dat het idee vrij te gebruiken is?! staat dan ook zeer goed op je cv
Daarnaast is het en project van een klant van ons, dus zij zijn degene die betalen.
Als ik dan de hele boel herbouw en zij zeggen, nee gaat mijn baas mij echt geen half jaar vrij geven
Helaas programmeert mijn baas ook mee aan onze projecten.quote:
[..]
Mijn baas snapt ook niet wat ik doe, maakt ook niet uit, ik mag zelf bepalen waar ik aan werk. Als ik maar oplever wat er wordt gevraagd.
Iemand nog een php developer nodig rond utrecht?
En wat is je maandelijkse onderhoudsbudget als ik vragen mag?quote:
[..]
Beide
[..]
De database is ook pure troep, maar daar gooien we gewoon een api service tegenaan.
Dus de database van het nieuwe product kan ik ook zelf opzetten.
En dat bestaande software dezelfde kwaliteit levert dat is niet helemaal waar, wij zullen sowieso functionaliteit gaan missen of welke niet volledig aan onze wensen voldoen.
En daarbij krijg je met bestaande software vaak het zelfde als wat we nu hebben; troep.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Waarom je uberhaupt Magento zou gebruiken is me een raadsel, ik heb het ooit wel eens bekeken, wat een bagger zeg, alleen al de honderden zo niet duizenden files waarmee je te maken hebt.quote:
[..]
Moet je eens kijken hoeveel Magentodevelopers er gevraagd worden om van alles te herschrijven omdat Magento apenballen zuigt.
De grootste reden voor eigen webshopsoftware is vaak omdat ze allerlei dingen erin willen hebben die niet met plugins te regelen is en niet standaard in de shops zit, dus dan kan je bestaande code gaan hacken waarvan steeds nieuwe updates komen of een net framework pakken en vanaf daar aan de slag gaan. Bovendien hebben ze vaak al hun eigen facturatiesysteem, dus heel dat stuk heb je niet nodig.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Een goede webshop in een halfjaar schrijven? GL, gaat je niet lukken.quote:
[..]
Je kunt toch zelf initiatief tonen als je het zo'n leuk project vind om in je eigen tijd het zelf te schrijven? en dan eventueel verkopen (of via half jaar betaald vakantie, ken een persoon die zo een lange tijd vrij was op de kosten van de baas!, betaald vakantie dus.) ? neem aan dat het idee vrij te gebruiken is?! staat dan ook zeer goed op je cv
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
En je configfile in een .xml die alleen met een .htaccess afgeschermd is. Zit je dus op een gare (shared) server waarbij je niet alle functies van .htaccess kan gebruiken staat je config open voor heel de wereld.quote:
[..]
Waarom je uberhaupt Magento zou gebruiken is me een raadsel, ik heb het ooit wel eens bekeken, wat een bagger zeg, alleen al de honderden zo niet duizenden files waarmee je te maken hebt.
Carpe Libertatem
Ik zit me dit echt af te vragen. Geen geld hebben om webshopsoftware naar je wensen aan te passen (door middel van plugins en/of patchen en upstream gooien), maar wel geld hebben om het van scratch te bouwen. Raar.quote:
De grootste reden voor eigen webshopsoftware is vaak omdat ze allerlei dingen erin willen hebben die niet met plugins te regelen is en niet standaard in de shops zit, dus dan kan je bestaande code gaan hacken waarvan steeds nieuwe updates komen of een net framework pakken en vanaf daar aan de slag gaan. Bovendien hebben ze vaak al hun eigen facturatiesysteem, dus heel dat stuk heb je niet nodig.
Het lijkt me dat die software inmiddels best lekker is uitgekristalliseerd en je dus makkelijk met een off-the-shelf products aan de gang kan gaan.
In theory there is no difference between theory and practice. In practice there is.
Zelf ben ik wel gecharmeerd van NOP commerce, opensource (wel c#/.net).quote:
[..]
Ik zit me dit echt af te vragen. Geen geld hebben om webshopsoftware naar je wensen aan te passen (door middel van plugins en/of patchen en upstream gooien), maar wel geld hebben om het van scratch te bouwen. Raar.
Het lijkt me dat die software inmiddels best lekker is uitgekristalliseerd en je dus makkelijk met een off-the-shelf products aan de gang kan gaan.
http://www.nopcommerce.com/downloads.aspx
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Mag ik vragen waarom niet? en wat is goed? ebay? marktplaats? 1 produkt webshop? je vergelijkt gelijk peren met kruidnoten...quote:
Een goede webshop in een halfjaar schrijven? GL, gaat je niet lukken.
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
ASP / MS SQL webshop. The horror!quote:
[..]
Zelf ben ik wel gecharmeerd van NOP commerce, opensource (wel c#/.net).
http://www.nopcommerce.com/downloads.aspx
Carpe Libertatem
De webshop zelf is 2 jaar geleden opnieuw gebouwd, en qua werk wat er daarna ingestopt is niet erg veel. Programmeer werk dan.quote:
[..]
En wat is je maandelijkse onderhoudsbudget als ik vragen mag?
Dat zal misschien hooguit 10 uur per maand zijn, en dan schat ik het nog hoog in.
Het is vooral de backend van de groothandel die brak in elkaar zit.
Maar er moet een nieuwe shop gebouwd worden omdat we onze zakelijke klanten ook een webshop op maat willen leveren en zelf binnen enkele klikken product/merk specifieke webshops willen opstarten op interessante domeinnamen.
Waarna er in feite een dropshipment in de backend wordt gezet.
quote:
[..]
Een goede webshop in een halfjaar schrijven? GL, gaat je niet lukken.
Je doet alsof een webshop een heel gecompliceerd iets is, dat valt ook wel weer mee.Je hebt alleen flexibiliteit nodig om al die seo meuk handelbaar te houden op een lange termijn.
Wat snap je niet aan een goede webshop?quote:
[..]
Mag ik vragen waarom niet? en wat is goed? ebay? marktplaats? 1 produkt webshop? je vergelijkt gelijk peren met kruidnoten...
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Op 