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:Op dinsdag 29 april 2014 09:59 schreef KomtTijd... het volgende:
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:Op dinsdag 29 april 2014 09:59 schreef KomtTijd... het volgende:
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:Op maandag 28 april 2014 23:19 schreef bondage het volgende:
[..]
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?
Duidelijk.quote:Op dinsdag 29 april 2014 21:27 schreef Light het volgende:
[..]
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 krijgenMySQL 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.
quote:Op woensdag 30 april 2014 15:01 schreef slacker_nl het volgende:
Omdat ik soms zo loop te miepen over tests:
[ afbeelding ]
100% code coverage! (dit laat Devel::Cover zien en aangezien er weinig perl mensjes zijn ging ik de PHP mensjes spammenquote:
Ziet er wel leuk uit, die statistiekenquote:Op woensdag 30 april 2014 17:53 schreef slacker_nl het volgende:
[..]
100% code coverage! (dit laat Devel::Cover zien en aangezien er weinig perl mensjes zijn ging ik de PHP mensjes spammen)
Dat is 000-package.t, daarin worden de volgende zaken getest:quote:Op woensdag 30 april 2014 18:42 schreef Light het volgende:
[..]
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.
Dan snap ik wel dat die tests ook lang duren (in ieder geval in verhouding).quote:Op woensdag 30 april 2014 20:59 schreef slacker_nl het volgende:
[..]
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.
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; |
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:Op woensdag 30 april 2014 22:15 schreef bondage het volgende:
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:Op woensdag 30 april 2014 22:35 schreef Light het volgende:
[..]
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 kan me niet voorstellen dat dat helpt, omdat de juiste index al wordt gebruikt.quote:Op woensdag 30 april 2014 22:36 schreef bondage het volgende:
[..]
Jup, ik snap er ook niets vanIk ga voor de zekerheid toch ff FORCE INDEX proberen.
Zou een gecombineerde index op topic_id en auteur misschien een optie zijn?quote:Op woensdag 30 april 2014 22:37 schreef Light het volgende:
[..]
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:Op woensdag 30 april 2014 23:15 schreef bondage het volgende:
[..]
Zou een gecombineerde index op topic_id en auteur misschien een optie zijn?
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?
Krijg binnenkort de kans om een gehele shop vanaf scrap op te zetten, waarbij de oude database slechts als api wordt gebruikt.quote:Op maandag 5 mei 2014 22:09 schreef Juicyhil het volgende:
[..]
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.
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:Op maandag 5 mei 2014 22:17 schreef TwenteFC het volgende:
[..]
Krijg binnenkort de kans om een gehele shop vanaf scrap op te zetten, waarbij de oude database slechts als api wordt gebruikt.
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).
Hier net zo, een klein bedrijf waar we eigenlijk meer misbruikt worden als helpdesk dan dat we daadwerkelijke nieuwe webapplicaties opzetten.quote:Op maandag 5 mei 2014 22:23 schreef Juicyhil het volgende:
[..]
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.
Ik voel je. Dat heb ik ook vaker meegemaakt. Met alle drama zoals security issues en jankende klanten eromheen. Maar dat is nu voorbijquote:Op maandag 5 mei 2014 22:27 schreef TwenteFC het volgende:
Wat dus soms ook een ramp is, omdat de code een ramp is. Oorspronkelijk gemaakt door een 16 jarige als bijbaantje 10 jaar geleden.
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:Op vrijdag 2 mei 2014 21:50 schreef Light het volgende:
[..]
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:Op maandag 5 mei 2014 22:27 schreef TwenteFC het volgende:
Wat dus soms ook een ramp is, omdat de code een ramp is. Oorspronkelijk gemaakt door een 16 jarige als bijbaantje 10 jaar geleden.
Lezen? Of daadwerkelijk TDD gaan gebruiken?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?
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:Op maandag 5 mei 2014 22:17 schreef TwenteFC het volgende:
[..]
Krijg binnenkort de kans om een gehele shop vanaf scrap op te zetten, waarbij de oude database slechts als api wordt gebruikt.
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).
Helemaal mee eens, maar helaas mag ik het niet herbouwen van mijn baas... kost te veel tijd.quote:Op dinsdag 6 mei 2014 11:44 schreef Chandler het volgende:
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
Beidequote:Op dinsdag 6 mei 2014 09:02 schreef slacker_nl het volgende:
[..]
Lezen? Of daadwerkelijk TDD gaan gebruiken?
De database is ook pure troep, maar daar gooien we gewoon een api service tegenaan.quote:Op dinsdag 6 mei 2014 11:21 schreef raptorix het volgende:
[..]
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.
Moet je eens kijken hoeveel Magentodevelopers er gevraagd worden om van alles te herschrijven omdat Magento apenballen zuigt.quote:Op dinsdag 6 mei 2014 11:21 schreef raptorix het volgende:
[..]
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.
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:Op dinsdag 6 mei 2014 12:03 schreef Darkomen het volgende:
[..]
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
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:Op dinsdag 6 mei 2014 12:03 schreef Darkomen het volgende:
[..]
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:Op dinsdag 6 mei 2014 22:42 schreef Chandler het volgende:
[..]
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
Helaas programmeert mijn baas ook mee aan onze projecten.quote:Op dinsdag 6 mei 2014 22:46 schreef bondage het volgende:
[..]
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.
En wat is je maandelijkse onderhoudsbudget als ik vragen mag?quote:Op dinsdag 6 mei 2014 18:09 schreef TwenteFC het volgende:
[..]
BeideIn 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.
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.
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: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.
Een goede webshop in een halfjaar schrijven? GL, gaat je niet lukken.quote:Op dinsdag 6 mei 2014 22:42 schreef Chandler het volgende:
[..]
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
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:Op woensdag 7 mei 2014 10:58 schreef raptorix het volgende:
[..]
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.
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:Op dinsdag 6 mei 2014 18:51 schreef Boze_Appel het volgende:
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.
Zelf ben ik wel gecharmeerd van NOP commerce, opensource (wel c#/.net).quote:Op woensdag 7 mei 2014 11:32 schreef slacker_nl het volgende:
[..]
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.
Mag ik vragen waarom niet? en wat is goed? ebay? marktplaats? 1 produkt webshop? je vergelijkt gelijk peren met kruidnoten...quote:Op woensdag 7 mei 2014 10:59 schreef raptorix het volgende:
Een goede webshop in een halfjaar schrijven? GL, gaat je niet lukken.
ASP / MS SQL webshop. The horror!quote:Op woensdag 7 mei 2014 13:51 schreef raptorix het volgende:
[..]
Zelf ben ik wel gecharmeerd van NOP commerce, opensource (wel c#/.net).
http://www.nopcommerce.com/downloads.aspx
De webshop zelf is 2 jaar geleden opnieuw gebouwd, en qua werk wat er daarna ingestopt is niet erg veel. Programmeer werk dan.quote:Op woensdag 7 mei 2014 10:57 schreef raptorix het volgende:
[..]
En wat is je maandelijkse onderhoudsbudget als ik vragen mag?
quote:Op woensdag 7 mei 2014 10:59 schreef raptorix het volgende:
[..]
Een goede webshop in een halfjaar schrijven? GL, gaat je niet lukken.
Wat snap je niet aan een goede webshop?quote:Op woensdag 7 mei 2014 17:12 schreef Chandler het volgende:
[..]
Mag ik vragen waarom niet? en wat is goed? ebay? marktplaats? 1 produkt webshop? je vergelijkt gelijk peren met kruidnoten...
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |