[php] hoe het snelst externe files opvragen en verwerken?

[r0bert]

Ik moet bestanden opvragen van een andere server dan waar mijn eigen website op staat. Nu doe ik dat door file_get_contents() en vervolgens door preg_match() mijn eigen aanvullende informatie in te voegen, maar deze methode werkt bij mij nog al traag. Soms wel 1 minuut voordat ik de pagina te zien krijg.

Is er een snellere manier om dit te doen? Bijvoorbeeld eerst de hele pagina te downloaden en op te slaan op de eigen server en dan te verwerken ofzo (pagina wordt steeds geupdate, dus moet ie steeds opnieuw gedownload worden, dat dan weer wel).

Iemand tips?

[Verwijderd]

Het is algemeen bekent dat preg* regular expressions over het algemeen twee keer zo snel zijn als ereg* regular expressions. Waarom het bij jou zo traag gaat, kan ik je zo niet zeggen. Dan moet je dus gaan debuggen en kijken waar de bottleneck zit. Ik vermoed dat je RegEx-en in elkaar knutselt die retetraag zijn.
Post eens wat (relevante) code...

[Erkens]

kan je die andere pagina niet zo aanpassen dat je die regexen niet hoeft uit te voeren?

[r0bert]

PHP:

$temp = preg_match_all('/\"id_item\"(.|\n)*?<span class=\"infobox\">(.*)?<\/span>/i', $result, $matchresult);

en nog 4 van soortgelijke RegExen..

maar die laatste 4 worden wel 5x uitgevoerd, dus dat is 4x5+1 RegEx.. Is dat de reden dat ie zo sloom is? Wist dan namelijk niet dat dat zoveel tijd kostte

kan je die andere pagina niet zo aanpassen dat je die regexen niet hoeft uit te voeren?

Nee, de pagina's worden in 1e instantie door wat anders gebruikt, en ik pas ze dan aan (dmv manier die ik nu dan heb dus) om mijn eigen elementen toe te voegen..

[ Voor 65% gewijzigd door r0bert op 07-06-2004 17:44 ]

[Verwijderd]

Zoals Jorgen al zegt, debuggen

Outcomment stukken van je code (bijv de preg_match gedeelten) en kijk bijvoorbeeld hoelang hij uberhaupt doet over het accessen van de file op de andere server. Als je alles stapje voor stapje test zul je het probleem wel tegenkomen en zul je dat (anders) op moeten lossen.

edit:

Zie nu je berichtje pas . 21 regexen is aardig wat maar het zou volgens mij bij lange na geen hele minuut moeten duren (een template systeem heeft het zwaar te verduren en bij mij kan het aardig wat tegelijk hebben zonder langzaam te worden). Is je server erg traag misschien?

[ Voor 33% gewijzigd door Verwijderd op 07-06-2004 17:46 ]

[Cavalera125]

Zou je niet gewoon bijvoorbeeld 1x per uur/dag/week ofzo die pagina kunnen downloaden. Je zegt wel dat de site geupdate wordt, maar als dat maar 1x per dag is is het natuurlijk niet zinvol om het telkens te downloaden en matchen.

[ACM]

Achterhaal eerst es wat er zo lang duurt. Als ik moet raden is het niet de regexp, maar het ophalen van de content...

En php kent voldoende timing-functionaliteit (zie o.a. microtime) om een en ander er aan uit te rekenen.

[r0bert]

Verwijderd schreef op 07 juni 2004 @ 17:44:
Zoals Jorgen al zegt, debuggen

Outcomment stukken van je code (bijv de preg_match gedeelten) en kijk bijvoorbeeld hoelang hij uberhaupt doet over het accessen van de file op de andere server. Als je alles stapje voor stapje test zul je het probleem wel tegenkomen en zul je dat (anders) op moeten lossen.

Zelfs als ik de regexpen eruit gooi duurt het nog lang, dus het ligt aan het inladen van het bestand lijkt me.. Ligt het dan aan de server?

quote: Cavalera

Zou je niet gewoon bijvoorbeeld 1x per uur/dag/week ofzo die pagina kunnen downloaden. Je zegt wel dat de site geupdate wordt, maar als dat maar 1x per dag is is het natuurlijk niet zinvol om het telkens te downloaden en matchen.

Nah, zeg dat het om duizend bestanden gaat, waarvan ik niet kan zien of ze geupdate zijn (dynamisch geladen dmv php+id bijv). Da's niet echt te doen om dat iedere dag weer in te laden. Zeker niet als er misschien eens 50x een pagina opgevraagd wordt

quote: ACM

Achterhaal eerst es wat er zo lang duurt. Als ik moet raden is het niet de regexp, maar het ophalen van de content...

Denk dat ej dat goed hebt gegokt Maar is daar wat aan te doen?

[ Voor 10% gewijzigd door r0bert op 07-06-2004 17:49 ]

[Banpei]

r0bert schreef op 07 juni 2004 @ 17:32:
Ik moet bestanden opvragen van een andere server dan waar mijn eigen website op staat. Nu doe ik dat door file_get_contents() en vervolgens door preg_match() mijn eigen aanvullende informatie in te voegen, maar deze methode werkt bij mij nog al traag. Soms wel 1 minuut voordat ik de pagina te zien krijg.

Hoe lang duurt het opbouwen van een connectie per bestand? Als dat namelijk een x seconden duurt is het niet zo gek dat het lang duurt.

Ik zou zeggen: ga even kijken wat de vertragende factor is. Probeer het eens met microtime te timen: dan heb je een beter inzicht in wat er nou precies langzaam is.

[NMe]

r0bert schreef op 07 juni 2004 @ 17:48:
Nah, zeg dat het om duizend bestanden gaat, waarvan ik niet kan zien of ze geupdate zijn (dynamisch geladen dmv php+id bijv). Da's niet echt te doen om dat iedere dag weer in te laden. Zeker niet als er misschien eens 50x een pagina opgevraagd wordt

Je maakt toch niet met 50 verschillende pagina's verbinding he?

[r0bert]

Het laden van 1 pagina duurt al ong. 1 minuut

En als ik 50 pagina's dit uit wil voeren, moet ik toch 50x verbinding maken?

Ennuh, uit mijn microtime test
na inladen bestand: 57.963706970215
na regexen: 57.999920129776

[ Voor 18% gewijzigd door r0bert op 07-06-2004 18:15 . Reden: had lunchpauze ]

[Verwijderd]

r0bert schreef op 07 juni 2004 @ 17:48:
Zelfs als ik de regexpen eruit gooi duurt het nog lang, dus het ligt aan het inladen van het bestand lijkt me.. Ligt het dan aan de server?

Ik zou denken dat het ligt aan de server waarvan je het bestand ophaalt, maar heb verder niet zo'n ervaring in het ophalen van externe bestanden. Het enige wat ik ooit ophaal zijn rss feeds en die gaan razendsnel, als je een gewone html pagina opvraagt van een site ziet hij dat als een request en gaatie alles opmaken wat een tijdje langer kan duren (veronderstel ik), maar nog lang geen hele minuut (of halve minuut, of 10 seconden ).

edit:
Ik & ubb

[ Voor 4% gewijzigd door Verwijderd op 07-06-2004 17:56 ]

[drm]

GsusZ:
als je een gewone html pagina opvraagt van een site ziet hij dat als een request en gaatie alles opmaken wat een tijdje langer kan duren (veronderstel ik), maar nog lang geen hele minuut (of halve minuut, of 10 seconden ).

't Kan PHP geen bal schelen of het .html, .rss, .sjaak of .malle-pietje-met-de-korte-achternaam bestanden zijn die hij ophaalt hoor. Waarschijnlijk is de server waar je de pagina's vandaan haalt gewoon niet zo snel (of de verbinding daar naartoe).

[NMe]

Is de betreffende pagina ook traag als je hem in de browser opent? Als dat niet zo is zul je een stukje van de code moeten laten zien waar je de file inleest, want dan ligt het 90% zeker daaraan.

[r0bert]

inlezen van het bestand (vb)

PHP:

$result = file_get_contents('http://www.server.nl/?module=info&id=2846');

^{en dan preg_match op $result loslaten}

Als ik de pagina gewoon op in mijn browser is ie wel snel.

[drm]

Als ik de pagina gewoon op in mijn browser is ie wel snel.

Maar draai je die browser ook op hetzelfde systeem als waar de webserver op draait? _{met jouw php that is}

Time nou gewoon alles even, dat is een fluitje van een cent en daar word je veel wijzer van dan van al dit halfzachte gegok van ons.

[r0bert]

Wat moet ik nog meer timen dan?

quote: r0bert

Ennuh, uit mijn microtime test
na inladen bestand: 57.963706970215
na regexen: 57.999920129776

[Verwijderd]

Denk, denk, denk. DRM heeft al volgens mij een paar keer de juiste aanpak voorgedragen; zoek waar de vertraging in zit. Nou, dat heb je dus gedaan. Het parsen van die 21 Regular Expressies kost een paar duizendste van een seconde, maar het inladen van het bestand kost zo'n 57 seconden.
Je weet dus dat daar de bottleneck, alias vertragende factor, zit. Draait jou php-script niet op een host die retetraag is?

[r0bert]

Lijkt me niet, ik kan alle pagina's gewoon behoorlijk rap opvragen, ook PHP pagina's. Tenminste, nu heb ik het over interne links/pagina's/includes local op de server. Maar volgens mij is ie snel genoeg. Zou het kunnen helpen als ik alles gewoon even op mijn eigen pc zet? (*gaat het iig vast proberen*)

.. lijkt niet te helpen, dus of het licht aan de file_get_contents() functie of het ligt aan de server waar de pagina's extern op staan

[ Voor 26% gewijzigd door r0bert op 07-06-2004 21:23 ]

[NMe]

r0bert schreef op 07 juni 2004 @ 21:12:
Lijkt me niet, ik kan alle pagina's gewoon behoorlijk rap opvragen, ook PHP pagina's. Tenminste, nu heb ik het over interne links/pagina's/includes local op de server. Maar volgens mij is ie snel genoeg. Zou het kunnen helpen als ik alles gewoon even op mijn eigen pc zet? (*gaat het iig vast proberen*)

Tussen twee servers is altijd trager dan binnen de eigen server, omdat je dan verbindingen moet gaan leggen, een request sturen, data verwerken enz. Op je eigen server is het een kwesite van simpelweg inlezen.

[r0bert]

Ja, maar een laadtijd van een minuut lijkt me dat ook beetje overdreven heb wel eens snellere verbinding gehad tussen hosts


edit:
heel vreemd.. Als ik copy() gebruik om het bestand te kopieeren naar mijn eigen server is het een kwestie van een dikke seconde (edit: dat is dus zoals ik achteraf merk, ook nog wel tegenvaller, af en toe 10 sec. is niet zeldzaam ) misschien ik denk dus dat ik de oplossing dan ook maar in die richting moet zoeken

[ Voor 66% gewijzigd door r0bert op 07-06-2004 21:33 ]

[r0bert]

Is het mogelijk dat het gewoon aan de browser ligt? En zo ja, hoe kan ik de site dan opvragen dat hij wel uitgevoerd wordt, maar niet weergegeven zeg maar.. Dus andere manier dan IE (lijkt me sterk hoor, maar wie weet)

[Cavalera125]

Dat lijkt mij ook erg sterk. Je doet niks anders dan een andere site inlezen en de tijd ervan weergeven. Maar om het uit te sluiten kun je natuurlijk ff in een andere browser kijken...

[r0bert]

Andere browser maakt geen verschil blijkbaar, maar met Teleport Pro gaat het razendsnel (120 kB/s vind ik snel ). Nu ben ik wel benieuwd of iemand weet hoe dat werkt bij Teleport Pro, want dat wil ik natuurlijk ook wel in mijn PHP script! (btw, teleport pro identificeert zich anoniem)

[.oisyn]

Volgens mij is het metertje in die Teleport Pro gewoon stuk, want de "manier van ophalen", voor zover daar verschillen in zijn (zo goed als nihil), maakt dus echt niet uit.

Als het ophalen van een file langzaam gaat, dan moet je dat zoeken bij de verbinding tussen de server waar je php script op draait en de server waar het bestand vandaan komt, nergens anders. Dat kan van alles zijn, maar imho iig geen programmeerprobleem

[r0bert]

Ok, kijk.. ik heb mijn phpscriptje local draaien. Teleport Pro heb ik ook gewoon op mijn eigen computer staan. De verbindingsnelheid is dus hetzelfde.

Zet ik mijn scriptje aan, dan doet hij over iedere pagina 1 minuut +/-
Zet ik teleport pro aan, dan duurt het per pagina +/- 2 à 3 sec.

Het is dus niet alleen het tellertje, het bestand is werkelijk veel sneller binnnen

[.oisyn]

Hmmm, ik zie dit in de comments staan bij de docs van file_get_contents:

I was recently running some PHP version prior to 4.3.0 and had a small script loading a very large file containing some HTML - I made some regular expression matches on content and it went quite fast..(- I had less than a second execution time).
I then upgraded to PHP 4.3.0 and suddenly my script ate my CPU and halted after 30 seconds. It seems since they made the function binary-safe the performance hit rock bottom.
My advice: If you have rather large files (something like >1 MB) - I suggest you use fopen() and fread() :

PHP:

$fp = fopen($file,"r");
$content = fread($fp,filesize($file));
... /* Do something */
fclose($fp);

This did the trick for me, my execution time is now back to normal. (Note: I did however test file() on smaller files, though slow, it worked - and I also tested file() on a fresh installation)
Specs.: AMD Athlon XP 1800+, 256 MB RAM, Windows 2000 (and XP tried), Apache 1.3, PHP 4.2.3

Blijkbaar ligt het dus toch aan PHP. Probeer het eens met fopen en fread, zoals deze persoon gedaan heeft

(Ik herzie mijn vorige statement dat het aan de verbinding moet liggen, en mijn dunk van Zend is weer eens gedaald, ook al dacht ik dat dat niet nog lager kon zijn )

[ Voor 8% gewijzigd door .oisyn op 15-06-2004 14:33 ]

[marty]

de request die je doet maakt ook nog uit. een server kan detecteren dat je geen browser bent en dan wat anders met je request doen. wellicht dat daar de vertragende factoor zit. probeer je zelf eens als browser aan te melden en kijk eens of dat de boel wat versnelt (zie fopen() in de manual)


// edit

PHP:

ini_set("user_agent", "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7");

die werkt zeker, want die gebruik ik zelf
en dan gewoon fopen gebruiken

[ Voor 32% gewijzigd door marty op 15-06-2004 15:11 ]

[r0bert]

.oisyn schreef op 15 juni 2004 @ 14:30:

PHP:

$fp = fopen($file,"r"); 
$content = fread($fp,filesize($file)); 
... /* Do something */ 
fclose($fp);

Verhaal lijkt idd heel veel op mijn probleem. Alleen als ik hiermee probeer van een ander domein uit te lezen (neem bijv. google.com als voorbeeld) dan wil dat niet

filesize("http://www.google.com") geeft:

code:

Warning: filesize(): Stat failed for http://www.google.com/ 
(errno=2 - No such file or directory) in ..\www\load.php on line 7

Warning: fread(): Length parameter must be greater than 0. 
in ..\www\load.php on line 7

Dit geeft geen error, maar nog steeds veelste langzaam..:

PHP:

$handle = fopen($file, "rb");
$result = '';
while (!feof($handle)) {
  $result .= fread($handle, 1024);
}
fclose($handle);

waarin RB speciaal voor systemen is als windows die onderscheid maken tussen binary en text bestanden (zie manual php.nederland.net)

marty schreef op 15 juni 2004 @ 15:07:
de request die je doet maakt ook nog uit. (..)

PHP:

ini_set("user_agent", "Mozilla/5.0 (Windows; U; 
Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7");

(..)

Maar het is juist dat in het mijn browser NIET goed werkt, en in Teleport Pro (die zich NIET identificeert als browser en geen gebruik maakt van php wel). Ik heb hem nu in ieder geval toegevoegd als ini_set("user_agent", "Anonymous"); Mja, lijkt me sterk dat er zoiets ingesteld staat

Wat kan ik nog meer proberen? Evt. taal als ASP overwegen in de hoop dat die er beter mee om gaat? (Iemand adres van gratis ASP server, als die tenminste nog bestaan (geen domaindlx of brinkster))

[ Voor 84% gewijzigd door r0bert op 16-06-2004 16:32 ]

[marty]

r0bert schreef op 16 juni 2004 @ 14:48:
Maar het is juist dat in het mijn browser NIET goed werkt

waar heb je het nu over? je eigen script dat je via een browser aanspreekt, of duur het ook zo lang als je de pagina waar je de content vandaan wil halen via de browser aanspreekt?

[ Voor 55% gewijzigd door marty op 16-06-2004 17:44 ]

[r0bert]

marty schreef op 16 juni 2004 @ 16:43:
[...]


waar heb je het nu over? je eigen script dat je via een browser aanspreekt, of duur het ook zo lang als je de pagina waar je de content vandaan wil halen via de browser aanspreekt?

Nee idd.. rechtstreeks in browser opvragen duurt niet lang, via het scriptje wel.. idd.. sorry

[marty]

als rechtstreeks in de browser opvragen niet lang duurt en via het script wel dan is het verhaal wat ik eerder posten dus best aannemelijk.
probeer dat dus eens uit (dat je doet alsof je script een browser is)

[r0bert]

Heb ik geprobeerd maar dat wordt hem niet

[r0bert]

Iemand nog wat anders? ^

[slm]

1. probeer het gebruik van file() ipv file_get_contents()
Dit is dus de oude/niet binary safe variant

2. als je ongeveer de maximale grootte van de bestanden die je wilt ophalen weet, gebruik je dit ipv de filesize() functie:

PHP:

$maxfilesize = 3000000;
$fp = fopen($file,"rb"); 
$contents = fread($fp,$maxfilesize);
fclose($fp);

3. Gebruik een grotere buffersize in de while (!feof($handle)) variant

[r0bert]

php lijkt nog steeds niet te werken, maar asp geeft geen problemen..

als enige oplossing zie ik dus tot nu toe al mijn code omschrijven naar asp Maar lijkt me toch dat er vaker mensen zijn geweest die last van deze bug hebben gehad.. ben ervan overtuigd dat er een andere oplossing is, hoewel ik nu toch wel beetje de moed begin op te geven.. Iemand eerder dit probleem gehad?

[marty]

ik kan me niet voorstellen dat mijn oplossing niet werkt, volgens mij doe je daar gewoon iets niet goed mee. Het is namelijk precies dezelfde request als dat een browser doet en je had zelf al achterhaald dat als de data eenmaal 'bij PHP' is, het snel verwerkt wordt.
Als het nog steeds niet gelukt is dan wil ik best even proberen of het mij wel lukt. Moet je me even je huidige code geven...