 Okay, let's start. Good morning. I'm Luca. I'm from Italy. I work for a Drupal shop in Milan, Italy. Here, some of my account page on Drupal.org and Twitter. And I'm a maintainer of a couple of Drupal 8 modules, Web Profiler and XhProof, and some other modules for Drupal 7. And I'm in the organization of the Italian Drupal Day, this winter, and next year, the Drupal Dev Days in Italy. And in this session, we will see how Drupal 8 builds the web pages. And you may already know that all Drupal 8 pages are built in the same way. Okay, if you have a node page or an admin page, view page, user profile page, all of those follows the same life cycle. Okay, a request is received and Drupal will return a response. So in this session, we go through all the layers that the HTTP request passes through and how it builds the HTTP meta response at the end of the journey. Okay, to get the most out of this journey, I suggest you disable for understand how Drupal works, I suggest you disable the default caches and optimization made by Drupal 8 by default. In Drupal 8, all the performance optimization are turned on by default, so we have to disable. And you can do that in a simple way. You have to decrement a couple of lines in settings.php file that import the settings.local.php file that disable a lot of caches, JavaScript and CSS aggregation and so on. But to analyze how Drupal 8 in this case works, it's better if you can use a tool that give us an in-depth insight into how the different subsystem works and interact. So exist a module for Drupal 8, it's called Web Profiler, I'm the maintainer. That is based on the Symfony Profiler, if you ever use the Symfony full stack application at the bottom of every HTML pages, you have a toolbar with a lot of widgets that show you a lot of information about every page. And Web Profiler is useful to analyze the performance of a response, so you can analyze the number of queries, time, memory, and a lot of other information. But it's also useful to analyze how the system works under the hood. In this session, we will use the 2.0 beta-15 version of Web Profiler, which is compatible with the Drupal Core beta-15, okay? And when you enable Web Profiler on your website, it starts to collect and save a lot of useful information about every generated page, both the get or post requests to your website. And profiles goes to the database by default, but it can also store to the file system. You have to, you can choose where to store the profile. And like in Symfony, preview of those collected data is printed in a toolbar at the bottom of every HTML page. And on this toolbar, there are a number of widgets, depending on the number of data collectors you have enabled on your system. And when you click on those widgets on the toolbar, you go to the dashboard. Dashboard is a backbone power and application, so it's very responsive. And in the dashboard, you have access to all the collected information. Okay, Web Profiler is a model like every other Drupal module, so you can install it with the method you prefer. It has only a couple of JavaScript dependencies that are not mandatory, but are useful for showing more information. D3.js for the timeline, we saw the timeline, we will see the timeline in a couple of minutes. And the highlight.js to highlight the syntax of the JavaScript, the database queries. So we can use the Drupal console module for example, Drupal console project, for example, for enable Web Profiler on our website. And if we reload our page, we have this toolbar at the bottom of every pages of our website. Okay, in this session, we will see only a subset of the all available widgets. So we disable, we turn off the one we doesn't use, configuration of Web Profiler are available both from the configuration menu of the Drupalator or directly from the toolbar on the first widget on the left, you can click on configure Web Profiler to go to the configuration page. Okay, here we have a lot of settings. You can choose to delete of the profiles when you clear the cache. You can choose the storage backend. Now we have file storage and database storage. There is a patch on the issue queue to enable the elastic search storage backend. We can exclude some path from profiling. And then we have a list of all available data collectors and we can turn on only the one we will see in this presentation. So we leave on assets, blocks, cache, database, events, extensions, forms, requests, routing services, theme and timeline. Then you can configure an ID, link to open file directly in your editor. We will see how this works. And then you have some configuration for the database widget. You can choose to display the queries by source or by duration or highlight the slows query. Queries, okay, save configuration, okay. So, let's start. Okay, the first chapter of this journey through the request of an HTTP request through Drupal starts with a single file, index.php, which is the front controller of Drupal. It's a bunch of line of code that every single request, it's when it arrives to a Drupal website. On those files, the first thing we import, use a couple of classes. Then we require the autoloader from Composer. And then we build an instance of the Drupal kernel, which is the Drupal version of the HTTP kernel of Symphony that handle the request and turns it to a response. Then we build a request object, a symphony request object from global super arrays in PHP like get server, cookie, files and so on. And then the kernel handles the request and turn it into a response, okay. The response will be sent to the browser and the process terminates. The interesting part of this file is the handle method of the kernel class. And in the next few chapters, we will see how this method works coordinate of the different subsystems to build the response. But before entering the kernel, the request passes through a set of layers called middleware. And those layers can decorate or alter the request before it reaches the kernel. It reaches the kernel. And the number of layers and the order of those layers depends on what modules you have enabled on your website. So the request arrives to your website, it cross all the layers, then reach the kernel. The kernel turns the request in a response. The response recross all the layers in the same order. And then it is returned to the browser. Okay, every layer of this stack middleware has a priority and the request passes through. Each of them in order, from the highest priority to the lowest priority. And we can start using web profiler here to look into this stack and see all the layers and their priority. The middleware information are in the services widget on the middleware tab. So we can go to the homepage. This is a Drupal 8 beta 15 website. You can click on the services widget on the toolbar, the one with the puzzle. And here we saw a list of all the middleware that are configured in this website from the highest priority to the lowest priority. So the first layer that the request eats is the negotiation, which decides if the request was an HTML request and Ajax request and so on. Then we have the web profiler middleware that starts the query logger. Then we have the reverse proxy, page cache, kernel pre-handler and the session layer. In a lot of part of the web profiler dashboard, when we have a class or a method, we can click directly on the link and if you have configured your editor correctly, it's open on the exact method of the class. So for instance, this is the web profiler middleware. And here we only start the database query logger, the same for the others. Okay, the next thing that our request eats after crossing all the stack middleware layers is the routing process. During the routing process, the request is ready to be routed and Drupal has to figure out the piece of code that handle it and convert it into something else. This project is called routing and allows Drupal to understand which controller will handle the request, so which controller classes and method will handle the request. So we can see an example here. We can use the examples for developers module, which has a sub-module called page example that implements a couple of pages. You can read also from the end of the room. Okay, here we have a simple page example and we can see which route controller is used for build this specific page. We have a request widget on the toolbar which shows us the status of the HTTP response. In this case, it is a 200 okay response. We see, we saw the route name, every route in Drupal has a unique identifier. In this case, it was a page underscore example underscore simple. If we click on the widget, we go to the dashboard to the request pane and we can see that the route was a page example simple and the controller class is a page example controller and the method was the simple method of this class. So we can, for example, click here to see what the controller method does. Okay, web profiler has another widget called routing which shows us every route defined on our system. So if you're looking for a specific route, you can use this widget to understand the route ID and the path and before calling the controller, the routing system uses some access control to determine if the user cannot access that specific route and on the request widget under the access check section, we can see that the example, page example simple path needs some permissions to, the user needs to have a specific permission to access this page. And we can look at the routing file when where this information is defined and we know that this route is provided by the page underscore example module to discover where this module is installed in our system. We can go to the extensions widget and look for page underscore example module here and we can click on the info file link to go to the info file of this module. In the same folder of the info.yaml file of every module, we have a routing yaml file which describes all the route in this module, for example. And we have here the definition of the page we just saw, the route ID is page underscore example underscore simple and the permission, the requirements, so the access is based on a permission, so Drupal uses the access check.permission service to determine if the user cannot access this resource, this page. Okay, examples for developers in this page example module as another example, more complex, more interesting. The on the arguments page link we can see a parametric URL. So in this case, the path of this page has some arguments in it. The definition is this, so the page underscore example underscore arguments route has a path example, page example arguments first and second and these are the arguments that arrives to the controller method and based on the values you have on the URL, so in this case the routers of arguments in it first and second and we can see the values of those arguments in the request widgets of web profiler and then we can see that those arguments arrives to the controller method in a couple of arguments which have the same name of the variables on the path definition. So we have a first argument and second argument. Okay, so here in this case we have that the first value was 33, second was 56 and if we look at the definition of the controller method we saw the same arguments first and second that the controller uses to build the contents of the page because the path was examples of page example arguments 23, 56. Okay, in some case the parameters were upcasted before reaching the controller. For example, when you go to the node slash one, for example, root, the controller does not receive one as parameter but it receives the node object that corresponds to the node ID one. All of this is done automatically for you by the entity system in this case and in web profiler we can see that if we, this for example is a node page. In this case it's node 20. If we go to the request widget of this page we can see that the node arguments that is passed to the controller is a node object and not the one value. Okay, and when the page you are, the page you have is a form. Usually, for example the site information page, usually the controller used is always the same which is HTML form controller. So if we go to the site information page for example, a controller that builds this page is HTML form controller in all cases. If we want to discover the effective code that builds this form, we can use another widget on the toolbar, the form widget, that shows us some information about this specific form. So we have the form ID, system site information settings and the form class and some information about the elements of the form API that is defined in this form. If we click here, we can see that this form is built with those form API elements. Okay, so we can discover which code builds the specific page. Okay, next step. Often controllers need to execute some complex logics to build our page and it's not a good idea to have all this logic into the controller class, okay? Because it's better that we separate concerns so every class do specific things but it's also useful for reusing the same code in different places and for testing our business logic. So all of that business logic needs to be in very specialized classes, which are the services, okay? So all the logic of our application needs to stay in those classes, in those services. Drupal Core provides us with a large number of already defined services. There are about 500 only in the core and this service is ranging from translated text around a database query, sends an email, authenticate a user and so on. And all of those services are managed by a service container that which is in charge of creating all the dependencies automatically and we can see a complete list of all the services in the services widget of web profiler. And here, services. There are a list of every service defined in our website. Some of them are initialized, some of them not because not every services are used on every request and for every service we have a lot of useful information. For example, the service ID, the class that define the service, the tags that are used in this service and the dependency. For example, cache underscore context underscore dot URL depends on request underscore stack. And then we have some information useful for performance analysis. We have the number of times this service is requested from the code and the time Drupal spends in initializing this service. Then all services are lazy loaded and then I saw the only one time that the second request uses the same instance. So this is the time of the first initialization. For example, if we look at the module handle service which is the service that manage all your module, you can use it to enable a module, disable a module, invoke a new Anook on a module and so on. It depends on app.root and cache dot bootstrap services. So when your code ask Drupal for an instance of module underscore handler, the service container instantiate app.root and cache dot bootstrap for you and inject them directly into the module handle. So all these dependencies are managed automatically and you only have to ask for a specific service and the service container do all the things for you. Okay, and during the life cycle of our request, the service container is used to get all the required service. And we can use, for example, the recent log messages page. Okay, this page is built by the overview method of the DBLO controller class. And we see in a moment that a controller isn't a service normally. So we can inject services into a controller class. Okay, because the service container manages only the services. So we have to follow a specific pattern in Drupal 8. And we have to use a create method which receives the service container and use it to inject our dependencies into the controller constructor. So we can use web profiler to understand of these works. We go to the database login is here. Okay. We can use web profiler to look at the controller class. In this class, we have a static method called create that receives an instance of the service container and use it to extract from this service container all the required services. This controller needs to do what it do. In this case, he needs the database service, the module handle service, the data format service, and the form builder service. And all of those services are used in the overview method, for example, to build this specific page. For example, it use the module handle service to load an include file, the database service to run a query on the database and so on. And we have this page. We have just seen that one of the services used by these recent log messages is the database service. The database service is one of the most used service because it's used to run every query to the database. And we can use web profiler to analyze the queries run to the database. So we can go to the database widget and we can use it to discover all the queries that are needed to build this page. For every query, we have the version with placeholder, time spent in running this query. The class that defines, that run this query, the target database, in this case is the default database. We can see the value, the actual value of all the placeholder. We can swap the placeholder into the query so we can copy it and run to the database. And if this query is a select, we can run an explain query to extract information from MySQL in this case to understand how MySQL analyzed this query and maybe implement better performance. We can also swap all the placeholder in all the placeholder of all the queries because maybe we need to search a specific string. And we can show only this low query, this low query, this low query, for example, the threshold was five milliseconds, I think. So the query that is lower than that is where I glided here. We can change the, we can filter by the query time and the query type and so on. So we can understand what queries Drupal uses to build this page. And the last step that a controller does is to return a render array. Usually, a controller returns a render array with all the information to build the main page content, by only the area of the page that fits in the main content region on the page. And the rest of the page is usually built by the block system on a Drupal 8 standard installation. The information around the main page content are built by the block system. And we'll see this later. Okay, in the case of the recent message, the recent block messages, the render array is composed by a couple of form, a couple of form and a table. Here we have two form and then a table. Okay, then we have a render array and we need to turn it into an HTML page that Drupal can return to the browser. But if we follow the source code of Drupal 8, if we try to understand where Drupal translated the render array into HTML, it's very difficult to understand where it happens. And this is because a lot of system in Drupal 8 are loosely coupled and all the communication between those systems happens through the event system, which is similar to the hook in Drupal 7, but not the same. And in this case, if the controller, which is a typical use case in Drupal, if the controller returns a render array and not a response object, the kernel dispatches a kernel.view event to look if someone are able to translate this render array into HTML, okay? So we need to, okay, this before. The event system works in this way. One or more listeners wait for a specific type of event and if someone dispatches this type of event, every listener is invoked in order. Okay, and all the listeners can interact with the event itself. So in this case, there has to be a listener for the kernel.view example, which is capable of turning a main page content before in a complete page render array and then render it to HTML. So we can use web profiler. For example, we can go to the homepage on the event widget. Here we can discover every called listeners, the class that implements the listener and the priority of the listener, all the listeners that responds to the same event type are executed in order. So we can look for a kernel.view event. There are three of these, but the one that draws our attention is the event called main content.view subscriber. And the responsibility of this event is to delegate to a page manager plugin in Drupal 8 that knows how to decorate the main content render array with the page, the whole page render array. And main content view subscriber, this class, which is a service, looks for every service tagged with a specific tag in the service container. This tag is main underscore content underscore render. We can look for every service that use this which is tagged main content render. Okay, there are some of them. That depends of, this depends of the type of request we have. If we have an adjunct request, a dialog request, and so on, or an HTML request, Drupal uses the correct one. In this case, we are dealing with an HTML page. So the renderer used is the HTML renderer. And this renderer is quite complex, but the specific things that it does is to look for a specific page variant plugin which is the component that to decorate the main page render array. In Drupal Core, there is only one implementation of this plugin, which is the block page variant, which uses the plugin defined in the plugin configuration page of Drupal 8 and use it to decorate the content with the plugin, the usual plugin system. And we can use web profiler also to discover which blocks are used on this page. And here we saw the plugin ID, the block ID, sorry, the block label in which region is printed. If it's rendered or not, which module provides this block, which theme, the status, and the plugin that implements this block. Okay, so we saw that. Okay, at the end of this process, main content view subscriber returns the renderer array of the whole page. And the last things that HTML renderer does is to render the renderer array to an HTML response. HTML response is a kind of symphony response object that contains the HTML of this page. And the component in Drupal 8 that translate the final translation from render array to HTML is the theme layer of Drupal 8. And the theme layer uses a tweak to fill all the templates with data from the render array. And we can use web profiler also in this case to look at the theme system. And here we can discover that the theme name in this case is talk, talk. The engine is tweak. This is a sub-team of Bartik. The defined regions use the libraries, stylesheets removed from other modules or themes. The path on the file system of this theme. And the class that choose that this is the active theme in this for this page. Then we, this is useful for performance analysis. We have the total render time, tweak are compiled in PHP before the render process. We have the number of tweak file used and the number of time they are used to build this specific page, which is the home page. And then we have a call graph of all the dependencies between every tweak file. So you can use, we can use this call graph to understand which tweak files were used and which files depends on other files. Okay. And during the render process, all the JavaScript and CSS assets were added to the final markup. And obviously we have a widget for that. In the assets widget, we have a list of all the JavaScript files and the CSS files used on this page. For the Drupal settings JavaScript assets, which is a particular assets, we can see all the JSON that is injected in the page. And for every file, we have the path, the version where if the file is inserted in the header of the footer of the page and a lot of other information for every specific file. For example, if we have a JavaScript file that is used only for a specific version of a specific browser, we can see that this JavaScript is used only if we have Inter Explorer lesser than eight, for example. And the same for CSS, the same instructor. So we can discover how those assets are used in every page. And at the end of this process, finally the kernel sends the response back to the browser. Our journey in said Drupal is finished. We have reached the end of the render process and the kernel returned the response to the browser that rendered the HTML into a web page. In a web page. Okay, but there are one more thing that I want to show you. Maybe in this presentation, we lack an overview of all the system work. There is another widget in the web profiler, the timeline widget that shows an overview of all the system. And it is built in using D3, which are library to draw, to do a drawing. And here, we saw a timeline and every components involved in rendering of this page are showed in this timeline with the information about the time spent for every component and the number of, the quantity of memory used for each of them. The brown one are the service's instantiation. Then we were each the, okay, there are a lot of them. Okay, we reached the event. In this case, kernel.request event spends this quantity of time and memory. The light blue were the event listeners. And then, so in the case of Drupal, the most expensive part of the page rendering happens in the main content view subscriber, the class we saw. And then in yellow, we have the twig compilation. So the biggest one is the HTML, the HTML twig file, which contains all the page. And we can use this timeline to have an overview of every dependencies and how the different components are invoked to go from the request to the response. Okay, we've just scratched the surface of the new Drupal 8 because during this process, Drupal can do a lot of other tasks. For example, sending email, contacting external systems, building views, and so on. And Web Profiler obviously has a widget for all of these of those things. We can collect every mail sent by a page, every external HTTP request using Gazel. How many time Drupal spends building the rendering views and so on. The API is very extensible, so ContribModule can provide other widgets to Web Profiler. For example, rules and them key are providing their debugging information on Web Profiler. And here we have some bibliography, the Web Profiler web page on Drupal 8. We have built an infographic to explain all of those things graphically. And some other useful link to understand other systems. For example, the documentation from symphony.com which explains how the debug toolbar works in symphony. And a link to the Drupal Console project. And okay, that's all. I remember you that tomorrow there will be a sprint. And probably we can, I am here at the sprint tomorrow. So if any of you are interested in contributing to Web Profiler, we can meet tomorrow and try to, there are a lot of things that we can add to the module to analyze other parts of Drupal. And I also remember you that next year, Drupal developer days will be in Italy at the end of June. So join us, join us in Italy. And okay, I think we have five minutes. No, no? Okay. If we have some minutes for questions, if you have some questions, you can use the mic. And if you have any other questions, I am here today and tomorrow. So feel free to ask a question when you want. Thanks for all, first of all, thanks for this nice talk. I wanted to ask if there's also some profiling on trick variables. So I have always sometimes a hard time finding the outcome or the origin of a tweak variable. Okay. No, at the moment, no, but it is an interesting argument, I never think about that. But if you can post an issue to the web profiler issue queue, I can work on it absolutely. Any other question? No? Okay, thank you very much.