laravel-octane-notes.md

1. One of the benefits of Laravel Octane is the huge improvement in the response times to HTTP requests by clients such as web browsers. p.20

2. Laravel Octane, through application servers, does just that: optimizes the process of starting the framework, which typically happens for each individual request. We will see in detail how this is done; essentially, the objects and everything that the framework needs are started and allocated to the start of the application server, and then the instances are made available to the various workers. Workers are the processes that are initiated to serve the requests. p.20

3. some features of swoole application server: p.21 the advanced mechanisms of the cache driver, shared storage for sharing information between the various workers, and the execution of tasks in parallel.

4. the classical PHP approach is to have one dedicated thread to manage one request.

5. The PHP interpreter can be activated mainly in two ways: as a web server module or as a separate process.

6. if PHP interpreter activated as a separate process, a technology called FastCGI Process Manager (FPM) is used.

7. The components are called sequentially in the HTTP request flow. The HTTP request starts from the browser, then goes through the network (optionally passing through via the proxy), until it reaches the web server that invokes the PHP engine and the framework is bootstrapped.

8. برای پیاده سازی بهینه نرم افزار: For example, on the browser side, you could work on caching assets in the browser or on the optimization of your JavaScript code. On the networking side, one solution could be resource optimization, for example, reducing the weight of assets or introducing architectural elements such as a CDN. In the case of the web server, an effective first-level improvement could be to avoid loading the PHP engine for the static assets (non-PHP files).

other tip is optimization of the framework. For example, topics such as the use of Octane with tools such as Swoole and RoadRunner, which enable more efficient and effective loading of resources (shared objects and structures), are addressed. Other points of performance improvement on the framework side include the introduction of an asynchronous approach through the use of queuing systems. p.24

9. A request is mainly characterized by methods (GET, POST, PUT, and so on), the URL, and HTTP headers. p.25

10. A URL is made up of the protocol, the hostname, the port, the path, and the parameters. A typical URL is as follows: <protocol>://<hostname>:<port>/<path>?<parameters>

11. One of the characterizing elements of a typical request to a classic PHP application is that each request is independent of any other request. This means that if your PHP script instantiates an object, this operation is repeated with each request. This has little impact if your script is called only a few times and your script is simple.

12. In contrast to what happens with a classic web server, an application server has the task of starting and managing the executions of multiple workers. Each worker will be able to handle multiple requests by reusing objects and parts of the logic of your application. This has one benefit, which is that the actual startup of your application and the setting up of the various objects occur on the first request received from the worker and not on each individual request.

13. Laravel Octane, which handles server configuration, startup, and execution, integrates mainly with two of them: Swoole and RoadRunner.

14. At startup, Laravel Octane via Swoole or RoadRunner activates some workers.

15. Octane acts as a load balancer. When a request comes from the network, the application server will decide which worker (of those available) to assign the request to.

16. The use of static variables is not so unusual. Just think of singleton objects or the app container of Laravel.

17. how a classic laravel app works: In the classic web server scenario (without Laravel Octane), the life cycles of all objects related to your application, but especially to the objects automatically instantiated and managed by the framework, are confined to each individual request. In every single request, all the objects necessary for the framework to work are instantiated, and the objects are destroyed when the response is sent back to the client. This also explains and helps you understand why the response times in a classic framework with a web server are longer than the response times of an already initialized worker. p.58

18. With Laravel Octane, instead of RoadRunner, you can use another type of application server. In addition to RoadRunner, we can configure and use Swoole. Both tools allow you to implement an application server. Obviously, there are differentiating elements between the two tools, and sometimes deciding which one to use can be difficult.

19. Despite there being a greater complexity in the management of Swoole, Swoole offers benefits such as additional and advanced features, such as the management of an in-memory cache (benefits on performance), Swoole Table, which is a data store for sharing information between different processes (and facilitates information sharing and better cooperation between processes), and the ability to start asynchronous functions and processes at a specific interval (thus enabling asynchronous and parallel execution of functions)

20. What is PECL? PECL is the repository for PHP extensions. The PECL extensions are written in C language and have to be compiled to be used with the PHP engine.