PHP time out

Scriptcase 9 General
#1

I have a rather long program that runs. Oddly if I run it from the production server (using the regular domain name, not localhost), it runs without time out. If I run from any other PC, it does a time out and stops. I have everything set for as long an execution as possible. Would dividing up the stored proc running (mysql) into calling different procedures reset this or is it purely browser/server interaction that keeps it alive? Any way to lie to it that I’ve pressed something?

#2

I ran into a very similar issue with a long-running process in Scriptcase: when I ran it directly on the server it never timed out, but from other PCs it would.

In my case I realized there were several possible causes/paths to check, and I went through them one by one. Here are some ideas you might explore on your side:

  1. PHP / web server / proxy timeouts
    Check max_execution_time in PHP / Scriptcase, and also the timeouts on the web server (Apache/Nginx, PHP-FPM) or any proxy/firewall between the browser and the server. Sometimes localhost doesn’t hit the same limits as when you go through the domain.
  2. Split the process into shorter steps
    Instead of one single button that runs the entire big procedure, break it into several shorter steps (or AJAX calls) that run in sequence. Internally you can call different stored procedures or parts of the same one, but each HTTP request is shorter and less likely to hit a connection timeout.
  3. Keep the session alive (keepalive)
    If the Scriptcase session is expiring while the user is waiting, you can add a small JavaScript that sends an AJAX request every X minutes to a simple “keepalive” app to prevent session timeout. This doesn’t fix a long execution timeout, but it helps avoid being logged out due to “inactivity”.
  4. Move the heavy work to background
    Another option is to trigger the long process in the background (cron, queue, external script). The app only registers the request and then shows progress or results when the user reloads or checks the status. That way the heavy part doesn’t depend on a single long web request.

Those four directions helped me understand where the real bottleneck was. Maybe one of them gives you a good starting point in your case.

1 Like