Schrift
Start · Board · Anwendungen/Programme/Skripte in Perl · Fragen zu Perl-Modulen
[thread]11723[/thread]

Web::Scraper unendlich langsam (?)

Leser: 1


<< >> 4 Einträge, 1 Seite
DanielH
 2008-04-29 17:17
#109003 #109003
User since
2007-11-15
54 Artikel
BenutzerIn
[default_avatar]
Hallo,

gestern hab ich mir mal das Modul Web::Scraper* angesehen.
An sich ist die Art Daten zu extrahieren extrem geil.

( * http://search.cpan.org/~miyagawa/Web-Scraper-0.24/... )

Genau so extrem ist allerdings auch die Geschwindigkeit (im negativen Sinn).

Ich hab ein Benchmark laufen gelassen, bei dem ich Regex gegen Web::Scraper mit CSS Selektion und XPath getestet habe.

Laut meinem Test braucht Web::Scraper ca. 120 wallclock Sekunden um die Links aus einem Google-Suchergebniss 1000 mal zu filtern. Die Regex-Variante braucht ca. 120 wallclock Sekunden für 10_000_000 Filterungen.


Jetzt hab ich ein paar Fragen dazu:

1. Hab ich irgendwas falsch gemacht, oder ist XPath echt so langsam (weiter unten poste ich mein benchmark script)
2. Gibt es eventuell ein XPath Module, das in C implementiert ist? Ich konnte leider nichts finden. <edit> ich hab jetzt XML::LibXML gedunden, was ein Interface für libxml2 ist, mit welchem man auch XPath zum parsen von HTML verwenden kann. Andere Module, die C libs verwenden interessieren mich aber trotzdem noch </edit>
3. Für Spider, die viele requests machen, ist Web::Scraper doch schon fast nicht zu gebrauchen, wegen der Langsamkeit (?). Ich will mir z. B. einen Bot bauen, der ebay nach bestimmten Kriterien durchforstet. Ich hab ausgerechnet, dass ich alleine für das parsen von 50.000 Seiten mindestens 92 Minuten brauchen würde (mit Regex in paar Sekunden). Was sagt ihr dazu; würdet ihr Regex oder doch Web::Scraper verwenden?


Das benchmark Ergebniss:

Benchmark:
timing 1000 iterations of
Regex, WebScraper - XPath, WebScraper - css
...

Regex: 0 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU) @ 100000.00/s (n=1000)

(warning: too few iterations for a reliable count)

WebScraper - XPath: 111 wallclock secs (110.18 usr + 0.01 sys = 110.19 CPU) @ 9.08/s (n=1000)

WebScraper - css: 114 wallclock secs (113.16 usr + 0.00 sys = 113.16 CPU) @ 8.84/s (n=1000)


Das benchmark script:

Code (perl): (dl )
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

#!/usr/bin/perl

use strict;
use warnings;

use Benchmark::Forking qw( timethis timethese cmpthese );
use Web::Scraper;

$| = 1;
$\ = "\n";

# hier fehlt der HTML-Code von einem Google-Suchergebniss,
# den ich entfernen musste, weil er über 25000 Zeichen lang war 
# pro Post sind ja nur maximal 10000 Zeichen erlaubt
# (" und @ muss im HTML-Code entsprechend ersetzt werden)

my $resp_body = "";



timethese(1000, {
        'Regex' => sub {

                my @URLs = $resp_body =~ /<h2 class=r><a href="(.*?)" class=l>/g;       
        },
        'WebScraper - css' => sub {

                my $google = scraper{

                        process 'a.l' => 'Links[]' => '@href'
                };

                my $res = $google->scrape( \$resp_body );
        },
        'WebScraper - XPath' => sub {

                my $google = scraper{

                        process '//a[@class="l"]' => 'Links[]' => '@href'
                };

                my $res = $google->scrape( \$resp_body );
        },
});



edit: in der Überschrift hätte ich wohlbesser "Thema: Web::Scraper / XPath unendlich langsam (?)" wählen sollen...
renee
 2008-04-29 18:30
#109005 #109005
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Reguläre Ausdrücke sind mit Sicherheit schneller, dafür hast Du unter Umständen einen Wartungsintensiven Code. Was wenn Google aus class=l mal class="l" macht? Dann läuft mit Regex erstmal nix, mit Web::Scraper bist Du da auf der sicheren Seite.

Außerdem würde es sicherlich einen Geschwindigkeitsvorteil bringen, wenn Du einmal das Scraper-Objekt erzeugst und dann nur noch die scrape-Methode aufrufst - und nicht für jede Seite ein neues Objekt erzeugst.
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
DanielH
 2008-04-29 19:36
#109006 #109006
User since
2007-11-15
54 Artikel
BenutzerIn
[default_avatar]
renee+2008-04-29 16:30:00--
Reguläre Ausdrücke sind mit Sicherheit schneller, dafür hast Du unter Umständen einen Wartungsintensiven Code. Was wenn Google aus class=l mal class="l" macht? Dann läuft mit Regex erstmal nix, mit Web::Scraper bist Du da auf der sicheren Seite.


Ja, das stimmt. Deshalb hab ich mir auch Web::Scraper angesehen. Falls ich einen Weg finde XPath zu verwenden, ohne dass das Ganze 10.000 mal langsamer ist, werd' ich auch weiterhin XPath für so einfache Sachen verwenden (für Kompliziertes sowieso).

Ich hab ja oben bereits reineditiert, dass ich XML::LibXML gefunden habe, was ein wrapper um eine c-Bibliothek ist (welche unter anderem XPath unterstützt). Das müsste ja theoretisch sehr viel schneller sein.

renee+2008-04-29 16:30:00--
Außerdem würde es sicherlich einen Geschwindigkeitsvorteil bringen, wenn Du einmal das Scraper-Objekt erzeugst und dann nur noch die scrape-Methode aufrufst - und nicht für jede Seite ein neues Objekt erzeugst.


Leider ist der Geschwindigkeitsvorteil relativ gering:

Vorher:

WebScraper - XPath: 111 wallclock secs (110.18 usr + 0.01 sys = 110.19 CPU) @ 9.08/s (n=1000)

WebScraper - css: 114 wallclock secs (113.16 usr + 0.00 sys = 113.16 CPU) @ 8.84/s (n=1000)

Nachher:

WebScraper - XPath: 111 wallclock secs (109.84 usr + 0.02 sys = 109.86 CPU) @ 9.10/s (n=1000)

WebScraper - css: 110 wallclock secs (109.81 usr + 0.01 sys = 109.82 CPU) @ 9.11/s (n=1000)
kristian
 2008-05-06 12:19
#109235 #109235
User since
2005-04-14
684 Artikel
BenutzerIn
[Homepage] [default_avatar]
Hallo

Mir fällt dazu generell nur eins ein:

ES IST DER FALSCHE WEG!

Lest bitte die Nutzungbedingungen von XY bevor ihr auf die Seiten von XY losgeht.

Alagut, genug geschimpft, hier der produktive Teil:
Google öffnet seine Such-APIs
Guckst du:
http://www.golem.de/0804/59288.html

Ich habs mir kurz angesehen, es gibt unschöne Limits, max. 8 Ergebnisse / max. 4 Seiten => max. 32 Ergebnisse.

Dafür gibt es Suche in News Web Blogs Local Bilder usw. und es ist - wenn man die Richtlinien einhält - zumindest für's Karma der bessere Weg.

Gruss
Kristian


EDIT:
Zwei Links die ich mir gebookmarkt hatte...
http://code.google.com/apis/ajaxsearch/documentati...
http://code.google.com/apis/ajaxsearch/documentati...
<< >> 4 Einträge, 1 Seite



View all threads created 2008-04-29 17:17.