Download the PHP package phphleb/webrotor without Composer

## Overview Shared hosting environments often come with significant limitations compared to dedicated servers. However, those limitations shouldn't stop you from experimenting with multi-threaded and asynchronous servers! **WebRotor** is a specialized web server designed for asynchronous request handling on shared hosting. It is easy to install and configure. *Important:* Before using, make sure to review the requirements for your code to execute asynchronously. Most frameworks include guidelines and recommendations for enabling asynchronous functionality. With this library, applications built on frameworks like `Laravel`, `Symfony`, `Yii3` and others that support asynchronous processing, along with any other asynchronously written code, can operate in this mode on various shared hosting platforms. _It makes sense to move a project to asynchrony if it has performance problems or you want to experiment with asynchrony._ --- ## Installation Use [Composer](https://getcomposer.org/): Next, you need to install one of the PHP HTTP client implementations for PSR-7. [Nyholm](https://github.com/Nyholm/psr7): ` or [Guzzle](https://github.com/guzzle/guzzle/): ` ## Shared Hosting ### Modifying the Index File Typically, shared hosting environments have a public folder containing an index file, usually named `index.php`. It is necessary to modify this file so that your application's code is enclosed within an asynchronous loop. You can find examples of how to connect to an asynchronous server in the documentation for the framework you are using. In a simplified manner, this looks like: ## Launching Workers Now for the fun part! :) Shared hosting is unlikely to allow you to daemonize processes, but we will use the built-in cron (or its equivalents). First, find the section in your hosting admin panel named something like "Task Scheduler" or "crontab." A simple example would be launching two workers, each with a lifespan of two minutes. We'll use the same index file (`index.php`) as our worker, specifying the worker number. The following example shows two workers that launch every two minutes with a one-minute offset. The implementation can vary depending on your hosting settings, but if you encounter any issues, try using just the first example, or contact your hosting support and show them this example. Workers can number more than two, and the restart time may vary based on specific load and available server resources. ## Configuration In the previous example, we indicated that two workers are running with a two-minute interval between them. Now, it’s essential to modify this in the web server settings, as it defaults to one worker restarting every minute. Here's how to do that: By default, web server logs are stored above the public directory in the `wr-logs` folder. ## Working with Sessions, Cookies, and Files in Asynchronous Mode Asynchronous mode has its own specific characteristics since the request is handled by a worker within a single thread inside the standard loop. As a result, additional attributes are passed through a created object that implements the `ServerRequestInterface`. ## Example for Laravel 11.x An example of basic initialization for `Laravel` 11.x can be found in this repository in the `examples/frameworks` folder. ## Virtual Server or Dedicated Server With broader access to the server environment, there's the potential to replace the current worker data storage with a Redis-based storage to maximize performance. An example of such a setup can be found in the `examples` folder. ## Local Development For local development, there's no need to modify the previous setup. Simply run the following command from the project's public directory: This will initiate a single worker for the duration specified in the configuration. If the worker is not running or has been disabled, your project will still function, but requests will be processed in the standard, non-synchronous mode. As a result, using workers is optional for local development. ----------