Denne adfærd lyder som sessionslåsning. Standard måden PHP-sessioner fungerer på er at låse sessionen (for at forhindre to processer i at skrive til sessionsobjektet). Dette er normalt fint for typiske kortlivede PHP-scripts, men det kan bide dig, når du har noget, der er langvarigt.
Hvis din applikation slet ikke bruger sessioner, skal du deaktivere session.auto_start i php.ini eller .htaccess:http ://www.php.net/manual/en/session.configuration.php#ini.session.auto-start
(Hvis du ikke kan se det der, eller det allerede er slået fra, men du bruger en form for ramme, kan rammen starte sessionen for dig; i så fald er det nemmere at gå til den næste løsning end at prøve at kæmpe rammerne.)
Hvis du bruger sessionen på nogle sider, men ikke på denne langvarige proces, er løsningen at lukke sessionen i starten af dit script med session_write_close() :
<?
set_time_limit(0);
require '../connect.php';
require '../includes/ses.php';
session_write_close();
$i = 1;
....
Igen, framework-advarslen:hvis frameworket starter en session for dig, så indsæt session_write_close(); efter at have inkluderet rammefilerne, ikke før! (Du nævnte, at det var tilfældet i dine kommentarer, og det er derfor, jeg har sat det efter kræve-linjerne.)
Hvis din langvarige proces skal bruge sessionen, men skrivebeskyttet, virker ovenstående stadig. Se https://stackoverflow.com/a/14409902/841830 (Som svaret viser, er det også muligt, hvis du har brug for at skrive til sessionen i slutningen af den langvarige proces.)
(P.S. Dette var allerede besvaret i kommentarerne, men jeg har taget Wrikken imod hans tilbud om at sende det som et svar. Ja, rygterne er sande:Jeg vil gøre alt for et par rep...)