URL's checken of ze nog bestaan in php of via programma

[Damic]

Voor mijn program dat ik heb geschreven heb ik een nogal "grote" db met niets anders dan url's (5505 momenteel). Dit wil ik dagelijks checken of ze nog wel actief zijn.

Ik was begonnen met php en curl, dit werkt maar ik loop tegen de php timeout aan. Deze kan ik verhogen maar is niet zo heel gezond, ik zit op een shared server dus beetje denken aan de rest van de users.

Elke curl heeft een timeout van 3s gekregen om zoveel mogelijk url's te doen maar dan nog duurt het minimum 4h30 om er door te gaan en in de toekomst gaat dit nog langer duren

Nu is mijn gedacht van: ik zou daar ook een .net applicatie voor kunnen bouwen die ik zelf draai. De data komt van de server af via json/csv/xml (nog te kiezen wat) en dan kan mijn applicatie dat in de dag of 's nachts rustig allemaal checken en achteraf de data met status terug sturen en parsen via php. Wat veel minder server load veroorzaakt en iedereen happier maakt

Wat denken jullie?

[Sandor_Clegane]

Damic schreef op zaterdag 19 oktober 2019 @ 09:58:
Voor mijn program dat ik heb geschreven heb ik een nogal "grote" db met niets anders dan url's (5505 momenteel). Dit wil ik dagelijks checken of ze nog wel actief zijn.

Ik was begonnen met php en curl, dit werkt maar ik loop tegen de php timeout aan. Deze kan ik verhogen maar is niet zo heel gezond, ik zit op een shared server dus beetje denken aan de rest van de users.

Elke curl heeft een timeout van 3s gekregen om zoveel mogelijk url's te doen maar dan nog duurt het minimum 4h30 om er door te gaan en in de toekomst gaat dit nog langer duren

Nu is mijn gedacht van: ik zou daar ook een .net applicatie voor kunnen bouwen die ik zelf draai. De data komt van de server af via json/csv/xml (nog te kiezen wat) en dan kan mijn applicatie dat in de dag of 's nachts rustig allemaal checken en achteraf de data met status terug sturen en parsen via php. Wat veel minder server load veroorzaakt en iedereen happier maakt

Wat denken jullie?

Check: https://fsharpforfunandpr...rency-async-and-parallel/

Staat een voorbeeld van een Async url downloader in. Kun je zo verherbouwen.

Ik denk dat je server load wel meevalt, als je alleen op een 200 OK checked. Het meeste zal netwerk zijn wat een eeuwigheid duurt in vergelijking met normale operaties en wat voor het grootste deel gewoon wachten is.

[Kalentum]

Als je een PHP script los draait (command line of cron), dan heb je toch geen timeout? Lang lopende scripts zijn in ieder geval geen probleem.

Om je script sneller te maken heb je verschillende opties:
- Threads (https://www.php.net/manual/en/class.thread.php) gebruiken zodat je bv 10 urls tegelijk kan checken
- je lijst met URL's voorzien van een last_checked_at timestamp en dan, in plaats van alle URL's in 1 loop te checken, alleen maar de 100 met de oudste last_checked_at timestamp URL's pakken (dus de hele dag door URL's checken)

[Verwijderd]

Om te beginnen. Wil je daadwerkelijk elke 24h checken of de URL nog bestaat? Met welke period ben je maximaal tevreden? Een dag? Een week?

Om te zien of een pagina bestaat en of een website niet gewoon tijdelijk down is, kan je wellicht alleen OPTIONS gebruiken zodat je aan de reactie kan zien of de pagina nog bestaat en verder geen content hoeft te downloaden.

Een pagina die down is hoeft niet te betekenen dat de pagina ook permanent weg is.

Wat wil je met het resultaat doen? Wat is je einddoel? Dit klinkt een beetje als een XY probleem.

[RobIII]

Verwijderd schreef op zaterdag 19 oktober 2019 @ 11:09:
Om te zien of een pagina bestaat en of een website niet gewoon tijdelijk down is, kan je wellicht alleen OPTIONS gebruiken

OPTIONS doet niet wat jij dénkt dat 't doet, HEAD daarentegen wel

[Damic]

Dank allen voor de antwoorden, aan meerdere threads was ik ook aan't maar dan lokaal en dacht dat meerdere threads niet bestonden in php (had het nog niet opgezocht).

De url's die ik controleer zijn radio streams van over de hele wereld, deze zou ik dagelijks willen checken (een week zou ook goed zijn)

@Kalentum ha dat wist ik niet, het script zou dus ook als cron job gaan draaien, maar dan nog, beter sneller afhandelen dan open blijven draaien.

Momenteel gebruik ik deze functie en daar staat de body af en de headers alleen *ik weet alleen niet meer waar ik dat gevonden heb

PHP:

    function getHttpResponseCode_using_curl($url, $followredirects = TRUE)
{
    // returns int responsecode, or false (if url does not exist or connection timeout occurs)
    // NOTE: could potentially take up to 0-30 seconds , blocking further code execution (more or less depending on connection, target site, and local timeout settings))
    // if $followredirects == false: return the FIRST known httpcode (ignore redirects)
    // if $followredirects == true : return the LAST  known httpcode (when redirected)
    if(! $url || ! is_string($url)){
        return 0;
    }
    $ch = @curl_init($url);
    if($ch === false){
        return 0;
    }
    /**SET OPTIONS**/
    @curl_setopt($ch, CURLOPT_HEADER         ,true);    // we want headers
    @curl_setopt($ch, CURLOPT_NOBODY         ,true);    // dont need body
    @curl_setopt($ch, CURLOPT_RETURNTRANSFER ,true);    // catch output (do NOT print!)
    if($followredirects)
    {
        @curl_setopt($ch, CURLOPT_FOLLOWLOCATION ,true);
        @curl_setopt($ch, CURLOPT_MAXREDIRS      ,10);  // fairly random number, but could prevent unwanted endless redirects with followlocation=true
    }else{
        @curl_setopt($ch, CURLOPT_FOLLOWLOCATION ,false);
    }
        $headers = [
    //'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
    'Accept-Encoding: gzip, deflate',
  /*  'Accept-Language: en-US,en;q=0.5',
    'Cache-Control: no-cache',
    'Content-Type: application/x-www-form-urlencoded; charset=utf-8',*/
];
    curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

  //@curl_setopt($ch, CURLOPT_CONNECTTIMEOUT ,5);   // fairly random number (seconds)... but could prevent waiting forever to get a result
    @curl_setopt($ch, CURLOPT_TIMEOUT        ,10);   // fairly random number (seconds)... but could prevent waiting forever to get a result
    @curl_setopt($ch, CURLOPT_USERAGENT      ,"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0");   // pretend we're a regular browser
    
    /**Get the url :)**/
    @curl_exec($ch);
    if(@curl_errno($ch)){   // should be 0
        $err=@curl_errno($ch) .': '.@curl_error($ch);
        @curl_close($ch);
        return $err;
    }
    $code = @curl_getinfo($ch, CURLINFO_HTTP_CODE); // note: php.net documentation shows this returns a string, but really it returns an int
    @curl_close($ch);
    return $code;
}

Edit: functie aangepast, ik kreeg veel geen code's terug dus heb ik eerst de curl_errno() terug gegeven maar vermits dat ik daar niet wijzer van werd ook de curl_error() erbij gedaan. Na wat runs en veel error 7 terug tekrijgen, ben ik wat gaan testenen kwam ik tot de conclusie dat er waarschijnlijk een header niet gezet was.

Dus headers bij ingevoegd en dan kreeg ik een 200 terug Dan een heel deel in commentaar gezet en ik moest blijkbaar alleen de encoding hebben.

[ Voor 23% gewijzigd door Damic op 17-11-2019 12:27 . Reden: Code aangepast ]

[ACM]

In plaats van met php-threads te 'klooien' kan je ook Curl's functionaliteit voor meerdere asynchrone requests gebruiken. Zie de diverse curl_multi-functies.

Is vast niet helemaal triviaal te gebruiken, maar dan hoef je in ieder geval niet te hopen dat je een php met multi-threading hebt en alle problemen die je door multi-threading krijgt te proberen op te lossen.

Hou er trouwens rekening mee dat controleren op status codes niet perfect zal werken. Er zijn met dit soort dingen altijd edge cases, bijvoorbeeld:
- Je kan tijdelijk geen 200 of zelfs geen response krijgen
- Je kan een redirect krijgen en daarna een 200; blijkbaar is dan je opgeslagen url verouderd
- De partij achter de site kan gestopt zijn en dat met een 200-response melden (zoals o.a. vaak bij faillissement gebeurt)
- De site kan gestopt zijn, door een domeinsquatpartij overgenomen zijn en vragen 'wil je dit domein kopen?' met een 200 status

[Matis]

Wij hebben een vergelijkbare situatie. Het gaat niet zozeer over het controleren van URLs, maar wel het "parallel" verwerken van data uit een grote set.
Wij hebben een cron-systeem gebouwd dat maximaal 5 concurrent processen (Docker containers) kan starten. We hebben een tabel met daarin de data welke we moeten controleren. Als een proces start, neemt deze x-aantal (in ons geval 1000) oudste entries uit de database en schrijft een lock-bit in de tabel. Op dat moment beginnen we met verwerken van de data en schrijven de resultaten weer terug, updaten we de modificatie-datum en verwijderen we het lock-bit. Een minuut later begint de volgende container met precies dezelfde strategie. Totdat het maximum van 5 parallelle containers. Het is niet gezegd dat de eerste als eerste klaar, maar de daaropvolgende minuut checkt de cron of er weer eentje gestart mag worden en start, indien nodig, een nieuw proces.

Mocht er een container vastlopen, dan loopt er een aparte cronjob welke alle gelockte rijen met een modificatiedatum ouder dan 1 dag weer unlockt en wacht op een volgende container.

Om nog even inhoudelijk te reageren, ik vind het een gewaagde manier om te controleren of de URLs nog kloppen. Wat als je een redirect krijgt naar een "globale" pagina. Hoe ga je dan detecteren dat de stream nog werkt? Een 200 betekent niet perse dat de stream nog bestaat. Of begrijp ik iets verkeerd?

[ Voor 12% gewijzigd door Matis op 20-10-2019 10:39 ]

[Damic]

@ACM Het is de bedoeling om de urls automatisch te testen en diegene dat niet meer werken in een rapport te dumpen en te mailen naar me dat ik deze eens moet nakijken. Zodoende dat ik zelf kan zien wat er gebeurd met de url, in ieder geval heb ik mijn code aangepast zodoende dat ik test op 200 en 30x.

Die curl_multi-functies moet ik eens bekijken, want op het eerste gezicht (ik zal het wrs wel verkeerd hebben) moet ik wachten tot al de curls gedaan hebben voor ik de volgende batch kan starten, terwijl met multithreaded kan ik de threads in het oog houden en telkens als er 1 gedaan heeft een nieuwe starten.

[PeeVv]

Moet het per se in PHP? Heb je ook bijv. NodeJS tot je beschikking? Dat is asynchroon, dus kan je zonder problemen tientallen tot honderden URLs tegelijk proberen (afhankelijk van wat je server aankan), dan ben je in een paar minuten klaar.

[Merethil]

PeeVv schreef op zondag 20 oktober 2019 @ 13:12:
Moet het per se in PHP? Heb je ook bijv. NodeJS tot je beschikking? Dat is asynchroon, dus kan je zonder problemen tientallen tot honderden URLs tegelijk proberen (afhankelijk van wat je server aankan), dan ben je in een paar minuten klaar.

Taal X, Y en Z kunnen dat ook. Hij zou ook 5000 PHP-processen kunnen starten, als de server dat aankan is ie ook binnen een paar minuten klaar.
Hij zit echter op een shared host, dus misschien is het dan minder wenselijk dat allemaal naast elkaar af te trappen.

[RobIII]

Ik snap even niet de noodzaak van alles parallel willen doen en zo snel mogelijk met strakke time-outs enzo. Who cares als dat process urenlang loopt? Als het maar klaar is binnen, zeg, 24 uur zodat je elke dag een rapportje krijgt. Al zou je vertiendubbelen naar 50.000 url's, dat is pakweg 2.000 url's per uur, 34 url's per minuut, 1 url per 2 seconden. Aangenomen dat de meeste url's binnen de seconde reageren zijn de paar trage uitzonderingen geen enkel probleem.

Ik heb ergens begin deze eeuw eind vorige eeuw, toen de snelheden een stuk lager lagen, exact zo'n systeem gebouwd in VB6 (dus niks geen fancy threading of überhaupt http libraries) en dat ding deed met gemak 50k url's per dag (nacht actually, het proces begon om middernacht en was tegen de ochtend meestal al klaar). Overigens was ik enkel geïnteresseerd in een 200/301/302 status (misschien nog een paar andere "OK" statussen), alle andere werden gerapporteerd. De inhoud was, voor mij, niet heel relevant.

Neemt niet weg dat 't natuurlijk wel efficiënter kan met meerdere threads/processen; je moet je alleen afvragen of dat nu al interessant is. Zéker als je op een shared hosting zit is 't helemaal niet zo verkeerd 't "lekker rustig aan" te doen. Heb je harde requirements dat 't binnen X tijd gedaan moet zijn dan wordt 't een ander verhaal, maar zoals ik uit je verhaal tot nu toe lees is een "eens per etmaal" een "nice to have" maar dat een "eens per week" eigenlijk ook nog wel prima is... waar hebben we 't dan over? (Uitgaand van 5500 urls per week hebben we 't zelfs over ~30 url's per uur ofwel 1 url per 2 minuten... als dát al niet lukt ). Je moet je ook afvragen: ga je elke dag wat met zo'n rapport doen? Of is een wekelijks rapport (wellicht iets langer qua resultaten maar dus wel infrequenter) niet eigenlijk net zo handig? Ga je "dode url's" élke dag meteen opschonen/fixen? Wat is het probleem / wat kost het je als een dode url een paar dagen in je DB staat? Lopen je klanten weg dan? Kost het je inkomsten? Of loopt 't allemaal wel los en is 't niet zo'n issue? Op basis daarvan zou ik eerst dus eens requirements opstellen en op basis daarvan zou ik eens gaan kijken wat je software nou eigenlijk helemaal aan moet kunnen. En ik denk dat als je dat eerlijk bekijkt 't allemaal reuze meevalt en je dus die tijd beter kunt besteden aan andere zaken

[ Voor 60% gewijzigd door RobIII op 20-10-2019 14:06 ]

[Ben(V)]

Onnodig ingewikkeld allemaal
Een python script is veel eenvoudiger.
Dit voorbeeld scriptje checked of google bereikbaar is.
Een loopje er omheen die door de lijst met url's loopt is alles wat je nodig hebt

Python:

import requests
Url = "http://www.google.com"
print requests.Session().head(Url, timeout=3).ok

Als je alles gelijktijdig wilt checken dan kun je threads gebruiken.

Dit stukje code checked alle URL's in een lijst en maakt een nieuwe lijst met alle URL's die bereikbaar waren.
Elke 10 threads wacht hij even 3 seconden om de server niet te overbelasten.

Python:

import requests, threading, time


UrlList = []
ResultList = []

def CheckUrl(Url, ResultList):
    if requests.Session().head(Url, timeout=3).ok:
        ResultList.append(Url)

for Count, Url in enumerate(UrlList):
    threading.Thread(target=CheckUrl, args=(Url, ResultList, )).start()
    if Count % 10:
        time.sleep(3)

[ Voor 3% gewijzigd door Ben(V) op 20-10-2019 14:29 ]

[Damic]

@RobIII heeft een duidelijk punt, het probleem dat ik eignelijk had was tijds gebonden maar als cron jobs geen timeout kennen speelt dat geen rol

[Damic]

Paar weekends verder en er klopt iets niet, ik krijg geen rapports via mail als ik kleine batches draai wel maar eens boven de 100 streams niets meer, volgens mij heb ik dus wel met een timeout te maken

Dat word leuk zoeken.

[Creepy]

Hoe roep je nu je script aan? Je zou niet de eerste zijn die via cron een PHP script aanroept via een URL ipv via de commandline zodat je alsnog een timeout hebt.....

[Damic]

Dat is ingesteld via DirectAdmin, moet ik eens nakijken.

[AW_Bos]

Zit er geen mail-limiet in je profiel in DirectAdmin?

[Damic]

Ja 1000/dag en heb er vandaag 1 verstuurd en die is ook aangekomen

Edit: mmmh nu lijkt het wel of dat de php niet word uitgevoerd edit2: yes werkt wel

In ieder geval is de volgende string de cron die zou uitgevoerd moeten worden: /usr/local/bin/php /home/[accountname]/domains/cd-pc.be/public_html/ts_cron.php

Edit3: heb het getest tot 1000 url's en dat werkt nu de volledige tabel eens doen.

Edit4: het werkt en ik weet niet wat er mis ging

Edit5: juist tegen een mysql error gelopen: SQL Error : 2006 MySQL server has gone away
Altijd handig als een script lang bezig is en dan 1 record moet updaten en de verbinding is dood eens zien of het met ini_set("mysqli.reconnect", 1); wel werkt

Edit6: reconnect is sinds 2018 niet meer in gebruik maar SESSION.wait_timeout werkt dan weer wel
Query doen met het volgende is SET @@SESSION.wait_timeout=18000; is goed voor 5h

[ Voor 117% gewijzigd door Damic op 07-11-2019 21:17 ]