Introduction to Dispatcher introduction-dispatcher
An introduction to the capabilities and features of the dispatcher as part of the AEM architecture.
Transcript
Hello and welcome everyone. My name is Abhishek Dwevedi, and in this video, we are going to learn about dispatcher. After completing this video, you should be able to define dispatcher and to ultimately describe, the benefits of using dispatcher.
Dispatcher is an Adobe Experience Managers caching and load-balancing tool. The most common use of dispatcher is to cache responses from an AEM Publish instance.
A lot of pages on your site are going to be static in nature. They are not going to change frequently. So it’s a good idea to cache your pages and serve them directly from your server, not from your Publish instance. And this is where dispatcher comes in the picture. Dispatcher is also used as load-balancing tool. So, if you have got multiple publish instances, dispatcher can act as a load-balancing tool.
This helps into increasing responsiveness office site.
Also dispatcher can handle any external security threat on your site. Adobe strongly recommends using the latest version of AEM Dispatcher, to avail the latest functionality, the most recent bug fixes and the best possible performance.
So now let’s see some of the important features of AEM Dispatcher.
AEM Dispatcher can convert dynamically published content to a static HTML, which will be serviced by a static web server. It can cache all static assets and serve from that server.
Now there will be scenario, if content is already presenting cache and if author makes a change on that page, what exactly should be served.
Because it’s on the cache but now the author has also made the change, so cache content will be flushed off. So whenever you publish new content, new content will be in there in the cache.
AEM makes an environment fast and dynamic, because it also serves as a load-balancing tool.
AEM Dispatcher is available as a plug-in for your web server. It is available for Apache and IIS both.
Now let’s see a high-level Dispatcher module architecture. So, on the left side we have authors and we can have multiple authors. On author environment, they will be making changes, they will be adding new pages or editing existing pages. Now once the content is published to Publish instance, there will also be a web server, which will serve the content to your end users or your visitors to the site. In your web server, you can place a dispatcher module and then dispatcher module will now serve, its role as caching mechanism as a load-balancer and also it will help you to identify security threats.
Now let’s see how dispatcher handles, when to serve the content from cache and when to serve the content from your publish server. So as soon our visitor visits the site, it’s a document request.
This request goes to web server and as dispatcher is already available there as a module, it accepts that request, and as a step one it checks if this request is cacheable.
If it is not cacheable, then you can directly go to your Publish instance and to serve the content. Because there can be kind of documents or pages which are not cacheable because they are very dynamic in nature. But if it is cacheable, then it will further go to step two where it will ask a question. Now okay, so it is cacheable, but is it already cached or not? If it is not cached, it will go to Publish instance and then serve the content. And also at this step, it will also cache this requested page.
Now what if the content is already cached? If it is a cache file is already available. So dispatcher will smartly check here, if this content is up-to-date or not. Because we do not want to serve a stale content which is updated in your site, but a cache is an older version. Now checks if the content is up-to-date or not, which means that maybe authorize change the content, but it is not reflecting in cache. So, to avoid all those kinds of issues, it always checks if the content is up-to-date. And if it does not up-to-date, it will serve the content from Publish instance and will create a cache file for this. And if it is up-to-date, then it will directly serve from your dispatcher. It will directly serve from your cache and will not hit the Publish instance. A lot of time as a lot of pages are static in nature, so most of the requests will not go to a Publish instance.
This will save requirement of additional Publish instances and will make your site faster as well. The other benefit of using dispatcher is load-balancing. So it comes in two ways. First one is increased processing power because share documents request among several instances. You can reduce the response time, when you’re using the dispatcher for load-balancing. It also maintains internal statistics for each document category. And it can estimate the load and distribute the queries efficient. The other set of benefits that comes from dispatcher’s load balancing is increased fail-safe coverage. It relieves request to one of the other instances automatically. It can slow down the site proportional to the computational power lost if that happens. And it can manage different websites on the same static web server.
Now you should be able to define dispatcher and you should also be able to describe the benefits of using dispatcher. Thank you for watching this video, have a great day. -
Additional Resources additional-resources
recommendation-more-help
4859a77c-7971-4ac9-8f5c-4260823c6f69