[PHP/(My)SQL] voor dummies #110

FOK!-Schrikkelbaas woensdag 26 juni 2013 @ 11:26:28 #31

Swetsenegger

Egocentrische Narcist

quote:
Op woensdag 26 juni 2013 11:22 schreef mstx het volgende:

[ code verwijderd ]

zo simpel.

 | FOK! Schrikkelbaasch

woensdag 26 juni 2013 @ 11:30:26 #32

mstx

2x1/2 = 1/2 x 1/2

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

zoem

zoemt

Ja, een aparte counter bijhouden ipv COUNT(*) uitvoeren

woensdag 26 juni 2013 @ 12:58:48 #34

Pakspul

quote:
Op woensdag 26 juni 2013 11:59 schreef zoem het volgende:
Ja, een aparte counter bijhouden ipv COUNT(*) uitvoeren

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

mstx

2x1/2 = 1/2 x 1/2

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.

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.
👾

woensdag 26 juni 2013 @ 13:16:03 #36

KomtTijd...

Is die query zo'n performance hit dan? Volgens mij moet die vrij snel kunnen met de juiste indexes, toch?

zcflevo.nl

woensdag 26 juni 2013 @ 13:22:33 #37

mstx

2x1/2 = 1/2 x 1/2

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?

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.
👾

woensdag 26 juni 2013 @ 13:58:28 #38

KomtTijd...

heb je ook een index op comments.topic_id?

zcflevo.nl

woensdag 26 juni 2013 @ 14:39:48 #39

mstx

2x1/2 = 1/2 x 1/2

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.
👾

woensdag 26 juni 2013 @ 19:05:16 #40

papernote

Een echte.

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...

woensdag 26 juni 2013 @ 20:29:22 #41

Chandler

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...

woensdag 26 juni 2013 @ 20:55:19 #42

papernote

Een echte.

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...

woensdag 26 juni 2013 @ 21:16:29 #43

Chandler

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..

The people who lost my respect will never get a capital letter for their name again.
Like trump...

woensdag 26 juni 2013 @ 21:56:23 #44

papernote

Een echte.

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..

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...

woensdag 26 juni 2013 @ 22:00:16 #45

Chandler

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...

woensdag 26 juni 2013 @ 22:04:55 #46

papernote

Een echte.

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

zoem

zoemt

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

slacker_nl

Sicko pur sang

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?

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

Boze_Appel

Vrij Fruit

quote:
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

donderdag 27 juni 2013 @ 07:00:08 #50

Chandler

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...

donderdag 27 juni 2013 @ 07:16:29 #51

Light

quote:
Op woensdag 26 juni 2013 11:30 schreef mstx het volgende:
Ik heb zelf ook een vraagje, deze (simpele) query is soms traag:
[ code verwijderd ]

De explain zegt dit:
[ code verwijderd ]

Kan dat sneller?

Ik zou hier in Inner Join gebruiken ipv een Left Join. Je zoekt expliciet naar rijen waar TabelB.KolomY een waarde heeft, dus voegt het gebruik van een left join niets toe.

fokstok.nl

donderdag 27 juni 2013 @ 08:04:40 #52

mstx

2x1/2 = 1/2 x 1/2

quote:
Op donderdag 27 juni 2013 00:47 schreef Boze_Appel het volgende:

[..]

Indexes erbij maken op type en isactive. Daar doe je de selecties op.

Die indexes zitten er al op.

quote:
Op donderdag 27 juni 2013 07:16 schreef Light het volgende:

[..]

Ik zou hier in Inner Join gebruiken ipv een Left Join. Je zoekt expliciet naar rijen waar TabelB.KolomY een waarde heeft, dus voegt het gebruik van een left join niets toe.

Maar dan selecteert 'ie toch ook rijen uit tabel B die niet gekoppeld zijn aan een rij uit tabel A?

Nog wat dingen geprobeerd maar het probleem zit hem echt in de COUNT() i.c.m. JOIN.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

SELECT COUNT(*) FROM TabelA
= 0.0002 sec

SELECT COUNT(*) FROM TabelA LEFT JOIN TabelB.................
= 0.25 sec

SELECT COUNT(*) FROM TabelA INNER JOIN TabelB.................
= 0.4 sec

SELECT * FROM TabelA LEFT JOIN TabelB.................
= 0.001 sec

SELECT * FROM TabelA INNER JOIN TabelB.................
= 0.001 sec

SELECT * FROM TabelA
= 0.0004 sec

Ik denk dat ik maar gewoon de kolom van TabelB die ik in de WHERE gebruik kopieer naar TabelA zodat ik niet hoef te joinen.

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.
👾

donderdag 27 juni 2013 @ 08:09:55 #53

Light

quote:
Op donderdag 27 juni 2013 08:04 schreef mstx het volgende:

Maar dan selecteert 'ie toch ook rijen uit tabel B die niet gekoppeld zijn aan een rij uit tabel A?

Nee.
Bij een left join selecteer je alle rijen uit A en als er geen match in B gevonden kan worden (op basis van de ON clause) dan worden alle velden van B voor die rij gevuld met NULL.
Bij een inner join selecteer je alleen die rijen uit A waarvoor een match in B gevonden kan worden (op basis van de ON clause).

fokstok.nl

donderdag 27 juni 2013 @ 08:22:45 #54

mstx

2x1/2 = 1/2 x 1/2

Ho ik zat even niet op te letten, je hebt gelijk.

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.
👾

donderdag 27 juni 2013 @ 08:31:58 #55

slacker_nl

Sicko pur sang

quote:
Op donderdag 27 juni 2013 07:00 schreef Chandler het volgende:
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

Mijn code is altijd bugfree

In theory there is no difference between theory and practice. In practice there is.

donderdag 27 juni 2013 @ 08:33:07 #56

Cue_

Cuecumbergirl

Mensen hier ervaring/voorbeelden van een soap call naar een webservice met PL/SQL?

donderdag 27 juni 2013 @ 10:13:55 #57

Chandler

quote:
Op donderdag 27 juni 2013 08:31 schreef slacker_nl het volgende:

[..]

Mijn code is altijd bugfree

^{juist haha}

maar goed, blijkbaar doe ik iets verkeerd!? ik ga nu eens kijken hoe anderen het doen...

The people who lost my respect will never get a capital letter for their name again.
Like trump...

donderdag 27 juni 2013 @ 13:39:43 #58

mstx

2x1/2 = 1/2 x 1/2

Ik kwam net weer eens een prachtige query tegen van een oud-collega:

1
2
3
4
5
6
7
8
9
10
11
12
13

SELECT
kolommen
FROM
tabel
WHERE
id IN (
          SELECT
            id
          FROM
            tabel
          WHERE
           voorwaarde=1
         )

(het is dezelfde tabel)

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.
👾

donderdag 27 juni 2013 @ 13:41:02 #59

Chandler

Prachtig! zo leer je sub selects

The people who lost my respect will never get a capital letter for their name again.
Like trump...

donderdag 27 juni 2013 @ 16:00:42 #60

Crutch

Filantroop || Taalzwengel

Hallo! Wat vinden jullie van Symfony?

Je moeder is een hamster

Forum Opties
Forumhop:
Hop naar:	(afkorting, bv 'KLB')

» digital corner

» development

» digital corner

» development