|
|
 | PHP går død
Fra : Thomas Lindgaard |
Dato : 05-04-04 12:59 |
|
Hejsa
Jeg har skrevet en (flere faktisk) webcrawler i PHP, og det går jeg
basalt set ud på at hente en hjemmeside, finde links på denne og så
hente de sider. Med den størrelse Internettet har så er det jo næsten
en uendelig løkke, så crawleren burde køre fra nu og til dinosaurerne
genopstår...
Men på et eller andet tidspunkt så går min crawler i stå - så vidt
jeg kan regne ud så sker det i forbindelse med en fsockopen(). Hvis jeg
kører en
strace -p PID
kan jeg se at den står og laver en masse timeouts.
Jeg har sat en timeout på fsockopen på 10 sekunder og fwrite/fread er
ligeledes begrænset til 10 sekunder med et kald til stream_set_timeout().
Hvad kan det skyldes? Er det et PHP-problem, eller er det fordi jeg får
åbnet for mange forbindelser til servere og systemet/PHP så bliver træt
eller noget helt tredie?
Håber at der er en der har en ide!
/Thomas
| |
 Andreas Haugstrup Pe~ (05-04-2004)
| Kommentar
Fra : Andreas Haugstrup Pe~ |
Dato : 05-04-04 13:25 |
|
Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> wrote in
news:pan.2004.04.05.11.58.29.468508@it-snedkeren.BLACK_HOLE.dk:
> Hvad kan det skyldes? Er det et PHP-problem, eller er det fordi jeg får
> åbnet for mange forbindelser til servere og systemet/PHP så bliver træt
> eller noget helt tredie?
Har du tjekket at det ikke er selve php-scriptet der giver time out? Standard
er at et php-script kun kører i 30 sekunder.
Du kan ændre dette i php.ini.
- Andreas
--
Personal: < http://www.solitude.dk>
File Thingie - PHP File Manager < http://www.solitude.dk/filethingie/>
| |
Poul-Erik Andreasen (05-04-2004)
| Kommentar
Fra : Poul-Erik Andreasen |
Dato : 05-04-04 13:43 |
|
On Mon, 5 Apr 2004 12:25:27 +0000 (UTC)
Andreas Haugstrup Pedersen <usenet@solitude.dk> wrote:
> Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> wrote in
> news:pan.2004.04.05.11.58.29.468508@it-snedkeren.BLACK_HOLE.dk:
>
> > Hvad kan det skyldes? Er det et PHP-problem, eller er det fordi jeg får
> > åbnet for mange forbindelser til servere og systemet/PHP så bliver træt
> > eller noget helt tredie?
>
> Har du tjekket at det ikke er selve php-scriptet der giver time out? Standard
> er at et php-script kun kører i 30 sekunder.
Lige en tilføjelse de 30 sekunder er den rene kørselstid. Det vil sige at tid
hvor proccesen den står og venter f.eks på input, tæller ikke med.
Så selv om der går meget længere tid end 30 sekunder før scriptet stopper kan
det sagtens være det der er problemet alligevel.
--
Poul-Erik Andreasen
http://www.linux-service.dk
http://www.pea.dk
| |
Thomas Lindgaard (05-04-2004)
| Kommentar
Fra : Thomas Lindgaard |
Dato : 05-04-04 14:14 |
|
On Mon, 05 Apr 2004 14:43:02 +0200, Poul-Erik Andreasen wrote:
>> Har du tjekket at det ikke er selve php-scriptet der giver time out?
>> Standard er at et php-script kun kører i 30 sekunder.
>
> Lige en tilføjelse de 30 sekunder er den rene kørselstid. Det vil sige
> at tid hvor proccesen den står og venter f.eks på input, tæller ikke
> med.
>
> Så selv om der går meget længere tid end 30 sekunder før scriptet
> stopper kan det sagtens være det der er problemet alligevel.
Hejsa
Det er ikke dér problemet ligger - jeg har kaldt set_time_limit(0) så
PHP-scriptet skulle kunne køre for evigt. Desuden har jeg kaldt
ini_set('memory_limit', '100M'), så det burde heller ikke være et
hukommelsesloft jeg er stødt på.
Mvh.
/Thomas
| |
Jens Kristian Søgaar~ (05-04-2004)
| Kommentar
Fra : Jens Kristian Søgaar~ |
Dato : 05-04-04 13:32 |
|
Hej Thomas,
> strace -p PID
> kan jeg se at den står og laver en masse timeouts.
> Jeg har sat en timeout på fsockopen på 10 sekunder og fwrite/fread er
Jeg har observeret nøjagtigt samme problem med PHP, og det ser da også
ud til at være en bug i PHP. Jeg løste problemet ved at fixe bug'en i
source-koden -- desværre er det noget meget meget rodet software, så det
blev en "hack" løsning, som udelukkende virker på den specifikke
timeout, jeg skal bruge.
Jeg har oprettet en bug-sag om det på PHPs side, men desværre har de
valgt ikke at rette den (eller også kan de ikke reproducere fejlen).
--
Jens Kristian Søgaard, Mermaid Consulting ApS,
jens@mermaidconsulting.dk,
http://www.mermaidconsulting.com/
| |
Thomas Lindgaard (06-04-2004)
| Kommentar
Fra : Thomas Lindgaard |
Dato : 06-04-04 11:21 |
|
On Mon, 05 Apr 2004 14:31:58 +0200, Jens Kristian Søgaard wrote:
> Jeg har observeret nøjagtigt samme problem med PHP, og det ser da også
> ud til at være en bug i PHP. Jeg løste problemet ved at fixe bug'en i
> source-koden -- desværre er det noget meget meget rodet software, så det
> blev en "hack" løsning, som udelukkende virker på den specifikke
> timeout, jeg skal bruge.
Hmm - så er det spørgsmålet om man skal være glad for at det nok ikke
er ens egen kode der er skyld i problemet, eller om man skal være
irriteret over at man ikke (sårn lige) kan løse det og komme videre :)
> Jeg har oprettet en bug-sag om det på PHPs side, men desværre har de
> valgt ikke at rette den (eller også kan de ikke reproducere fejlen).
Oki - kan man ikke sende dem en rocker til at skynde lidt på?
Mvh.
/Thomas
| |
Poul-Erik Andreasen (05-04-2004)
| Kommentar
Fra : Poul-Erik Andreasen |
Dato : 05-04-04 14:42 |
|
On Mon, 05 Apr 2004 15:13:50 +0200
Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> wrote:
> On Mon, 05 Apr 2004 14:43:02 +0200, Poul-Erik Andreasen wrote:
>
> >> Har du tjekket at det ikke er selve php-scriptet der giver time out?
> >> Standard er at et php-script kun kører i 30 sekunder.
> >
> > Lige en tilføjelse de 30 sekunder er den rene kørselstid. Det vil sige
> > at tid hvor proccesen den står og venter f.eks på input, tæller ikke
> > med.
> >
> > Så selv om der går meget længere tid end 30 sekunder før scriptet
> > stopper kan det sagtens være det der er problemet alligevel.
>
> Hejsa
>
> Det er ikke dér problemet ligger - jeg har kaldt set_time_limit(0) så
> PHP-scriptet skulle kunne køre for evigt. Desuden har jeg kaldt
> ini_set('memory_limit', '100M'), så det burde heller ikke være et
> hukommelsesloft jeg er stødt på.
Det er muligvis dumt at spørge, men husker du at køre
fclose($fh)på dine fsockopen($fh).
Eller kører du først fclose($fh) efter din at du spider til en
ny side. På den måde får du nemlig en masse åbne
fsokopen der står og hænger.
--
Poul-Erik Andreasen
http://www.linux-service.dk
http://www.pea.dk
| |
Thomas Lindgaard (05-04-2004)
| Kommentar
Fra : Thomas Lindgaard |
Dato : 05-04-04 23:47 |
|
On Mon, 05 Apr 2004 15:41:58 +0200, Poul-Erik Andreasen wrote:
>
> Det er muligvis dumt at spørge, men husker du at køre
> fclose($fh)på dine fsockopen($fh).
Det kører efter devisen
fsockopen - send request - læs svar - fclose
> Eller kører du først fclose($fh) efter din at du spider til en
> ny side. På den måde får du nemlig en masse åbne
> fsokopen der står og hænger.
Øhm - ikke forstået :)
Mvh.
/Thomas
| |
Poul-Erik Andreasen (06-04-2004)
| Kommentar
Fra : Poul-Erik Andreasen |
Dato : 06-04-04 00:30 |
|
On Tue, 06 Apr 2004 00:46:56 +0200
Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> wrote:
> On Mon, 05 Apr 2004 15:41:58 +0200, Poul-Erik Andreasen wrote:
>
> >
> > Det er muligvis dumt at spørge, men husker du at køre
> > fclose($fh)på dine fsockopen($fh).
>
> Det kører efter devisen
>
> fsockopen - send request - læs svar - fclose
>
> > Eller kører du først fclose($fh) efter din at du spider til en
> > ny side. På den måde får du nemlig en masse åbne
> > fsokopen der står og hænger.
>
> Øhm - ikke forstået :)
Hvis du skal spide efter nye links så skal programmet jo fungere
rekursivt på en eller anden måde det er jo nød til at kalde sig selv
med det nye link for at man kan komme videre.
Hvis det sker i sekvensen "læs svar" kommer du til at stå med en masse åbne
handlere.
jeg ville køre sådan her(det er måske også det du mener)
fsockopen - send request - gem svar midlertidigt -fclose - læs svar.
På den måde bliver hver filehandle lukket før du starter på et nyt
link.
--
Poul-Erik Andreasen
http://www.linux-service.dk
http://www.pea.dk
| |
Thomas Lindgaard (06-04-2004)
| Kommentar
Fra : Thomas Lindgaard |
Dato : 06-04-04 10:47 |
|
On Tue, 06 Apr 2004 01:30:12 +0200, Poul-Erik Andreasen wrote:
> Hvis du skal spide efter nye links så skal programmet jo fungere
> rekursivt på en eller anden måde det er jo nød til at kalde sig selv
> med det nye link for at man kan komme videre.
Hejsa
Der er ingen rekursion involveret (jo i forbindelse med redirects - men
det ryger aldrig gennem ret mange lag). Alt foregår i en while-løkke:
while ( køen er ikke tom )
{
hent side
find links
tilføj links til kø
}
Mvh.
/Thomas
| |
 Bo (06-04-2004)
| Kommentar
Fra : Bo |
Dato : 06-04-04 10:53 |
|
Det lyder som et spændende projekt, er det evt. noget man kan se i funktion
når problemerne er løst ? 
Mvh
Bo
| |
Thomas Lindgaard (06-04-2004)
| Kommentar
Fra : Thomas Lindgaard |
Dato : 06-04-04 11:09 |
|
On Tue, 06 Apr 2004 11:52:55 +0200, Bo wrote:
> Det lyder som et spændende projekt, er det evt. noget man kan se i funktion
> når problemerne er løst ?
Jeg ved ikke lige om problemerne bliver løst :) ... men du kan da se
koden til forrige version her:
http://www.daimi.au.dk/~u972035/speciale/miniwebcrawler.phps
Jeg har lige lavet en ny version som er en kombination af det meste af
PHP-koden og et bash-script. Den gamle version kører indtil den er
færdig (eller det var i hvert fald meningen), mens den nye bliver fodret
med op til 500 URL'er og bliver så startet igen af bash-scriptet hvis der
er flere URL'er i kø.
Grunden til den nye strategi var at jeg håbede at grunden til at skidtet
gik i stå kunne omgås ved at køre en række mindre crawls i serie...
men ak!
Mvh.
/Thomas
| |
|
|