abonnement Unibet Coolblue Bitvavo
pi_128245815
quote:
14s.gif 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...
Tja, maar volgens mij is een index apart, maar een veld toevoegen of wijzigen duurt helaas VEEL LANGER! :( maar er is een oplossing, export, aanpassen import (zonder tables aan te maken)
The people who lost my respect will never get a capital letter for their name again.
Like trump...
  dinsdag 25 juni 2013 @ 18:25:51 #27
187069 slacker_nl
Sicko pur sang
pi_128246839
quote:
14s.gif 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?
Heel simpel, maar zo effectief:

Symlink: /var/www/ditisdelivecode

Je hebt je dir:

/var/www/versie1.2
/var/www/versie1.3

Je doet:

rm /var/www/ditisdelivecode
ln -s /var/www/versie1.3 /var/www/ditisdelivecode

Tada, fixed.

Terug gaan?
rm /var/www/ditisdelivecode
ln -s /var/www/versie1.2 /var/www/ditisdelivecode


En eigenlijk moet je gewoon het oude weggooien, je hebt toch alles in version control staan.
In theory there is no difference between theory and practice. In practice there is.
pi_128247476
Versiebeheer, ja dat moeten we nog altijd eens implementeren. 't is een offline omgeving, dat maakt het niet makkelijker.
Maar er worden wel dagelijks (off-site) backups gemaakt dus oude zooi flikker ik inderdaad gewoon weg.

Een symlink maken is ook wel een goed idee. Niet aan gedacht :)
  FOK!-Schrikkelbaas woensdag 26 juni 2013 @ 11:18:19 #29
1972 Swetsenegger
Egocentrische Narcist
pi_128272611
Mogguh,

Ik heb een klein SQL vraagje. Waarschijnlijk heel simpel op te lossen maar ik kan het niet verzinnen.

stel ik heb de volgende tabel

1
2
3
4
5
idA  | idB
-----+----
3    | 15
8    | 11
136  | 3

Nu wil ik alle rijen selecteren waar idA danwel B een 3 bevat, maar dan wil ik alleen de value terug die géén 3 is, in dit voorbeeld krijg ik dus 15 en 136 terug.

Hoe doe ik dat?
  woensdag 26 juni 2013 @ 11:22:48 #30
91039 mstx
2x1/2 = 1/2 x 1/2
pi_128272767
1SELECT IF(idA=3, idB, idA) FROM tabel WHERE idA=3 OR idB=3
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.
👾
  FOK!-Schrikkelbaas woensdag 26 juni 2013 @ 11:26:28 #31
1972 Swetsenegger
Egocentrische Narcist
pi_128272887
quote:
0s.gif Op woensdag 26 juni 2013 11:22 schreef mstx het volgende:

[ code verwijderd ]

_O_ zo simpel.
  woensdag 26 juni 2013 @ 11:30:26 #32
91039 mstx
2x1/2 = 1/2 x 1/2
pi_128273040
Ik heb zelf ook een vraagje, deze (simpele) query is soms traag:

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

De explain zegt dit:
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
Kan dat sneller?
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.
👾
  Moderator / Redactie Sport / Devops woensdag 26 juni 2013 @ 11:59:49 #33
176766 zoem
zoemt
pi_128274123
Ja, een aparte counter bijhouden ipv COUNT(*) uitvoeren :P
pi_128276222
quote:
0s.gif Op woensdag 26 juni 2013 11:59 schreef zoem het volgende:
Ja, een aparte counter bijhouden ipv COUNT(*) uitvoeren :P
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.
  woensdag 26 juni 2013 @ 13:11:35 #35
91039 mstx
2x1/2 = 1/2 x 1/2
pi_128276662
Zou kunnen, het gaat om het tellen van bijvoorbeeld het aantal berichten in een forum topic, waarvan het topic niet verwijderd is en het bericht ook aan een voorwaarde moet voldoen. Dan zou ik inderdaad het aantal berichten per topic kunnen bijhouden, maar als je dan bijvoorbeeld het aantal berichten per user of het aantal berichten in een bepaald subforum wil tellen moet je alsnog een count + join doen, of dat ook allemaal apart weer bijhouden en bij het plaatsen/verwijderen van een bericht al die tellers weer updaten, lijkt me een beetje omslachtig. :P
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.
👾
pi_128276836
Is die query zo'n performance hit dan? Volgens mij moet die vrij snel kunnen met de juiste indexes, toch?
  woensdag 26 juni 2013 @ 13:22:33 #37
91039 mstx
2x1/2 = 1/2 x 1/2
pi_128277079
quote:
14s.gif 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?
Hij komt wel redelijk vaak voor in m'n slow query log. :')

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';
Op comments.type en topics.isactive zit een index.

Het zal wel fout gaan bij "Rows_examined: 401908" maar geen idee hoe ik dat precies kan verbeteren.
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.
👾
pi_128278823
heb je ook een index op comments.topic_id?
  woensdag 26 juni 2013 @ 14:39:48 #39
91039 mstx
2x1/2 = 1/2 x 1/2
pi_128280472
Yes.
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.
👾
pi_128290560
Laat eens een EXPLAIN zien.

-edit: laat maar, die staat er boven :')

Is het datatype van isActive een bool? Misschien kun je nog een USE INDEX toevoegen, omdat hij bij de eerste SELECT kiest voor kolomY en niet voor PRIMARY?

[ Bericht 45% gewijzigd door papernote op 26-06-2013 19:10:56 ]
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
pi_128293936
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;

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
*/
                     
);
?>

Heeft iemand een idee waar de fout zou kunnen zitten? of is er bekend mee en weet er een work around/oplossing voor?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_128295163
Waarom staat je CURLOPT_DNS_CACHE_TIMEOUT zo kort? En draait je script op dezelfde computer als je browser? Zoeken ze de host op via dezelfde DNS server?
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
pi_128296332
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? :D maar zal hem eens verhogen en kijken of dat een verschil maakt..
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_128298826
quote:
0s.gif 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? :D maar zal hem eens verhogen en kijken of dat een verschil maakt..
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.

Het is dus géén timeout die bepaalt hoe lang cURL staat te wachten op een request.
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
pi_128299050
Het voorbeeld is dat ook niet helemaal juist, want zowel met deze opties als zonder (of op welke waarde dan ook) blijven de fouten zich voordoen. Ik had deze DNS opties als test toegevoegd, maar zonder resultaat....

Dus snap ik nog steeds niet (lijkt mij dus dat DNS van de brouwser het zelfde is als die php gebruikt) waarom hij ze niet pakt? beetje vervelend...
The people who lost my respect will never get a capital letter for their name again.
Like trump...
pi_128299337
Doe de URLs eens stuk-voor-stuk en kijk bij welke hij vastloopt.
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
  Moderator / Redactie Sport / Devops woensdag 26 juni 2013 @ 22:23:09 #47
176766 zoem
zoemt
pi_128300570
Alleen de curl opts zegt niet zo heel veel; het kan ook op een ander punt fout gaan (wat ik vermoed). Wat voer je verder nog uit met curl?
  woensdag 26 juni 2013 @ 23:54:41 #48
187069 slacker_nl
Sicko pur sang
pi_128305582
quote:
0s.gif 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?
Je wilt die DNS CACHE behouden, je zou eventueel als je echt lowlevel wilt gaan doen eerst resolven en dan pas aan CURL geven.

http://www.php.net/manual/en/function.dns-get-record.php

En dan wil je op A, CNAME en AAAA records zoeken en CNAME's moet je weer doorresolven tot je uitkomt op een A/AAAA record.

Of deze: http://www.php.net/manual/en/function.checkdnsrr.php
In theory there is no difference between theory and practice. In practice there is.
  † In Memoriam † donderdag 27 juni 2013 @ 00:47:33 #49
159335 Boze_Appel
Vrij Fruit
pi_128307402
quote:
0s.gif Op woensdag 26 juni 2013 14:39 schreef mstx het volgende:
Yes.
Indexes erbij maken op type en isactive. Daar doe je de selecties op.
Carpe Libertatem
pi_128309712
Ik voer verder niets specifieks uit met curl, ik gebruik dezelfde opzet als die eerder door Slacker_nl is gegeven (DIG / [PHP/(My)SQL] voor dummies #109)

En het uitlezen van de DNS per URL zou een mogelijkheid zijn, al zou CURL deze url natuurlijk ook gewoon moeten kunnen vinden :{
The people who lost my respect will never get a capital letter for their name again.
Like trump...
abonnement Unibet Coolblue Bitvavo
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')