Tja, maar volgens mij is een index apart, maar een veld toevoegen of wijzigen duurt helaas VEEL LANGER!quote:Op dinsdag 25 juni 2013 17:28 schreef KomtTijd... het volgende:
[..]
Even een index toevoegen over een kleine 3M records kost ook langer dan een kwartiertje...
Heel simpel, maar zo effectief:quote:Op dinsdag 25 juni 2013 14:06 schreef KomtTijd... het volgende:
ik denk dat ik beter de situatie (wat beter) kan omschrijven:
1) ik heb een map met scripts erin op een linux (ubuntu 12.04) server waarin ik ontwikkel (zeg /var/www/
2) ik rename de map via een SFTP-verbinding zodat dit de live versie wordt (is het idee)
3) alle calls naar dirname(__FILE__) blijven de oude mapnaam teruggeven met als gevolg hele ritsen errors van includes die niet meer gevonden kunnen worden.
4) ik rename de map weer naar zijn oorspronkelijke naam, alles gaat weer goed
5) ik maak (wederom via SFTP) een kopie van de map en rename die naar de naam die ik wil hebben, vervolgens verwijder ik de oorspronkelijke map
6) alles gaat goed, de applicatie draait succesvol op zijn nieuwe locatie.
ik heb een clearstatcache() geprobeerd maar dat hielp niet, misschien heeft het wel met het filesystem te maken?
1 2 3 4 5 | idA | idB -----+---- 3 | 15 8 | 11 136 | 3 |
1 | SELECT IF(idA=3, idB, idA) FROM tabel WHERE idA=3 OR idB=3 |
1 2 3 4 5 6 7 | SELECT COUNT(*) FROM tabelA LEFT JOIN tabelB ON tabelA.id=tabelB.id_van_tabelA WHERE tabelA.kolomX=1 AND tabelB.kolomY=1 |
1 2 3 | id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE tabelB ref PRIMARY,kolomY kolomY 1 const 123980 Using where 1 SIMPLE tabelA ref id_van_tabelA id_van_tabelA 5 database.tabelB.id,const 7 Using index |
dit performance technisch gezien de beste oplossing t.o.v. count queries. Je moet wel in de applicatie goed testen dat de tel kolom goed bij blijft, anders geef je valse waardes weer.quote:Op woensdag 26 juni 2013 11:59 schreef zoem het volgende:
Ja, een aparte counter bijhouden ipv COUNT(*) uitvoeren
Hij komt wel redelijk vaak voor in m'n slow query log.quote:Op woensdag 26 juni 2013 13:16 schreef KomtTijd... het volgende:
Is die query zo'n performance hit dan? Volgens mij moet die vrij snel kunnen met de juiste indexes, toch?
1 2 3 | # Query_time: 4.404715 Lock_time: 0.000632 Rows_sent: 1 Rows_examined: 401908 SET timestamp=1372244412; SELECT COUNT(*) AS num_comments FROM `comments` LEFT JOIN `topics` ON `topics`.`id`=`comments`.`topic_id` WHERE `comments`.`type`=1 AND `topics`.`isactive`='Y'; |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | <?php $setopt_array = array(CURLOPT_TIMEOUT => $cronjobSettings['curl_timeout'], // in seconds CURLOPT_TIMEOUT_MS => $cronjobSettings['curl_timeout'] * 1000, // in ms CURLOPT_CONNECTTIMEOUT => $cronjobSettings['curl_timeout'], // in seconds CURLOPT_CONNECTTIMEOUT_MS => $cronjobSettings['curl_timeout'] * 1000, // in ms CURLOPT_NOBODY => false, // return body CURLOPT_VERBOSE => false, // Minimize logs CURLOPT_AUTOREFERER => true, // ? CURLOPT_FAILONERROR => true, // fail connection on error! CURLOPT_RETURNTRANSFER => true, // return (get) data CURLOPT_SSL_VERIFYHOST => false, // no certificate CURLOPT_SSL_VERIFYPEER => false, // no verify! CURLOPT_POST => false, // no posting CURLOPT_FOLLOWLOCATION => true, // follow redirects CURLOPT_MAXREDIRS => 3, // max number of redirects to follow CURLOPT_DNS_USE_GLOBAL_CACHE => false, CURLOPT_DNS_CACHE_TIMEOUT => 2, /* CURLOPT_LOW_SPEED_LIMIT => 10, // in bytes CURLOPT_LOW_SPEED_TIME => $cronjobSettings['curl_timeout'], // in seconds CURLOPT_NOSIGNAL => 1, // exit if no signal is found */ ); ?> |
Het is de duur waarmee items in de DNS cache van cURL worden bewaard. Jij kiepert nu elke twee seconden je DNS cache leeg, waardoor je URLs heel vaak moet resolven. Als je vaak dezelfde host benaderd, dan is het wel handig om je cache langer gevult te laten.quote:Op woensdag 26 juni 2013 21:16 schreef Chandler het volgende:
Ik draai alles op het zelfde systeem (mijn test omgeving laptop) en heb nergens een DNS adres ingesteld whatsoever...
De timeout staat zo kort omdat deze dan toch al wel gevonden moet zijn? lijkt mij?maar zal hem eens verhogen en kijken of dat een verschil maakt..
Je wilt die DNS CACHE behouden, je zou eventueel als je echt lowlevel wilt gaan doen eerst resolven en dan pas aan CURL geven.quote:Op woensdag 26 juni 2013 20:29 schreef Chandler het volgende:
Ik loop tegen iets in CURL aan, voor vele URLS krijg ik een goede status terug van CURL maar sommige een foutmelding, deze foutmelding is vaak Could not resolve host: (nil); Host not found terwijl als ik met de browser naar deze url ga, bestaat deze wel!? en laad erg snel.
Mijn scriptje draait 25 URLS tegelijk met een timeout van 10 seconden.. Dus nu vraag ik mij af?! waar ligt dit aan? mijn opts zijn als volgt;
[ code verwijderd ]
Heeft iemand een idee waar de fout zou kunnen zitten? of is er bekend mee en weet er een work around/oplossing voor?
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |