Usar o Internet Explorer para chamar PHP / CURL para API de dados de execução longa faz com que o servidor Apache 2 congele e exija reinicialização


10

Estou executando um programa PHP que funciona bem, desde que não seja invocado por um navegador Microsoft Internet Explorer, após o qual gera os processos abaixo, bloqueia o Apache 2 e requer a reinicialização do servidor web (no 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

Ele costumava bloquear todo o servidor até eu alterar alguns dos parâmetros do módulo " mpm_ " para algo mais razoável no /etc/spache2/apache2.conf .

Dados os problemas com o Internet Explorer, eu até adicionei esta linha:

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

no arquivo de hosts virtuais localizado aqui: / etc / apache2 / sites-available.

Há vários artigos escritos sobre o assunto, mas não obtive sucesso ao implementar nenhum deles:

O servidor Apache 2 trava após receber solicitações do IE 10/11 :

Mais P&D: Internet Explorer 10 (Windows 8) travando o Apache

O programa PHP usa cURL para obter uma lista de 25 itens e executar uma chamada de API (GET) para cada um deles em um servidor externo que retorna dados JSON para processamento adicional. É um programa clássico de dados de longa duração.

O que assusta meu macarrão é que ele funciona bem em todos os outros navegadores, exceto o Internet Explorer - o que faz com que o servidor da Web se comporte mal.

Eu interroguei a P&D listada e algumas implementaram as correções sugeridas, mas ainda assim recebo o mesmo comportamento previsível, recriável e problemático do servidor.

Preciso descobrir como proteger o servidor de se comportar mal quando ele encontrar e o navegador Internet Explorer fazendo essas solicitações específicas. Eu gostaria de entender por que isso acontece em primeiro lugar.

Qualquer orientação, perspectivas, direção ou soluções serão muito apreciadas ...

Aqui está um instantâneo do meu código 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);

?>

Aqui está a página de informações do PHP: http://www.versaggi.net/phptest.phtml


1
Eu acho que você precisa registrar de alguma forma as solicitações HTTP completas recebidas do IE e de algum outro navegador que não tenha um problema, para que possamos compará-las e procurar diferenças. Por favor, dê uma olhada nesta pergunta para saber como você pode fazer isso. Deve haver algo que o IE faz com a solicitação HTTP (algum cabeçalho extra ou ausente etc?) Que leva o Apache a tratá-lo de maneira diferente. Ou isso, ou está em um nível mais baixo (pacotes IP), o que eu certamente não espero.
Stijn de Witt

Coloco uma recompensa para ajudá-lo, espero, a obter alguma atenção para sua pergunta.
Stijn de Witt

2
Pensando um pouco mais, você provavelmente poderia relatar isso ao Apache como um bug ... Porque realmente não há como explicar isso como um bug do Apache. Isso também pode ajudá-lo a fazer com que alguns gurus do Apache muito experientes analisem o problema (e esperamos corrigi-lo). Se você quiser seguir esse caminho, pode ser útil reduzir a página com o problema para o menor cenário possível que ainda tenha o problema. Isso pode ser útil por si só.
Stijn de Witt

Definir um tempo limite em curl usando setopt
user1050544

3
O cliente tem alguma influência sobre quais URLs estão sendo acessados ​​pelo script php? As solicitações de cURL ainda estão em andamento quando você encontra o servidor no estado acima? Será que o IE está tentando novamente as solicitações quando elas estão respondendo muito lentamente? Se cada solicitação HTTP para o servidor da Web puder fazer com que ela inicie outras 25 solicitações HTTP para um back-end, isso poderá ser escalado rapidamente. Você poderia reutilizar as respostas obtidas com o cURL para mais de um cliente?
kasperd

Respostas:


5

Há muito tempo, vi bloqueios do Apache resultantes de um processo do Apache fazendo uma chamada via HTTP para outro URL atendido por um processo do Apache no mesmo servidor. Às vezes, acabava com vários processos aguardando essas chamadas, sem os processos Apache disponíveis para atendê-los. No meu caso, eu tinha uma camada de tradução na frente de algumas páginas da Web, mas chamar uma API no seu próprio site é praticamente a mesma coisa.

As características do navegador que fez a chamada original podem aumentar a probabilidade de ocorrência. Por exemplo, manter vivo, comportamento de tempo limite e assim por diante, mas não é fundamentalmente o navegador que está com defeito.

Se for algo parecido com o que eu vi, você deseja observar o comportamento do tempo limite no uso do curl. O código que você incluiu sugere que você é favorável a isso, mas pode ser mais preciso para entender exatamente em que ponto da solicitação está chegando. Pode ser interessante analisá- lo com tcpdump (ou ngrep, Wireshark ou o que for). Também seria bom saber qual chamada do sistema está em andamento quando o processo de chamada é interrompido. Ou seja, olhe para isso com strace -p [PID].

Você provavelmente também deve estar pensando se pode remover a chamada HTTP do uso da API. Você pode manter as coisas no mesmo processo do Apache fazendo uma chamada direta para o código apropriado que lida com a solicitação da API?

Provavelmente é relevante dizer às pessoas como você está executando o PHP (por exemplo, mod_php, fpm, etc.). Isso pode ser parte da compreensão do mecanismo pelo qual o código trava.


Isso pode ajudar com o interrogatório dos internos do PHP ... versaggi.net/phptest.phtml
ProfVersaggi

Como experimento, desativei as chamadas de API do loop CURL e executei vários testes. Isso isolou o problema, pois durante esses testes, o Apache2 deamon permaneceu saudável.
ProfVersaggi
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.