[PHP] error_reporting (E_ALL) & snelheid

[DRvDijk]

In een loopje wil ik telkens een waarde bij een variabele optellen. Als de variabele nog niet geset is, krijg ik een error. Logisch. Dus IN dat loopje doe ik telkens:
if (!isset ($var)) { $var = null; }
Dat werkt goed.. Ik krijg geen error meer. Alleen deze regel scheelt me 0.7 seconde in executie-tijd (ja, ik rag 16000 keer langs het loopje).

Waarom niet net voor het loopje? Omdat $var voor het loopje ook al kán bestaan.

Kán ik op een snellere manier checken of de variabele al bestaat? 0.7 seconde is redelijk lang namelijk (op de 10 seconde weliswaar, maar zonder check zit ik dus op 9.3).


Vóór de hele error_reporting (E_ALL) discussie wéér begint: ik zet het niet uit. Imho is het géén onzin. Noem het princiepe, maar het blijft aan En als er geen snellere manier is: so be it.. Maar ideeën?

[Grum]

16000x in 10 sec .. dan raad ik aan om een betere pc te kopen

[DRvDijk]

Hoe bedoel je betere PC? Celli 466 is goed genoeg voor een server toch? En die check is niet de enige code die in het loopje staat.. Anders is ut loopje een beetje onzinnig niet?

Ghe, wel typerend (en goed ).. Grum als eerste een reply. De error_reporting(E_ALL)-freak (en terecht!)

[ACM]

Waarom niet net voor het loopje?

[Stewie!]

even een andere vraag over dat error reporting all gedoe:
ik krijg telkens een fout als ik een array heb en dan de tweede waarde in de array pak door $array[1]. Dan geeft ie een undefined offset in de betreffende regel. Dit probleem heb ik bijvoorbeeld bij:

code:

$array = explode(bla,$bla);
$blabla[$array[0]] = $array[1];

hoe los ik dit op?

[DRvDijk]

Op dinsdag 23 april 2002 22:55 schreef DaMorpheus het volgende:
even een andere vraag over dat error reporting all gedoe:
ik krijg telkens een fout als ik een array heb en dan de tweede waarde in de array pak door $array[1]. Dan geeft ie een undefined offset in de betreffende regel. Dit probleem heb ik bijvoorbeeld bij:

code:

$array = explode(bla,$bla);
$blabla[$array[0]] = $array[1];

hoe los ik dit op?

Ghe, zal ik niet gaan zeggen dat die explode kaduuk is? Maar welke error krijg je precies bij wát?

[Stewie!]

hij zegt undefined offset in de regel waar $array[1] in staat

[DRvDijk]

Op dinsdag 23 april 2002 22:54 schreef ACM het volgende:
Waarom niet net voor het loopje?

Sorteren in logs..

PHP:

<?        foreach ($files as $filename) {          $openfile = fopen ($filename, "r");          while ($field = fgetcsv ($openfile, 200)) {            if (isset ($field[1])) {              $getidkey = substr ($field[0], 0, 4) . substr ($field[0], 5, 2) . substr ($field[0], 8, 2) . "," . "$field[2]," . rtrim($field[3]);              $getid[$field[1]][$getidkey][0] = $field[0];              if (!isset ($getid[$field[1]][$getidkey][1])) { $getid[$field[1]][$getidkey][1] = null; }              $getid[$field[1]][$getidkey][1] += $field[4];            } // if          } // while        } // foreach?>

Di's misschien wat ranzige array-code, maar zo moet het eenmaal werken. Daar rag ik dus voor elke regel overheen. Als de fields (behalve $field[4]) in de eerste zeg 10 regels gelijk is, wordt er maar 1 $getid gemaakt. Dáárom niet

[Grum]

Dit kan vast efficienter

[DRvDijk]

Helaas.. Ik ben al meer dan een jaar bezig deze functie maar te herschrijven en herschrijven.. Maar nee, sneller dan nu heb ik um nog nooit gehad..

Behálve als iemand nu aan komt dragen met een betere manier voor die isset!

[Grum]

geef es een 'snipet' logfile welke je moet parsen.

[Verwijderd]

edit: lama

[Grum]

hey! .. great minds think alike

[Verwijderd]

[ACM]

comment dat deel binnen de while es uit?
Dan zie je iig of het daar wel/niet aan kan liggen en of het dus alleen het file lezen is dat zo lang duurt...

Als dat laatste het geval is moet je dat zien te versnellen.
Dat gedoe met al die array's moet ook wel sneller kunnen?

[DRvDijk]

Op dinsdag 23 april 2002 23:06 schreef Grum het volgende:
geef es een 'snipet' logfile welke je moet parsen.

Hiesj Ik ben telkens als ik hiero post me code maar aan het versleutelen om niet te laten zien waar ik mee bezig ben Wordt een grote verassing als het af is.. Wordt er om een log-file gevraagd!! Hiesj!!

Maar goed.. Ik versleutel de log-file ook wel weer (kan dus misschien niet kloppen bij de code)

code:

2002-04-23,192.168.0.2,16662,4,5,2
2002-04-23,192.168.0.2,16311,4,5,1

2002-04-23,192.168.0.2,874621,4,5,1
2002-04-23,192.168.0.2,7854,4,5,3
2002-04-23,192.168.0.2,14577,4,5,2
2002-04-23,192.168.0.3,53147,4,5,1
2002-04-23,192.168.0.3,87965,4,5,1
                ^^^ ^
                 onzin     op te tellen

die $field[2] is dus onzin, die heb ik niet nodig. De laatste ($field[5]) wil ik bij elkaar optellen, als de DATUM (niet tijd) (deel van $field[0]), IP ($field[1]), getalletje ($field[3]) en nog een getalletje ($field[4]) gelijk zijn.

Veel plezier Thanx hehehe

edit:
Ja, die whiteline is expres.. Die kunnen er óók in voorkomen helaas.. Daarom if (isset ($field[1]))..

[DRvDijk]

Op dinsdag 23 april 2002 23:12 schreef ACM het volgende:
comment dat deel binnen de while es uit?
Dan zie je iig of het daar wel/niet aan kan liggen en of het dus alleen het file lezen is dat zo lang duurt...

Als dat laatste het geval is moet je dat zien te versnellen.
Dat gedoe met al die array's moet ook wel sneller kunnen?

Jah, het is wel het while-deel.. Dat neemt 9 van de 10 seconde in.

Dat gedoe met die arrays kan niet sneller: er moeten na dit stukkie nog een aantal groepeer-functies overheen (en die zijn ondertussen RETE snel )

[ACM]

Heb je het volgende al geprobeerd:
Maak een tabelletje in een mysql DB, let daarbij erop dat je date's gebruikt voor de datum en integer's voor het ip.

Daarop leg je een setje indices en vervolgens kan je 2 dingen doen. Voor elke nieuw in te voeren waarde controleren of ie al bestaat en dan optellen (sloomste, maar maar éénmalig). Of je kan er een group-query (insert into andere_tabel select datum, ip, ..., sum(teller) from ... where ... GROUP BY datum, ip) met evt een insert in een andere tabel doen.

Waar je meer winst uit zult halen is denk ik echter als je het voor elkaar weet te krijgen dat je zo min mogelijk logfile nog door moet nemen.

[Grum]

Dit kan ow zo mooi met een regular expression met de 'eval' modifier

[ACM]

Op dinsdag 23 april 2002 23:26 schreef Grum het volgende:
Dit kan ow zo mooi met een regular expression met de 'eval' modifier

Maar is dat ook sneller?

[DRvDijk]

Het stukkie code wat hier staat is de code voor een complete db-update. Als er een filepointer en een file in een andere tabel staan, ga ik vanaf daar verder met een íéts aangepaste code. Ik laad uit de db alle gegevens die al bekend zijn over de datum zoals de eerstvolgende log-regel aangeeft, en tel dáárbij de rest van de logfile op, en flikker die zooi de database weer in.
Nieuwere log-files laadt ik daarna weer compleet in..

Ik weet niet of je tip nog steeds tijdwinst oplevert? De zooi zit al in een db, waarom 2 keer?

[DRvDijk]

Op dinsdag 23 april 2002 23:26 schreef Grum het volgende:
Dit kan ow zo mooi met een regular expression met de 'eval' modifier

ZOEEEEEEEEK OP php.net!!!!! Jij mij hoop geef doe iz ben enzo.. brb

[DRvDijk]

Sorry, ik kom er niet helemaal uit, die tip over regular expressions en eval.. Waar doelde je op?

[WouZz]

Op dinsdag 23 april 2002 23:43 schreef elviver het volgende:
Sorry, ik kom er niet helemaal uit, die tip over regular expressions en eval.. Waar doelde je op?

Op de e modifier voor regex patterns voor gebruik met preg_replace():

/e modifier makes preg_replace() treat the replacement parameter as PHP code after the appropriate references substitution is done.

[DRvDijk]

Da's inderdaad een leuk speeltje Maar Grum.. Di's geen script-request ofzo.. Maar aangezien het te laat is en me functie net weer helemaal werkt na een complete herbouwing ervan, heb ik niet héél veel zin ermee te gaan spelen.. Hoe dacht je dat dat zo mooi kon dan?

[DRvDijk]

Hier in dit draadje werd wéér gevraagd waar ik het voor wil gaan gebruiken. What the heck.. Lees het maar

[Grum]

Dan zou ik PRECIES moeten weten wat je met je data wil.

Maar ik vermoed dat het in een database zetten en de results daarmee eruit vissen toch wat handiger is, zeker als je wat meer met de data wilt doen.

[DRvDijk]

Hehehe hiero doe ik me hele verhaal.. Ik wíl het nog wel een keer plakken, maar of de mods het daar mee eens zijn... vrees ut niet..

[Grum]

En als je nu nog es naar je verhaaltje een pagina terug (of dezelfde pagina als je niet 25posts/page hebt) dan zie je dat je log-sample anders is en wat je eruit wilt halen ook.

[edit]
Ok dat was dus de 3e versie van je logfiles (net ff naar die post gegaan )

Maar ik denk nog steeds dat je beter af bent als je dit in een mysql database insert (en dat is iets wat heel simpel kan natuurlijk )

Hoe ik het zou aanpakken, waarschijnlijk zo:

1/ Move de logfile (en maak evt een 0 byte file aan zodat evt appends doorgaan)
2/ Open de gemovede log (daar word nu dus niet meer ingeschreven)
3/ Lees regel voor regel in (met fgets)
4/ if(strlen($line)) -> split, insert in mysql
5/ blij zijn ? je bent al klaar ?

[Sjaaky]

Als je de personal proxy kan laten loggen naar stdout, kan je een progje schrijven dat die logregel vanaf stdin direct in de database zet.
Dan start je proxy dmv

code:

proxy | log2db

[DRvDijk]

Nope.. de perproxy logt op 1 standaard manier (uit de readme.txt):

code:

OUTPUT: Keyblock log
--------------------
The personal proxy will also output so-called "key logs" which record
details of each completed block that is reported to it by a client.
These files are intended for automated processing and so they have a
very regular, comma delimited formatting. Each line of a key log has the
following fields, in order:

    date/timestamp of format "mm/dd/yy hh:mm:ss"
    IP address of the reporting client
    email address of the client
    first block number in completed packet (16 hexadecimal digits)
    itersize of packet (number of 2^28 blocks)
    operating system identifier of client (0=unknown).
    cpu type of client (0=unknown).
    build number of client (middle segment of version number).

01/15/99 07:39:16,0.0.0.0,[e-mail],6404AF4970000000,10,0,0,6400

Hee, dit is ook nieuw voor mij, dat datum-formaat.. Mijn proxy schrijft ze nog als 1999-01-15 07:39:16 .. Humm.. eens kijken naar een update van de proxy? Maar ja, ik kan um dus niet anders laten loggen