Sử dụng Internet Explorer để gọi PHP / CURL cho API dữ liệu chạy dài khiến máy chủ Apache 2 bị đóng băng và yêu cầu khởi động lại


10

Tôi đang chạy một chương trình PHP hoạt động tốt miễn là nó không được trình duyệt Microsoft Internet Explorer gọi, sau đó nó sẽ sinh ra các quy trình dưới đây, khóa Apache 2 và yêu cầu khởi động lại máy chủ web (trên 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

Nó được sử dụng để khóa toàn bộ máy chủ cho đến khi tôi thay đổi một số tham số mô-đun " mpm_ " thành một cái gì đó hợp lý hơn trong /etc/spache2/apache2.conf .

Do các vấn đề với Internet Explorer, tôi thậm chí đã thêm dòng này:

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

trong tệp máy chủ ảo nằm ở đây: / etc / apache2 / sites-Available.

Có một số bài báo viết về vấn đề này, nhưng tôi đã không thành công khi thực hiện bất kỳ bài viết nào:

Máy chủ Apache bị treo sau khi nhận được yêu cầu từ IE 10/11 :

R & D khác: Internet Explorer 10 (Windows 8) gặp sự cố với Apache

Chương trình PHP sử dụng cURL để lấy danh sách 25 mục và thực hiện lệnh gọi API (GET) cho mỗi máy chủ bên ngoài trả về dữ liệu JSON để xử lý thêm. Đây là một chương trình dữ liệu chạy dài cổ điển.

Điều làm cho mì của tôi là nó chạy tốt trong mọi trình duyệt khác ngoại trừ Internet Explorer - nguyên nhân khiến máy chủ web hoạt động sai.

Tôi đã thẩm vấn R & D được liệt kê và sau đó một số, đã triển khai các bản sửa lỗi được đề xuất, nhưng tôi vẫn nhận được cùng một hành vi máy chủ có vấn đề, có thể tái tạo, có thể dự đoán được.

Tôi cần tìm ra cách bảo vệ máy chủ khỏi hành vi xấu khi gặp phải và trình duyệt Internet Explorer thực hiện các yêu cầu cụ thể này của nó. Tôi muốn hiểu tại sao nó xảy ra ở nơi đầu tiên.

Bất kỳ hướng dẫn, quan điểm, định hướng hoặc giải pháp sẽ được đánh giá cao ...

Đây là một ảnh chụp nhanh mã cURL của tôi:

<?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);

?>

Đây là trang thông tin PHP: http://www.versaggi.net/phptest.phtml


1
Tôi nghĩ rằng bạn cần phải bằng cách nào đó đăng nhập đầy đủ các yêu cầu HTTP đến từ cả IE và một số trình duyệt khác không có vấn đề gì để chúng tôi có thể so sánh chúng và tìm kiếm sự khác biệt. Xin hãy xem câu hỏi này để biết cách bạn có thể làm điều đó. Phải có một cái gì đó IE thực hiện với yêu cầu HTTP (một số tiêu đề bổ sung hoặc thiếu, v.v.) dẫn đến việc Apache xử lý nó theo cách khác. Hoặc là, hoặc nó ở mức thấp hơn (gói IP), điều mà tôi chắc chắn không hy vọng.
Stijn de Witt

Tôi đặt một tiền thưởng cho nó để hy vọng giúp bạn chú ý đến câu hỏi của bạn.
Stijn de Witt

2
Nghĩ thêm về nó, có lẽ bạn có thể báo cáo vấn đề này với Apache như một lỗi ... Bởi vì thực sự không có cách nào tôi có thể giải thích điều này vì đây không phải là lỗi của Apache. Điều đó cũng có thể giúp bạn có được một số chuyên gia Apache có kinh nghiệm để xem xét vấn đề (và hy vọng sẽ khắc phục nó). Nếu bạn muốn đi theo con đường đó, có thể hữu ích nếu bạn thu nhỏ trang gặp sự cố theo kịch bản nhỏ nhất có thể vẫn có vấn đề. Điều này có thể hữu ích trong và dù sao đi nữa.
Stijn de Witt

Đặt thời gian chờ trong curl bằng setopt
user1050544

3
Máy khách có bất kỳ ảnh hưởng nào đến các URL đang được truy cập bởi tập lệnh php không? Các yêu cầu cURL vẫn đang tiếp diễn khi bạn tìm thấy máy chủ ở trạng thái trên phải không? Có thể là IE đang thử lại các yêu cầu khi chúng phản hồi quá chậm? Nếu mỗi yêu cầu HTTP đến máy chủ web của bạn có thể khiến nó bắt đầu 25 yêu cầu HTTP khác đến một phụ trợ, điều đó có thể leo thang khá nhanh. Bạn có thể sử dụng lại các phản hồi bạn nhận được với cURL cho nhiều khách hàng không?
kasperd

Câu trả lời:


5

Cách đây rất lâu, tôi đã thấy các khóa của Apache xuất phát từ một quy trình Apache thực hiện cuộc gọi qua HTTP đến một URL khác được phục vụ bởi một quy trình Apache trên cùng một máy chủ. Đôi khi tôi gặp phải một loạt các quy trình đang chờ trong các cuộc gọi như vậy mà không có các quy trình Apache có sẵn để phục vụ chúng. Trong trường hợp của tôi, tôi đã có một lớp dịch trước một số trang web, nhưng việc gọi API trên trang web của riêng bạn cũng giống như vậy.

Các đặc điểm của trình duyệt thực hiện cuộc gọi ban đầu có thể làm cho điều này có nhiều khả năng xảy ra. Ví dụ, hành vi sống còn, hết thời gian và vv, nhưng về cơ bản, trình duyệt không có lỗi.

Nếu đó là bất cứ điều gì giống như những gì tôi thấy, thì bạn muốn xem xét hành vi hết thời gian trong việc sử dụng curl của bạn. Mã bạn bao gồm gợi ý bạn về điều đó, nhưng bạn có thể cần phải tinh tế hơn trong sự hiểu biết của bạn về chính xác điểm nào trong yêu cầu mà nó nhận được. Nó có thể thú vị khi nhìn vào nó với tcpdump (hoặc ngrep, Wireshark , hoặc bất cứ điều gì). Ngoài ra, thật tốt khi biết cuộc gọi hệ thống nào đang diễn ra khi quá trình gọi bị treo. Đó là, nhìn vào nó với strace -p [PID].

Có lẽ bạn cũng nên suy nghĩ về việc liệu bạn có thể xóa cuộc gọi HTTP khỏi việc sử dụng API hay không. Bạn có thể giữ mọi thứ trong cùng một quy trình Apache bằng cách thực hiện cuộc gọi trực tiếp tới mã thích hợp xử lý yêu cầu API không?

Có lẽ có liên quan để nói với mọi người về cách bạn đang chạy PHP (Ví dụ: mod_php, fpm, v.v.). Đó có thể là một phần của việc hiểu cơ chế mà mã khóa.


Điều này có thể giúp với việc thẩm vấn các phần bên trong PHP ... Versaggi.net/phptest.phtml
ProfVersaggi

Như một thử nghiệm, tôi đã vô hiệu hóa các lệnh gọi API từ vòng lặp CURL và chạy một loạt các thử nghiệm. Điều đó đã cô lập vấn đề như trong các thử nghiệm đó, deamon Apache2 vẫn khỏe mạnh.
ProfVersaggi
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.