abonnement Unibet Coolblue
pi_124756137
Iemand enig idee hoe ik deze pagina's van waypoint kan screenscrapen?
Ik krijg niet de juiste data terug:(
https://app.halowaypoint.(...)tch-b5bae280fab08275

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
$url = 'https://app.halowaypoint.com/en-us/Halo4/Ninja%20pgl/wargames/match-b5bae280fab08275';
$agent= $_SERVER['HTTP_USER_AGENT'] ;

$ch = curl_init();
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_VERBOSE, true);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_USERAGENT, $agent);
curl_setopt($ch, CURLOPT_URL,$url);
$result=curl_exec($ch);
echo '<xmp>'.$result.'</xmp>';

?>
Klein test scriptje
pi_124757875
Wat krijg je dan terug? En wat verwacht je terug te krijgen? Log je wel eerst in?
Tegenwoordig moet je Dr. Ir. zijn om een beetje correct Nederlands te kunnen neerpleuren.
Abusing semicolons since 1987.
  maandag 1 april 2013 @ 16:07:58 #253
84926 WyriHaximus
Release the hounds smithers!
pi_124758760
quote:
0s.gif Op maandag 1 april 2013 15:34 schreef rekenwonder het volgende:
Wat krijg je dan terug? En wat verwacht je terug te krijgen? Log je wel eerst in?
Idd word gelijk door geredirect naar een login. @Darkomen ff wat meer werk in stoppen door o.a. een cookie jar te gebruiken of zoiets als selenium of phantomjs te gebruiken.
phluphy for president!
pi_124763491
Nog wel een tip als je beter het proces beter wil volgen:
1
2
curl_setopt($ch, CURLOPT_STDERR, fopen('php://output', 'w+'));
curl_setopt($ch, CURLOPT_VERBOSE, true);
Ook nuttig in dit geval:
1curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
En waar ^^ al op hintte: gebruik CURLOPT_COOKIEJAR.
Tegenwoordig moet je Dr. Ir. zijn om een beetje correct Nederlands te kunnen neerpleuren.
Abusing semicolons since 1987.
pi_124765050
quote:
0s.gif Op maandag 1 april 2013 15:34 schreef rekenwonder het volgende:
Wat krijg je dan terug? En wat verwacht je terug te krijgen? Log je wel eerst in?
Een stat pagina.
Was idd de login vergeten.

En bedankt, ga maar eens met de nieuwe suggesties aan de slag
pi_124765542
Iemand een idee hoe ik deze query beter kan schrijven?

1
2
3
4
5
6
7
SELECT `plaatjes`.*
FROM `plaatjes`
LEFT JOIN `views` ON `views`.`category` = `plaatjes`.`category`
WHERE YEAR(`views`.`date`) = YEAR(CURRENT_DATE - INTERVAL 1 MONTH)
AND MONTH(`views`.`date`) = MONTH(CURRENT_DATE - INTERVAL 1 MONTH)
GROUP BY `views`.`category`, `plaatjes`.`category`
ORDER BY `views`.`date` DESC

structuur en indexes
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
CREATE TABLE IF NOT EXISTS `plaatjes` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `category` varchar(32) CHARACTER SET latin1 NOT NULL,
  `filetype` tinyint(3) unsigned NOT NULL,
  `filename` varchar(40) CHARACTER SET latin1 NOT NULL,
  `filesize` int(10) unsigned NOT NULL,
  `height` int(10) unsigned NOT NULL,
  `width` int(10) unsigned NOT NULL,
  `animated` enum('j','n') CHARACTER SET latin1 NOT NULL DEFAULT 'n',
  `views` int(10) unsigned NOT NULL,
  `lastview` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `category` (`category`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=DYNAMIC AUTO_INCREMENT=28350 ;

-- --------------------------------------------------------

CREATE TABLE IF NOT EXISTS `views` (
  `category` varchar(32) NOT NULL,
  `date` date NOT NULL,
  `tstamp` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE CURRENT_TIMESTAMP,
  `views` int(10) unsigned NOT NULL,
  `thumbs` int(10) unsigned NOT NULL,
  `searches` int(10) unsigned NOT NULL,
  UNIQUE KEY `category` (`category`,`date`),
  KEY `date` (`date`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

maar deze gebruikt filesort, iets wat ik graag wil voorkomen aangezien dat nogal in de snelheid beperkt.

1
2
1,SIMPLE,views,index,category,category,37,NULL,35317,Using where; Using index; Using temporary; Using f...
1,SIMPLE,plaatjes,ref,category,category,34,nvt****_anipl.views.category,17

Iemand een idee?
Just say hi!
pi_124808135
Wat probeer je precies te bereiken met je query?
pi_124838601
Het ligt wat ingewikkelder dan ik dacht.

Ik heb eerst een token nodig van M$ Live via "Connect Live OAuth 2.0"
Alleen kan ik daar voor php en connect live weinig over vinden.
Wel voor google.

Heeft iemand van jullie daar ervaring mee? php +connect live OAuth 2.0?

Daarmee moet ik weer een token van halowaypoint ophalen, daar is genoeg over gedocumenteerd op http://api.auntiedot.net
Als ik die beide heb dan kan ik de gewenste json data ophalen en verwerken.
pi_124839733
quote:
0s.gif Op dinsdag 2 april 2013 20:56 schreef Light het volgende:
Wat probeer je precies te bereiken met je query?
Ik sla dagelijks views op basis van de categorieėn. In deze views sla ik de datum, timestamp, categorie naam, aantal thumb views, image views en zoek opdrachten op. Deze wil ik gebruiken in combinatie met het plaatjes tabel. Eerst wil ik bv de beste categorieen van de laatste dag/maand opvragen en daarbij wil ik het plaatjes tabel gebruiken om een plaatje (liefst, het best bekeken plaatje) uit te kunnen lezen.

Nu kreeg ik via een ander forum de volgende query voorgesteld, maar deze werkt ook niet snel, denk er nu aan om deze query te splitsen in 2 queries zodat ik deze sneller kan laten draaien (denk ik).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELECT plaatjes.*
FROM (
  SELECT MAX(plaatjes.id) AS id, plaatjes.category, a.date_viewed
  FROM (
    SELECT category, MAX(date) AS date_viewed
    FROM views
    WHERE date BETWEEN date_sub(CURDATE(), INTERVAL '1' month) and CURDATE()
    GROUP BY category
  ) a
  LEFT JOIN plaatjes ON a.category = plaatjes.category
  GROUP BY plaatjes.category, a.date_viewed
) b
LEFT JOIN plaatjes ON b.id = plaatjes.id
ORDER BY b.date_viewed DESC
LIMIT 5 

Alleen lijkt deze wat complex, snap er zelf de helft maar van :P en is wel een stuk sneller (van 10 seconden naar 1-2 seconden).

Iemand een idee?
Just say hi!
pi_124852956
Ik heb een testje gedaan, en wat blijkt 2 queries zijn sneller ;)

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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
<?php

function microtime_float()
{
    list($usec, $sec) = explode(" ", microtime());
    return ((float)$usec + (float)$sec);
}

function getRecordsByDate(&$db, $search = '1 DAY')
{
    $sql = "SELECT SQL_NO_CACHE category, MAX(date) AS date_viewed
            FROM views
            WHERE date BETWEEN date_sub(CURDATE(), INTERVAL " . $search . ") and CURDATE()
            AND `category` != ''
            GROUP BY category
            LIMIT 5";
    $db->q($sql);
    if ($db->rows() > 0)
    {
        $l = array();
        foreach ($db->fetch() AS $k=>$v)
        {
            $l[$v['category']] = $v['date_viewed'];
        }
        
        if (count($l) > 0)
        {
            $sql = "SELECT `plaatjes`.*
                    FROM `plaatjes`
                    WHERE `category` IN ('" . implode("','", array_keys($l)) . "')
                    GROUP BY `plaatjes`.`category`
                    ORDER BY `plaatjes`.`views` DESC";
            $db->q($sql);
            
            return $db->fetch();
        }
    }
    return array();
}

function getRecordsByDateOld(&$db, $search = '1 DAY')
{
    $sql = 'SELECT SQL_NO_CACHE plaatjes.*
            FROM (
                  SELECT MAX(plaatjes.id) AS id, plaatjes.category, a.date_viewed
                  FROM (
                        SELECT category, MAX(date) AS date_viewed
                        FROM views
                        WHERE date BETWEEN date_sub(CURDATE(), INTERVAL '  . $search . ') and CURDATE()
                        AND `category` != \'\'
                        GROUP BY category
                       ) a
                  LEFT JOIN plaatjes ON a.category = plaatjes.category
                  GROUP BY plaatjes.category, a.date_viewed
                ) b
            LEFT JOIN plaatjes ON b.id = plaatjes.id
            ORDER BY b.date_viewed DESC
            LIMIT 5';
    
    $db->q($sql);
    if ($db->rows() > 0)
    {
        return $db->fetch();
    }
    else
    {
        return array();
    }
}

echo '1 day old function<br />';
$time_start = microtime_float();
for ($x = 0; $x < 100; $x++)
{
    getRecordsByDateOld($db, '1 DAY');
}
echo round(microtime_float() - $time_start, 2) . " secs<br />";

echo '1 day new function<br />';
$time_start = microtime_float();
for ($x = 0; $x < 100; $x++)
{
    getRecordsByDate($db, '1 DAY');
}
echo round(microtime_float() - $time_start, 2) . " secs<br />";

echo '1 month old function<br />';
$time_start = microtime_float();
for ($x = 0; $x < 100; $x++)
{
    getRecordsByDateOld($db, '1 MONTH');
}
echo round(microtime_float() - $time_start, 2) . " secs<br />";
echo '1 month new function<br />';
$time_start = microtime_float();
for ($x = 0; $x < 100; $x++)
{
    getRecordsByDate($db, '1 MONTH');
}
echo round(microtime_float() - $time_start, 2) . " secs<br />";

uitkomst:
1
2
3
4
5
6
7
8
1 day old function
4.63 secs
1 day new function
4.51 secs
1 month old function
33.67 secs
1 month new function
0.19 secs

met name de maand functie is extreem snel.. waarom? geen idee... nu eens ff online testen.

Online versie vertelt nog een mooier verhaal.

1
2
3
4
5
6
7
8
1 day old function
55.34 secs
1 day new function
0.19 secs
1 month old function
79.06 secs
1 month new function
0.19 secs

In mijn lokale versie zijn er nog geen statistieken van 'vandaag' / 'gisteren' online wel.. Toch raar want vele mensen zeggen dat 1 query altijd sneller is dan 2........

[ Bericht 0% gewijzigd door Chandler op 03-04-2013 21:32:06 ]
Just say hi!
pi_124853300
Voer eens tien duizend je functie uit en kijk dan eens naar het gemiddelde.
pi_124853410
why 10.000? dan is mijn systeem nog wel ff bezig...
Just say hi!
pi_124853734
quote:
0s.gif Op woensdag 3 april 2013 21:28 schreef Chandler het volgende:
why 10.000? dan is mijn systeem nog wel ff bezig...
Omdat je dan pas betrouwbare statistieken hebt ;) Eén keer een query uitvoeren zegt nog heel weinig over de gemiddelde tijd.
------___------ 53
----.(___).---- 42
---(o\_!_/o)---
pi_124853833
quote:
0s.gif Op woensdag 3 april 2013 21:28 schreef Chandler het volgende:
why 10.000? dan is mijn systeem nog wel ff bezig...

http://en.wikipedia.org/wiki/Central_limit_theorem

Daarom :P
pi_124854658
Goed goed goed, eerst maar eens 1.000 keer! *) zal mijn laptop CPU leuk vinden! :P
quote:
0s.gif Op woensdag 3 april 2013 21:33 schreef Rockfire het volgende:
Omdat je dan pas betrouwbare statistieken hebt ;) Eén keer een query uitvoeren zegt nog heel weinig over de gemiddelde tijd.
100 keer vond ik anders toch aardig wat, zijn dus in totaal 400 queries geweest

[ Bericht 56% gewijzigd door Chandler op 03-04-2013 23:26:02 ]
Just say hi!
pi_124858771
quote:
0s.gif Op woensdag 3 april 2013 21:21 schreef Chandler het volgende:
Ik heb een testje gedaan, en wat blijkt 2 queries zijn sneller ;)
[ code verwijderd ]

uitkomst:
[ code verwijderd ]

met name de maand functie is extreem snel.. waarom? geen idee... nu eens ff online testen.

Online versie vertelt nog een mooier verhaal.
[ code verwijderd ]

In mijn lokale versie zijn er nog geen statistieken van 'vandaag' / 'gisteren' online wel.. Toch raar want vele mensen zeggen dat 1 query altijd sneller is dan 2........
Ik vind 0.19 seconden niet bijzonder snel maar die andere functies wel erg traag. Volgens mij mis je her en der wat indexen.
pi_124860416
De indexen kun je inzien in posts hierboven, daar moet volgens mij weinig mis mee zijn.

0.19 voor 100x deze query uitvoeren? oftewel 0.0019? best snel toch?

-edit-
laptop crasht tot 2x toe bij 1.000 queries per test (dus in totaal 4.000 queries) processor kan het allemaal niet aan en wordt te heet..
Just say hi!
pi_124861126
Dat getRecordsByDateOld VEEL langzamer is, is niet gek want je sorteert daar op een virtuele column die het resultaat is van een aggregation in een subquery. Hij kan daar dus nooit een index op toepassen. Sowieso geven de query's ook geen identieke resultaten waardoor je nooit eerlijk kan vergelijken.
pi_124863080
quote:
0s.gif Op woensdag 3 april 2013 21:21 schreef Chandler het volgende:
Ik heb een testje gedaan, en wat blijkt 2 queries zijn sneller ;)

Toch raar want vele mensen zeggen dat 1 query altijd sneller is dan 2........
Vele mensen zeggen dat je nooit vooraf moet optimaliseren om datsoort (veelal verkeerde) aannames te voorkomen.
pi_124867347
quote:
0s.gif Op woensdag 3 april 2013 23:37 schreef StM het volgende:
Dat getRecordsByDateOld VEEL langzamer is, is niet gek want je sorteert daar op een virtuele column die het resultaat is van een aggregation in een subquery. Hij kan daar dus nooit een index op toepassen. Sowieso geven de query's ook geen identieke resultaten waardoor je nooit eerlijk kan vergelijken.
Juist, maar dit was een oplossing voor de vorige query zie code (verbetering van 10 seconden naar 1,5)

1
2
3
4
5
6
7
SELECT `plaatjes`.*
FROM `plaatjes`
LEFT JOIN `views` ON `views`.`category` = `plaatjes`.`category`
WHERE YEAR(`views`.`date`) = YEAR(CURRENT_DATE - INTERVAL 1 MONTH)
AND MONTH(`views`.`date`) = MONTH(CURRENT_DATE - INTERVAL 1 MONTH)
GROUP BY `views`.`category`, `plaatjes`.`category`
ORDER BY `views`.`date` DESC

Het heeft gezorgd voor een versnelling maar ook niet veel zeg maar, bovenstaande query zou goed moeten werken aangezien de indexes goed staan maar werkt toch met een filesort :{ en de 2 losse queries zijn vele malen sneller dus! :)

quote:
1s.gif Op donderdag 4 april 2013 00:47 schreef KomtTijd... het volgende:
Vele mensen zeggen dat je nooit vooraf moet optimaliseren om datsoort (veelal verkeerde) aannames te voorkomen.
Correct, maar in sommige gevallen is het juist wel handig anders kun je heel veel werk dubbel / over gaan doen...
Just say hi!
pi_124873350
quote:
0s.gif Op donderdag 4 april 2013 10:19 schreef Chandler het volgende:

[..]

Juist, maar dit was een oplossing voor de vorige query zie code (verbetering van 10 seconden naar 1,5)
[ code verwijderd ]

Het heeft gezorgd voor een versnelling maar ook niet veel zeg maar, bovenstaande query zou goed moeten werken aangezien de indexes goed staan maar werkt toch met een filesort :{ en de 2 losse queries zijn vele malen sneller dus! :)

[..]

Correct, maar in sommige gevallen is het juist wel handig anders kun je heel veel werk dubbel / over gaan doen...
Waar is de filesort op? Zou je een volledige explain hier willen plaatsen? (Of heb ik die gemist...)
pi_124884664
1
2
1,SIMPLE,views,index,category,category,37,NULL,35317,Using where; Using index; Using temporary; Using f...
1,SIMPLE,plaatjes,ref,category,category,34,nvt****_anipl.views.category,17

Die had je idd gemist :)
Just say hi!
pi_124892627
Ik krijg met wat testdata die explain er niet uit... Maar het kan dat ik te weinig heb waardoor de queryplanner andere beslissingen maakt. En zet volledige teksten eens aan ;)

Wil je trouwens nog verder er op in gaan of is het nu snel genoeg?
pi_124893957
StM op zich is het nu snel genoeg, zeker nu ik het gewoon dagelijks cache ;) scheelt ook queries die toch de hele dag het zelfde zijn... Maar zou graag willen weten waarom een gecombineerde query zoveel slomer is terwijl dat eigenlijk niet zo zou moeten zijn.

Mocht je meer testdata willen hebben dan kan ik tzt wel een dump online zetten :@
Just say hi!
pi_124902766
verkeerde topic

[ Bericht 89% gewijzigd door KomtTijd... op 05-04-2013 01:57:53 ]
abonnement Unibet Coolblue
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')