Laravel Application Now that we have the Laravel application running on Octane, let's dive into the details. As we mentioned, Octane starts a number of php processes to handle incoming requests. Each process can handle a single request at any given time. So the maximum of concurrent requests your application can handle is limited by the number of processes that you start on your machine, which is similar to how PHP FPM works. However, because the application is bootstrapped

which is similar to how php-fpm works. However, because the application is bootstrapped and loaded in memory only once, you will be able to handle requests faster and thus increase the throughput. When we run the octane start command, multiple processes are started on our system. We have the octane process, the swoole master process, the swoole manager process,

the swool master process, the swool manager process, and then one process for each php worker we want to start. Let's go check this out. The octane process starts the swool master process in the background and reads any output returned by it, and prints that output. This allows us to see logs on every request handled by swool and any errors returned. The swool master process creates multiple threads

By default, octane starts a number of processes that is equal to the number of CPU cores your machine has. You can configure the number of processes using a command line option of the octane start command. Now, when a worker starts, octane will create a fresh instance of the Laravel application and bootstrap it and register some instances into its container. These instances are octane-specific objects that are needed by the Laravel application to communicate with the different swoole services.

that are needed by the Laravel application to communicate with the different swoole services. It is also possible to configure a list of custom services to warm up on the worker's booting phase. You can do that from within the octane.php configuration file. Let's scroll down. And then under the warm attribute, we may register an array of services we want to warm up. Octane already registers multiple services here which are warmed by default,

Octane already registers multiple services here which are warmed by default, like the authentication service, the cache service, the configuration service, and so on. Now, back to our start sequence. And so during the application bootstrapping phase, all framework and application service providers register and boot methods are called. This is no different than bootstrapping a Laravel application running on php FPM.

This is no different than bootstrapping a Laravel application running on php FBM. However, any services that you register as singleton in your server's providers that are resolved in the boot method in any of the providers will live in the application container for the entire duration the worker is up and will be shared between requests. So what does that mean to you? We will look into practical examples in a future lesson, of course.

So what does that mean to you? We will look into practical examples in a future lesson, of course. For now, as you can see, Octane starts your Laravel application even before the first request reaches the server. The service container of your application will have several instances or several singletons resolved and ready for use by the time any request is received. These singletons instances will also be reused for every request handled by the Octane server, which enhances the performance.

for every request handled by the Octane server, which enhances the performance as some services are very expensive to create. Creating them once and reusing them for all requests speeds up the request handling part. This comes at a cost though, like everything, everything comes at a cost and we will look into this later in this course. For now, let me share another special aspect of Octane. In Laravel, there are service providers that can be marked as deferred.

For now, let me share another special aspect of Octane. In Laravel, there are service providers that can be marked as deferred. These providers won't be loaded unless any of the services they provide is needed. This is a feature that enhances the application performance so you don't pay the price of registering a provider while none of its services are needed to handle a certain request. In Octane, deferred providers are registered and booted during the worker boot sequence. They won't be deferred like in a regular application.

and booted during the worker boot sequence. They won't be deferred like in a regular application running under php fpm. Now, let's have a quick recap of what we have so far. We have multiple php processes running. Each one of these processes has a Laravel application kept in memory and each Laravel application has a service container with multiple singletons already resolved. The Octane objects, the ones that facilitate communication between the Laravel application and Octane services,

The Octane objects, the ones that facilitate communication between the Laravel application and Octane services, and the default framework objects, ones that get warmed up by default, and any custom objects that you register for warming in the Octane configuration file, and finally, singletons that are resolved in the boot method of service providers. All the application service providers are loaded into the container, including providers that are marked as deferred.

All the application service providers are loaded into the container, including providers that are marked as deferred. With all that in mind, let's see how Octane handles requests using this instance of the Laravel application that is already loaded in memory. And that's the topic of our next lesson. Stay tuned.