Process models in web apps and mobile/desktop apps

Web applications use a different process model than mobile/desktop applications. Mobile/desktop apps have a process running until the user exits the app, they are typically stateful, meaning the application maintains its state as long as it is running. In contrast, web apps are generally stateless, meaning each request is independent, and the server does not maintain the state between requests. The server processes a request, sends a response, and then terminates the process handling that request. Multiple users accessing a web app will create multiple independent processes on the server. Web apps are designed to handle many short-lived processes. A web process is typically terminated after 300s (set in web server config) if it has not already sent a response.

REST (Representational State Transfer) is designed to be stateless. This means that each HTTP request from a client to a server must contain all the information needed to understand and process the request. The web server handles each request separately, delegating it to PHP, which terminates the process after the response is sent back to the client. This approach ensures scalability and efficiency, as the server can handle many requests from different users simultaneously. Scalability is achieved through load balancing and distributing requests across multiple servers or processes.

1. Request-Response Cycle: Each time a user interacts with your web app (e.g., by clicking on a product), the browser sends an HTTP request to the server.
2. Single Process Execution: When the server receives a request, it starts a new process or thread to handle that specific request. This process runs your PHP code, generates the necessary response (usually HTML), and sends it back to the browser.
3. End of Process: Once the response is sent back to the client, the PHP process or thread is terminated by the web server. The server does not maintain any long-running processes for individual users between requests.
4. No Inter-process Communication: Each request is handled independently, and PHP does not keep any information about previous requests in memory. Any necessary state information (like user sessions) is typically managed using session variables, cookies, or other storage mechanisms like databases or caching systems.
5. Session Management: To maintain state (like user login status, shopping cart contents, etc.), PHP uses session management. When a user clicks on a different product, the session data is used to retain the necessary information across multiple requests. When a session is started in PHP (using session_start()), PHP generates a unique session ID for that session. This session ID is then stored in a cookie on the client's browser. The actual session data (such as user information, preferences, etc.) is stored on the server, typically in files or a database. The session data is associated with the session ID. When the client makes subsequent requests to the server, the session ID stored in the cookie is sent along with the request. PHP uses this session ID to retrieve the corresponding session data from the server.

Note that PHP-FPM (PHP FastCGI Process Manager) uses FastCGI. Unlike CGI, which creates a new process for each request, FastCGI keeps processes alive and reuses them for multiple requests. This avoids the overhead of process creation and teardown. PHP-FPM runs a master process responsible for managing the worker processes. These processes are persistent and handle multiple requests over their lifetime. Each incoming request is assigned to an available worker process. After completing a request, the worker process becomes idle and waits for the next request.

Note about cPanel NPROC (nb. of processes): The NPROC limit in cPanel refers to the maximum number of processes that a single user can have running simultaneously. This includes all types of processes, not just web server processes (e.g., background scripts, cron jobs, etc.). While this can indirectly impact the number of concurrent connections your web server can handle, it doesn't directly translate to the number of concurrent connections. Your server might use a threaded model (like Apache's worker MPM or Nginx), where each process can handle multiple connections through threads. The NPROC limit then becomes less directly tied to the number of concurrent connections.

Music: Legendary Pakistani Singer goes Metal [Sanson Ki Mala Pe]