Internet Explorer'ın uzun süre çalışan veri API'sı için PHP / CURL'u çağırmak için kullanılması Apache 2 sunucusunun donmasına ve yeniden başlatılmasına neden olur

10

Bir Microsoft Internet Explorer tarayıcısı tarafından çağrılmadığı sürece iyi çalışan bir PHP programı çalıştırıyorum, bundan sonra aşağıdaki süreçleri ortaya çıkarıyor, Apache 2'yi kilitliyor ve web sunucusunun (Ubuntu 12.04 LTS'de) yeniden başlatılmasını gerektiriyor.

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

Ben "bazı değişti kadar bütün sunucuyu kilitlemek için kullanılan mpm_ daha makul bir şey için" modül parametreleri /etc/spache2/apache2.conf .

Internet Explorer ile ilgili sorunlar göz önüne alındığında, bu satırı bile ekledim:

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

Burada bulunan sanal ana bilgisayarlar dosyasında: / etc / apache2 / sites-available.

Bu konuda yazılmış birçok makale var, ancak bunlardan hiçbirini uygulayamadım:

Apache Server 2, IE 10/11'den istek aldıktan sonra takılıyor :

Daha Fazla Ar-Ge: Apache'nin çökmesine neden olan Internet Explorer 10 (Windows 8)

PHP programı , 25 öğenin bir listesini almak ve daha fazla işlem için JSON verilerini döndüren harici bir sunucuya (GET) API çağrısı yapmak için cURL kullanır . Klasik, uzun soluklu bir veri programı.

Noodle'ımı pişiren şey, Internet Explorer dışındaki diğer tüm tarayıcılarda iyi çalışması - bu da web sunucusunun yanlış davranmasına neden oluyor.

Listelenen Ar-Ge'yi sorguladım ve sonra bazıları önerilen düzeltmeleri uyguladım, ancak yine de aynı öngörülebilir, yeniden oluşturulabilir, sorunlu sunucu davranışını alıyorum.

Sunucunun karşılaştığında kötü davranmaya karşı nasıl korunacağını ve Internet Explorer tarayıcısının bu belirli istekleri yapmasını anlamaya ihtiyacım var. İlk etapta neden olduğunu anlamak istiyorum.

Herhangi bir rehberlik, perspektif, yön veya çözüm çok takdir edilecektir ...

İşte benim cURL kodumun bir anlık görüntüsü:

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

?>

İşte PHP bilgi sayfası: http://www.versaggi.net/phptest.phtml

apache-2.2  php  internet-explorer  curl 
— ProfVersaggi
kaynak
1
Bence bir şekilde hem IE'den hem de sorun olmayan başka bir tarayıcıdan gelen HTTP isteklerini tam olarak günlüğe kaydetmeniz gerekiyor, böylece onları karşılaştırabilir ve farklılıkları arayabiliriz. Bunu nasıl yapabileceğiniz hakkında lütfen bu soruya göz atın . IE'nin HTTP isteği ile yaptığı bir şey olmalı (bazı ekstra veya eksik üstbilgiler vs.?) Apache'nin farklı davranmasını sağlar. Ya bu, ya da daha düşük (IP paketleri) düzeyinde, umarım umarım.
— Stijn de Witt
Sorunuz için biraz dikkat çekmenize yardımcı olmak için bir ödül koydum.
— Stijn de Witt
2
Biraz daha düşünerek, muhtemelen bunu bir hata olarak Apache'ye bildirebilirsiniz ... Çünkü gerçekten bunu Apache hatası olarak açıklayamamın bir yolu yok. Bu, soruna bakmak için çok deneyimli bir Apache gurusu almanıza da yardımcı olabilir (ve umarım düzeltir). Bu rotaya gitmek istiyorsanız, sorunu yaşayan sayfayı hala sorunu olan olası en küçük senaryoya küçültmeniz yardımcı olabilir. Bu zaten kendi başına yardımcı olabilir.
— Stijn de Witt
Setopt kullanarak kıvırmak bir zaman aşımı ayarlamak
— user1050544
3
İstemcinin php komut dosyası tarafından erişilen URL'ler üzerinde herhangi bir etkisi var mı? Sunucuyu yukarıdaki durumda bulduğunuzda cURL istekleri devam ediyor mu? IE çok yavaş yanıt verirken istekleri yeniden deniyor olabilir mi? Web sunucunuza gelen her HTTP isteği, bir arka uca başka 25 HTTP isteği başlatmasına neden olabilirse, bu oldukça hızlı bir şekilde yükselebilir. CURL ile aldığınız yanıtları birden fazla müşteri için tekrar kullanabilir misiniz?
— kasperd

Yanıtlar:

5

Uzun zaman önce, aynı sunucuda bir Apache işlemi tarafından hizmet verilen başka bir URL'ye HTTP üzerinden çağrı yapan bir Apache işleminden kaynaklanan Apache kilitlenmelerini gördüm. Bazen, bu tür çağrıları bekleyen hiçbir Apache işlemi olmadan onlara hizmet edecek bir sürü süreçle yaralandım. Benim durumumda, bazı web sayfalarının önünde bir çeviri katmanım vardı, ancak kendi sitenizde bir API çağırmak aynı şey.

Orijinal aramayı yapan tarayıcının özellikleri, bunun gerçekleşme olasılığını artırabilir. Örneğin, canlı tutma, zaman aşımı davranışı vb. Ancak temelde tarayıcı hatalı değildir.

Gördüğüm gibi bir şeyse, kıvırma kullanımınızdaki zaman aşımı davranışına bakmak istiyorsunuz. Eklediğiniz kod, bunun üzerinde olduğunuzu gösterir, ancak isteğin tam olarak hangi noktaya ulaştığına dair anlayışınız konusunda daha ayrıntılı olmanız gerekebilir. Buna tcpdump (veya ngrep, Wireshark veya başka bir şey) ile bakmak ilginç olabilir . Ayrıca, arama işlemi askıya alındığında hangi sistem çağrısının devam ettiğini bilmek de iyi olur. Yani, şuna bak strace -p [PID].

Muhtemelen, HTTP çağrısını API kullanımınızdan kaldırıp kaldıramayacağınızı da düşünmelisiniz. API isteğini işleyen uygun koda doğrudan çağrı yaparak işleri aynı Apache sürecinde tutabilir misiniz?

Muhtemelen insanlara PHP'yi nasıl çalıştırdığınızı söylemek önemlidir (örn. Mod_php, fpm, vb.). Bu, kodun kilitlenme mekanizmasını anlamanın bir parçası olabilir.

— mc0e
kaynak
Bu, PHP'nin içindekilerin sorgulanmasına yardımcı olabilir ... versaggi.net/phptest.phtml
— ProfVersaggi
Bir deneme olarak CURL döngüsünden API çağrılarını devre dışı bıraktım ve bir sürü test yaptım. Bu sorunu testlerde olduğu gibi izole eden Apache2 deamon sağlıklı kaldı.
— ProfVersaggi
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.