Використання Internet Explorer для виклику PHP / CURL для тривалого запуску API даних змушує сервер Apache 2 замерзнути і вимагає перезавантаження


10

Я запускаю програму PHP, яка працює добре до тих пір, поки її не викликає браузер Microsoft Internet Explorer, після чого вона породжує наведені нижче процеси, блокує Apache 2 і вимагає перезавантаження веб-сервера (на 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

Він використовувався для блокування всього сервера, поки я не змінив деякі параметри модуля " mpm_ " на щось більш розумне в /etc/spache2/apache2.conf .

Враховуючи проблеми з Internet Explorer, я навіть додав цей рядок:

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

у файлі віртуальних хостів, розміщеному тут: / etc / apache2 / sites-available.

До цього питання написано ряд статей, але я не мав жодного успіху в реалізації жодної з них:

Apache Server 2 зависає після отримання запитів від IE 10/11 :

Більше досліджень та розробок: Internet Explorer 10 (Windows 8) вибиває Apache

Програма PHP використовує cURL для отримання списку з 25 елементів та виконання виклику (GET) API для кожного на зовнішній сервер, який повертає дані JSON для подальшої обробки. Це класична тривала програма даних.

Що пече мою локшину, це те, що вона працює чудово у будь-якому іншому браузері, окрім Internet Explorer, - що призводить до поганого поводження веб-сервера.

Я допитував перелічені НДДКР, а потім деякі, впроваджував запропоновані виправлення, але все ще отримую таку ж передбачувану, відтворювану, проблемну поведінку сервера.

Мені потрібно розібратися, як захистити сервер від поганої поведінки, коли він стикається, і браузер 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


1
Я думаю, вам потрібно якось увімкнути всі вхідні запити HTTP як від IE, так і з іншого браузера, у якого немає проблем, щоб ми могли їх порівняти та шукати відмінності. Будь ласка, погляньте на це питання, як ви можете це зробити. Повинно, що IE робить із запитом HTTP (якийсь додатковий чи відсутній заголовок тощо?), Що приводить Apache до цього по-різному. Або це, або це на нижчому рівні (IP-пакети), на що я, напевно, не сподіваюся.
Штійн де Віт

Я покладаю на це щедрість, щоб сподіватися допомогти вам привернути увагу до свого питання.
Штійн де Віт

2
Думаючи про це ще трохи, ви, ймовірно, могли повідомити про це Apache як помилку ... Тому що насправді немає можливості я пояснити це як не помилку Apache. Це також може допомогти вам отримати дуже досвідчених гуру Apache, щоб розглянути проблему (і, сподіваємось, виправити це). Якщо ви хочете піти цим маршрутом, це може допомогти, якщо ви зменшите сторінку з проблемою на найменший можливий сценарій, який все ще має проблему. Це може бути корисно саме по собі.
Штійн де Віт

Встановіть тайм-аут у завитку, використовуючи setopt
user1050544

3
Чи впливає клієнт на те, які URL-адреси отримують доступ до скрипту php? Чи продовжуються запити CURL, коли ви знаходите сервер у зазначеному вище стані? Можливо, IE повторює запити, коли вони відповідають занадто повільно? Якщо кожен запит HTTP на ваш веб-сервер може призвести до того, що він може ініціювати ще 25 запитів HTTP до бекенда, це може швидко наростати. Чи можете ви повторно використовувати відповіді, отримані за допомогою CURL, для більш ніж одного клієнта?
kasperd

Відповіді:


5

Дуже давно я побачив блокування Apache в результаті процесу Apache здійснювати дзвінок через HTTP на іншу URL-адресу, що обслуговується процесом Apache на тому ж сервері. Я іноді закінчуюся купою процесів, які чекають на такі дзвінки без доступних процесів Apache для їх обслуговування. У моєму випадку я мав шар перекладу перед деякими веб-сторінками, але виклик API на власному веб-сайті - це те саме.

Характеристики браузера, який здійснює вихідний дзвінок, можуть зробити це більш імовірним. Наприклад, продовжуйте жити, тактику очікування та інше, але це не принципово, що браузер винен.

Якщо це щось на кшталт того, що я бачив, то ви хочете, щоб ви дивилися на поведінку в очікуванні, коли ви використовуєте curl. Код, який ви включили, пропонує вам зайнятися цим, але, можливо, вам доведеться бути більш чіткими в розумінні того, до якого саме пункту запиту він потрапляє. Це може бути цікаво подивитися на це за допомогою tcpdump (або ngrep, Wireshark чи будь-чого іншого). Також було б добре знати, який системний виклик триває, коли виклик зависає. Тобто подивіться на це strace -p [PID].

Напевно, ви також повинні замислюватися над тим, чи можете ви вилучити HTTP-дзвінок із використання API. Чи можете ви зберегти речі в межах одного процесу Apache, здійснивши прямий дзвінок у відповідний код, який обробляє запит API?

Мабуть, доречно розповісти людям, як ви працюєте з PHP (наприклад, mod_php, fpm тощо). Це може бути частиною розуміння механізму, за допомогою якого код блокується.


Це може допомогти при допиті внутрішніх служб
ProfVersaggi

Як експеримент, я відключив виклики API з циклу CURL і провів купу тестів. Це усунуло проблему, оскільки під час цих тестів дімон Apache2 залишався здоровим.
ProfVersaggi
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.