Veel data verwerken; php of perl?

[Rene59]

Hey, ik heb een flink aantal logbestanden. Gezamenlijk zo'n 60 Mb en het worden er steeds meer.
Nu wil ik deze adhv een script analyseren en de resultaten online gebruiken. Een statistieken site dus.
Maar wat raden jullie nou aan, php of perl?

Het is niet de bedoeling dat alles op aanvraag gegenereerd wordt uiteraard. Dat gebeurt om de dag met dat script.

Wie is hierin het snelste/stabielste/etc? PHP of Perl?

[Verwijderd]

Wellicht van belang: welk OS?

Linux, Windows?

[brammetje]

zware regex shit en strings handling zou ik (als het kon) perl voor gebruiken...

[disjfa]

ligt eraan hoe je t programeert natuurlijk, niet aan de taal

als je brak progt dan komt er een onstabiel progje van.... (en vice versa natuurlijk )

[Rene59]

Windows.
En ga er dan even van uit dat ik het goed programmeer.
Wat is dan de snelste?

[Verwijderd]

Zend schopt kont!

[TrailBlazer]

perl definitely
Practical
Extraction
Report
Language

ligt eraan hoe je t programeert natuurlijk, niet aan de taal

Niet mee eens. Perl biedt je standaard heeel veel mogelijkheden voor textbewerking. En dus programeert dit makkelijker.

[Verwijderd]

perl of AWK zijn akelig krachtig bij het verwerken van logfiles.
Maar wanneer je het onderste uit de kan wil hebben, of wanneer je geen nieuwe taal wilt leren, is 't soms beter om zelf die files te parsen met bv. Delphi of C++.
Zelfs wanneer je 't parsen hebt geoptimaliseerd zal 't niet zoveel sneller zijn dan perl of AWK, maar de syntax van die twee komt je ook niet zomaar aanwaaien, dus dat scheelt ook weer ontwikkeltijd.

[TrailBlazer]

Perl vindt ik juist een van de makkelijste talen die er zijn. Alleen het aanspreken van variabelen arrays en hashes kan wel een sonduidelijk zijn maar dan kun je ook wel hele stoere dingen doen. Waarodner de mensen die de code lezen gek krijgen

code:

$var=$var{$var[0])

volkomen legitiem maar volkomen onbegrijpelijk voor mensen die perl niet kennen

[jurri@n]

Als ik me niet vergis heeft PHP standaard een timeout-instelling. Een script mag niet meer dan x seconden draaien. Ik heb zelf ook al eens een analyzer willen maken met PHP, maar toen ik deze losliet op de log van m'n interne proxyserver (log van > 1/2 jaar, en dan met meerdere gebruikers ) stopte m'n script helaas voortijdig

Ik zou dus perl gebruiken...

[Apache]

Op dinsdag 18 december 2001 22:06 schreef jurri@n het volgende:
Als ik me niet vergis heeft PHP standaard een timeout-instelling. Een script mag niet meer dan x seconden draaien. Ik heb zelf ook al eens een analyzer willen maken met PHP, maar toen ik deze losliet op de log van m'n interne proxyserver (log van > 1/2 jaar, en dan met meerdere gebruikers ) stopte m'n script helaas voortijdig

Ik zou dus perl gebruiken...

set_time_limit(6000);

[mbravenboer]

<compleet off-topic>

sig van jurri@n: "The first month of the year is JANUARY which is 0; the last depends on the number of months in a year." (Java API documentatie)

Dit staat er ook :

public static final int UNDECIMBER

Value of the MONTH field indicating the thirteenth month of the year. Although GregorianCalendar does not use this value, lunar calendars do.

</compleet off-topic>

[dusty]

Ik zou fijn gebruik maken van een van de bestaande log analyzers.

[drm]

Op dinsdag 18 december 2001 22:02 schreef TrailBlazer het volgende:
Perl vindt ik juist een van de makkelijste talen die er zijn.

code:

$var=$var{$var[0])

volkomen legitiem maar volkomen onbegrijpelijk voor mensen die perl niet kennen

Ik ben geen Perl-crack, maar dat is volgens mij volkomen fout:

code:

$var=$var{$var[0])
             ^
Ik heb het vermoeden dat dat een sluitaccolade moet zijn.

En dat zijn trouwens niet de onbegrijpelijke dingen in Perl, imo.

Imo zijn de ietwat cryptische coderingen van allerlei variabelen ( $_ bijv), en regexen "door de taal heen" redelijk moeilijk te volgen.

[Verwijderd]

Op woensdag 19 december 2001 08:31 schreef dusty het volgende:
Ik zou fijn gebruik maken van een van de bestaande log analyzers.

Ja idd dat dacht ik dus ook

http://www.webtrends.com

[ACM]

60MB "om de dag" is trouwens niet eens zo gek veel.

Ik weet niet of je wel zoveel verschil merkt met verwerken tussen php en perl.
Als je dus een van de twee beter kent kan je net zo goed die taal nemen, want de kans is dan het grootst dat je daar het efficientst mee programmeert.

[TrailBlazer]

Op woensdag 19 december 2001 08:54 schreef drm het volgende:

[..]

Ik ben geen Perl-crack, maar dat is volgens mij volkomen fout:

code:

$var=$var{$var[0])
             ^
Ik heb het vermoeden dat dat een sluitaccolade moet zijn.

Ja klopt dom van me vinger luistere weer eens niet. (leuk iemand die mijn post leest)

En dat zijn trouwens niet de onbegrijpelijke dingen in Perl, imo.

Imo zijn de ietwat cryptische coderingen van allerlei variabelen ( $_ bijv), en regexen "door de taal heen" redelijk moeilijk te volgen.

Ja klotp regexen zijn best lastig

code:

$ts_dlci=~s/(\s*(\d{3})\s(\d{3})\s(\d{3})\s*\w*\s*(\d*))/$2:$3:$4;/g;

Dit is denk ik wat je bedoelt. Daarom denk ik niet dat mijn baas me ontslaat (KPN) niemand op de afdeling begrijpt dit.
En het kan ook best lastig zijn omde dit soort variabelen $ARGV[0] zijn ook niet fijn

[ACM]

Op woensdag 19 december 2001 10:08 schreef TrailBlazer het volgende:
Daarom denk ik niet dat mijn baas me ontslaat (KPN) niemand op de afdeling begrijpt dit.

Als je het niet documenteert zal je baas je misschien alsnog wel willen ontslaan

Magoed, deze begrijp ik gelukkig nog wel.

[Verwijderd]

Op woensdag 19 december 2001 10:08 schreef TrailBlazer het volgende:

Ja klopt regexen zijn best lastig

code:

$ts_dlci=~s/(\s*(\d{3})\s(\d{3})\s(\d{3})\s*\w*\s*(\d*))/$2:$3:$4;/g;

Dit is denk ik wat je bedoelt. Daarom denk ik niet dat mijn baas me ontslaat (KPN) niemand op de afdeling begrijpt dit.

Ik zou zelfs 11,2% loonsverhoging vragen