Leaderboard

You probably saw the behavior you did due to using sessions. When you start a session PHP will lock the session data so that it's not affected by other processes. This lock exists until you either call session_write_close or the process ends. So if you're long-running process doesn't need to update any session data, call session_write_close prior to starting it. That said, lots of concurrent long-running processes could block a server. Your HTTP server will process each request using a thread or worker process (depends on the configuration). I'll only spin up a certain number of these based on the configuration and if that limit is reached it'll stop responding to requests. Your long-running processes would tie up some of these threads. The number of threads available on an actual server will probably be relatively high though, so unless you expect a lot of these processes to be running concurrently it likely won't be an issue. If the server is setup with something like PHP-FPM or a CGI setup though, the number of allowed PHP instances may be smaller. You limit would be the smaller of the the http server's limits or PHP's limits. If you want to keep your site responsive though, the way to manage that would be to offload the work to a background process so that your website can continue to respond to requests. The user would then go to the page which would trigger the processing and you would respond with a message like "We're working on your request, check back in a bit". When the process is complete give the user the results. There are many ways to accomplish this, such as using services like redis, gearman, beanstalkd, etc or simply adding records to your database and having a background service checking for new records periodically.

Not even remotely the case. Locally, were you using the built-in server that PHP provides? Don't. It's good for quick stuff but it's not a real server. Set up your development environment to match your production environment as closely as possible.