2012-06-29 15 views
5

To nie jest jedno z normalnych pytań, jeśli sen jest wliczany do limitu czasu lub podobnych rzeczy. Ok, oto problem: Ustawiłem max_execution_time dla PHP na 15 sekund, a najlepiej powinno to przekroczyć ustawiony limit, ale tak nie jest. Apache został zrestartowany po zmianie pliku php.ini, a ini_get ("max_execution_time") jest w porządku. Czasami skrypt działa do 200 sekund, co jest szalone. Nie mam żadnej komunikacji z bazą danych. Cały skrypt szuka plików w systemie plików unix, a w niektórych przypadkach przekierowuje na inną stronę JSP. Na skrypcie nie ma uśpienia().PHP max_execution_time nie limit czasu

obliczyć całkowity czas wykonywania skryptu PHP tak:

Na początku skryptu I set:

$_mtime = microtime(); 
$_mtime = explode(" ",$_mtime); 
$_mtime = $_mtime[1] + $_mtime[0]; 
$_gStartTime = $_mtime; 

i czas zakończenia ($ _ gEndTime) oblicza się w podobny sposób.
Całkowity czas obliczany jest w funkcję wyłączania, że ​​już zarejestrowany:

register_shutdown_function('shutdown'); 
............. 
function shutdown() 
{ 
    .............. 
    .............. 
    $_total_time = $_gEndTime - $_gStartTime; 
    .............. 
    switch (connection_status()) 
    { 
    case CONNECTION_NORMAL: 
     .... 
     break; 
     .... 
    case CONNECTION_TIMEOUT: 
     .... 
     break; 
     ...... 
    } 
} 

Uwaga: nie mogę użyć $ _SERVER [ „REQUEST_TIME”] bo moja wersja PHP jest niezgodna. To jest do bani - wiem.

1) Cóż, moim pierwszym pytaniem jest oczywiście, dlaczego mój skrypt PHP działa nawet po ustawionym limicie czasu?
2) Apache ma dyrektywę Timeout, która wynosi 300 sekund, ale plik binarny PHP nie odczytuje konfiguracji Apache i nie powinno to stanowić problemu.
3) Czy istnieje możliwość, że coś wysyła PHP do trybu uśpienia?
4) Czy obliczam czas wykonania w niewłaściwy sposób? Czy jest lepszy sposób to zrobić?


Jestem zaskoczony w tym momencie. Wizards PHP - proszę o pomoc.

Edytuj: Właśnie dowiedziałem się, że operacje strumieniowe nie są przyczyną kilku dzienników. Opóźnienie jest po prostu losowe w skrypcie, nawet jeśli nie są wykonywane żadne operacje przesyłania strumieniowego. Przełączanie kontekstu może być właśnie powodem. Ale nadal nie mam jasnej odpowiedzi. Spojrzałem w górę Real max_execution_time for PHP on linux, ale nie jestem pewien, czy chcę to wypróbować. Jakieś inne sugestie?

+0

Uważam, że operacje systemu plików również nie są uwzględniane w obliczeniach limitów czasowych. – lonesomeday

+1

Wiesz, możesz użyć 'microtime (true)', aby uzyskać 'float' z powrotem ... – deceze

+0

@lonesomeday: Jesteś tego pewien? –

Odpowiedz

7

max_execution_time tylko limity script czas wykonanie siebie - czasu procesora swojego skryptu. jeśli kontekst systemu operacyjnego przełączy się na inny proces i spędził tam trochę czasu, nie będzie on również liczony. Tak więc pomiar czasu rzeczywistego i oczekiwanie przekroczenia limitu czasu po 30 sekundach nie będzie prawdą w danym momencie. I oczywiście, to pomija jakikolwiek system, exec lub czasy sieciowe oraz

+2

Rzeczywiście ... Nawet oczekiwanie na zapytania DB lub obsługę strumieni danych zostało pominięte w równaniu – Johan

+0

prawda, zapomniałem wspomnieć o db stuff;) dziękuję! – poncha

+0

Nie mam żadnych połączeń systemowych, wykonawczych, ani też nie wzywam żadnego zewnętrznego kodu. Czy operacje systemu plików są zliczane w ramach limitu max_execution_time? Powiedzmy, fopen() –

0

Jeśli potrzebujesz przerwy, po pewnej długości czasu (zgodnie z komentarzy), dlaczego nie nazwać

$startscript = microtime(); 

//do some stuff 

if (microtime() - $startscript > 1500) 
{ 
    dotimeout(); 
} 


    // do more stuff 

if (microtime() - $startscript > 1500) 
{ 
    dotimeout(); 
} 

    // do more stuff 

if (microtime() - $startscript > 1500) 
{ 
    dotimeout(); 
} 

Otrzymasz jist. Niezbyt ładna, ale może działać.

+0

Może to zadziałać, gdy będę wiedział, gdzie są opóźnienia. Ale w moim przypadku opóźnienia są przypadkowe. A więc na przykład: jeśli pierwsze sprawdzenie zostanie zaliczone, a funkcja microtime() - $ startscript będzie mieć wartość <1500, a jeśli opóźnienie nastąpi tuż przed wywołaniem drugiego czeku, to znowu ta sama historia. Dzięki i tak ...! –