Internet Explorerを使用して長期実行データAPIのPHP / CURLを呼び出すと、Apache 2サーバーがフリーズして再起動が必要になる

Microsoft Internet Explorerブラウザーによって呼び出されない限り問題なく動作するPHPプログラムを実行しています。その後、以下のプロセスが起動され、Apache 2がロックされ、Webサーバーの再起動が必要になります（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

/etc/spache2/apache2.confで「mpm_」モジュールのパラメータの一部をより適切なものに変更するまで、サーバー全体をロックしていました。

Internet Explorerの問題を考慮して、次の行も追加しました。

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

ここにある仮想ホストファイル：/ etc / apache2 / sites-available。

この問題について書かれた記事はたくさんありますが、私はそれらのいずれかを実装することに成功していません。

Apacheサーバー2は、IE 10/11からリクエストを受信した後にハングします。

その他の研究開発： Internet Explorer 10（Windows 8）がApacheをクラッシュさせる

PHPプログラムは、cURLを使用して25項目のリストを取得し、JSONデータを返す外部サーバーに対してそれぞれに対して（GET）API呼び出しを実行して、さらに処理します。それは古典的な長期実行データプログラムです。

私の麺を焼くのは、それがInternet Explorerを除く他のすべてのブラウザーで正常に動作することです-これにより、Webサーバーが誤動作します。

リストされているR＆Dを調査し、いくつかの提案された修正を実装しましたが、予測可能で、再現可能で、問題のあるサーバーの動作は同じです。

サーバーが遭遇したときにサーバーが正しく動作しないように保護する方法と、Internet Explorerブラウザーがサーバーにこれらの特定の要求を行う方法を理解する必要があります。そもそもなぜそれが起こるのか理解したいのですが。

ガイダンス、視点、方向性、または解決策があれば、大歓迎です...

これが私の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);

?>

PHPの情報ページは次のとおりです。http：//www.versaggi.net/phptest.phtml

ずっと前に、ApacheプロセスがHTTP経由で同じサーバー上のApacheプロセスによってサービスされる別のURLに呼び出しを行った結果、Apacheがロックアップするのを見ました。それらのサービスを提供する利用可能なApacheプロセスがない状態で、そのような呼び出しを待機している多数のプロセスを時々巻き込みました。私の場合、いくつかのWebページの前に翻訳レイヤーがありましたが、自分のサイトでAPIを呼び出すことはほとんど同じです。

元の呼び出しを行うブラウザの特性により、これが発生する可能性が高くなります。たとえば、キープアライブ、タイムアウト動作などですが、基本的にはブラウザの問題ではありません。

それが私が見たもののようなものなら、あなたはカールの使用におけるタイムアウトの振る舞いを見たいと思うでしょう。含まれているコードはそれを理解していることを示唆していますが、リクエストのどのポイントに到達するかを正確に理解するために、よりきめ細かくする必要があるかもしれません。tcpdump（またはngrep、Wiresharkなど）で確認すると興味深いかもしれません。また、呼び出しプロセスがハングしたときに進行中のシステムコールを知っておくとよいでしょう。つまり、で見てくださいstrace -p [PID]。

また、APIの使用からHTTP呼び出しを削除できるかどうかについても検討する必要があります。APIリクエストを処理する適切なコードを直接呼び出すことで、同じApacheプロセス内に物事を維持できますか？

PHPの実行方法（mod_php、fpmなど）を人々に伝えることはおそらく関連があります。これは、コードが固まるメカニズムを理解することの一部かもしれません。