L'uso di Internet Explorer per richiamare PHP / CURL per l'API di dati a esecuzione prolungata causa il blocco del server Apache 2 e il riavvio


10

Sto eseguendo un programma PHP che funziona benché non sia invocato da un browser Microsoft Internet Explorer, dopodiché genera i processi seguenti, blocca Apache 2 e richiede un riavvio del server Web (su Ubuntu 12.04 LTS).

bob@drools:/etc/php5/apache2# ps auxwww | grep apache2
root      8737  0.1  2.5 369164 25800 ?        Ssl  12:41   0:00 /usr/sbin/apache2 -k start
www-data  8743  0.0  3.2 393748 33268 ?        Sl   12:41   0:00 /usr/sbin/apache2 -k start
www-data  8755  0.1  3.3 393856 33904 ?        Sl   12:41   0:00 /usr/sbin/apache2 -k start
www-data  8779  0.1  3.2 393724 33252 ?        Sl   12:45   0:00 /usr/sbin/apache2 -k start
www-data  8782  0.1  3.2 393716 33236 ?        Sl   12:45   0:00 /usr/sbin/apache2 -k start
www-data  8785  0.1  3.2 393684 33204 ?        Sl   12:45   0:00 /usr/sbin/apache2 -k start
www-data  8812  1.1  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8815  1.3  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8818  1.3  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8821  1.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8824  1.4  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8827  1.4  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8830  1.4  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8835  2.5  3.2 393684 33256 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8838  2.8  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8841  2.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8844  2.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8847  3.2  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8850  3.0  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8853  3.2  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8856  3.2  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8861  3.3  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8864  3.6  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8867  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8870  3.6  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8873  3.6  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8876  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8879  3.3  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8881  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8883  3.6  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8886  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8891  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8894  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8896  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8900  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8901  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8904  3.5  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8909  3.8  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8912  3.8  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8915  3.8  3.2 393684 33264 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
www-data  8918  3.6  3.2 393684 33260 ?        Sl   12:47   0:00 /usr/sbin/apache2 -k start
root      8922  0.0  0.1   9396  2000 pts/0    S+   12:47   0:00 grep --color=auto apache2

Ha usato per bloccare l'intero server fino a quando ho modificato alcuni dei parametri del modulo " mpm_ " in qualcosa di più ragionevole in /etc/spache2/apache2.conf .

Dati i problemi con Internet Explorer, ho persino aggiunto questa riga:

**" SetEnvIf User-Agent ".*MSIE.*"   nokeepalive "**

nel file degli host virtuali che si trova qui: / etc / apache2 / sites-available.

Ci sono un certo numero di articoli scritti sul problema, ma non ho avuto alcun successo nell'attuare nessuno di essi:

Apache Server 2 si blocca dopo aver ricevuto richieste da IE 10/11 :

Altre attività di ricerca e sviluppo: Internet Explorer 10 (Windows 8) si arresta in modo anomalo Apache

Il programma PHP utilizza cURL per prendere un elenco di 25 elementi ed eseguire una chiamata API (GET) per ciascuno a un server esterno che restituisce i dati JSON per ulteriori elaborazioni. È un programma di dati classico di lunga durata.

Ciò che mi fa impazzire è che funziona bene in tutti gli altri browser tranne Internet Explorer, il che provoca un comportamento anomalo del server Web.

Ho interrogato la ricerca e lo sviluppo elencati e poi alcuni, ho implementato le correzioni suggerite, ma ho ancora lo stesso comportamento prevedibile, ricreabile e problematico del server.

Ho bisogno di capire come proteggere il server dal cattivo comportamento quando si incontra e il browser Internet Explorer che effettua queste particolari richieste. Vorrei capire perché succede in primo luogo.

Qualsiasi guida, prospettiva, direzione o soluzione sarebbe molto apprezzata ...

Ecco un'istantanea del mio codice cURL:

<?php

// *** CURL Init, SetOps, and Execution Statements ****
$ch = curl_init();


// *** Execute the  API call for each part number and store in the Associative Array ****
$index=0;
foreach ($partNumbersArray as $partNum) {

    $MyValue = $partNum;

    $MyUrl = $MyNiinjaBaseURL."/".$APICmd1."/".$MyDataSet."/".$MyValue."?key=".$MyKey."&$"."filter=substringof('".$MyValue."',PartNumbers)";


    // *** cURL SetOpts, and Execution Statements ****
    curl_setopt($ch, CURLOPT_URL, $MyUrl);
    curl_setopt($ch, CURLOPT_HEADER, 0);
    curl_setopt($ch, CURLOPT_FRESH_CONNECT, true);
    // curl_setopt($ch, CURLOPT_TIMEOUT, 15);       // <= THIS *never* worked with any reliability ....
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

    $server_output = curl_exec ($ch);   // <= THIS executes the cURL call and stores the resulting JSON object in the variable '$server_output'

    $niinjaResultsJsonArray[$MyValue] = $server_output;        // Add the JSON object to the Array and index to PartNumber
    $index++;                                                // Increment the index

} // End Execution of NIINJA API Calls

// ** Close the CURL Object and release resources
curl_close ($ch);

?>

Ecco la pagina di informazioni PHP: http://www.versaggi.net/phptest.phtml


1
Penso che sia necessario in qualche modo registrare tutte le richieste HTTP in entrata sia da IE che da altri browser che non presentano problemi in modo da poterle confrontare e cercare le differenze. Si prega di dare un'occhiata a questa domanda per come è possibile farlo. Deve esserci qualcosa che IE fa con la richiesta HTTP (qualche intestazione extra o mancante ecc.) Che induce Apache a trattarla in modo diverso. O quello, o è a un livello più basso (pacchetti IP), che sicuramente non spero.
Stijn de Witt,

Ho messo una taglia su di esso per spero di aiutarti a ottenere un po 'di attenzione per la tua domanda.
Stijn de Witt,

2
Pensandoci un po 'di più, potresti probabilmente segnalarlo ad Apache come un bug ... Perché non c'è davvero modo di poterlo spiegare come non un bug di Apache. Ciò potrebbe anche aiutarti a convincere alcuni guru di Apache molto esperti a esaminare il problema (e speriamo di risolverlo). Se si desidera seguire tale percorso, potrebbe essere utile ridurre la pagina che presenta il problema allo scenario più piccolo possibile che presenta ancora il problema. Questo può essere utile in sé e per sé.
Stijn de Witt,

Imposta un timeout in arricciatura usando setopt
user1050544

3
Il client ha qualche influenza su quali URL accedono allo script php? Le richieste cURL sono ancora in corso quando si trova il server nello stato sopra? Potrebbe essere che IE stia riprovando le richieste quando rispondono troppo lentamente? Se ogni richiesta HTTP al tuo server web può causare l'avvio di altre 25 richieste HTTP a un back-end, ciò può aumentare rapidamente. Potresti riutilizzare le risposte che ricevi con cURL per più di un cliente?
Kasperd,

Risposte:


5

Molto tempo fa, ho visto i blocchi di Apache derivanti da un processo Apache che effettuava una chiamata tramite HTTP a un altro URL servito da un processo Apache sullo stesso server. A volte mi sono ritrovato con un sacco di processi in attesa di tali chiamate senza processi Apache disponibili per servirli. Nel mio caso avevo un livello di traduzione davanti ad alcune pagine web, ma chiamare un'API sul tuo sito è praticamente la stessa cosa.

Le caratteristiche del browser che effettua la chiamata originale potrebbero aumentarne la probabilità. Ad esempio, keep-alive, comportamento di timeout e così via, ma non è fondamentalmente il browser in colpa.

Se è qualcosa di simile a quello che ho visto, allora vuoi guardare il comportamento di timeout nel tuo uso del ricciolo. Il codice che hai incluso suggerisce che ti stai occupando di questo, ma potresti aver bisogno di essere più preciso nella comprensione di esattamente a che punto della richiesta sta arrivando. Potrebbe essere interessante guardarlo con tcpdump (o ngrep, Wireshark o altro). Inoltre sarebbe utile sapere quale chiamata di sistema è in corso quando il processo di chiamata si blocca. Cioè, guardalo con strace -p [PID].

Probabilmente dovresti anche pensare se puoi rimuovere la chiamata HTTP dall'uso dell'API. Riesci a mantenere le cose all'interno dello stesso processo di Apache effettuando una chiamata diretta al codice appropriato che gestisce la richiesta API?

Probabilmente è rilevante dire alla gente come stai eseguendo PHP (ad esempio mod_php, fpm, ecc.). Ciò può far parte della comprensione del meccanismo mediante il quale il codice si blocca.


Questo potrebbe aiutare con l'interrogatorio degli interni di PHP ... versaggi.net/phptest.phtml
ProfVersaggi

Come esperimento ho disabilitato le chiamate API dal loop CURL ed ho eseguito un sacco di test. Ciò ha isolato il problema poiché durante quei test, il deamon di Apache2 è rimasto in salute.
ProfVersaggi,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.