ÃÛ¶¹ÊÓƵ

Transcript

Hello, everyone. Thanks for joining. We’ll give a couple of minutes for everybody to join and then we can get started.

OK, it’s a couple of minutes past 11, so let me just get started. Let me, yeah, so let me share my screen. OK. Hope you are able to see my screen. Hello, everyone. Thanks, Katie. Hello, everyone. Thanks for joining for today’s session. Today’s topic for the webinar is optimizing performance and caching strategies and techniques. This is basically about how we can optimize AM performance by using better caching and then what are the different techniques that manage better caching. So let me go to the next. OK. Here is the agenda that we have for the current session. We’ll have a brief introduction for myself and then the co-host, my colleague, and then we talk about a brief overview of AM caching and then what are the different caching mechanisms and different tiers of caching. And we have a quick look at what are the, what is a demo that we can have with respect to caching on the dispatcher side majorly. And then a couple of use cases of managing caching on the CDN, which I’ve seen with multiple customers. So we look at two different use cases which are commonly used across AM cloud services, basically to AM cloud service. And the same thing works similarly on AMS2 with the customer as CDN. And we look at the demo of what are the different caching attributes or caching configurations on the CDN that we can do on the dispatcher. And we also talk about the fragment caching, where how we handle the dynamic content on a page and then how we make sure dynamic content is not cached and the rest of the thing cached so that the overall page performance can be improved. And we have a, we’ll have a quick demo on that and then we’ll talk about different techniques to debug any caching issue, be it at the browser level dispatcher or CDN and followed by Q&A. Okay, so coming to the introduction myself, Pawan Kumar Gadham, I’m a senior field engineer in field engineering team at ÃÛ¶¹ÊÓƵ. I’ve been working with ÃÛ¶¹ÊÓƵ since 2021. And then I’m based out of East Coast Atlanta. Anish, you want to give a brief introduction about yourself? Sure, thanks Pawan. Hi everyone. My name is Anish Sinha and I’m also in the same team as Pawan, one of the senior field engineer at ÃÛ¶¹ÊÓƵ. I am based out in San Jose and I come with more than 12 years of experience on AM. Thank you. Okay, thanks Anish. Okay, so we will quickly look at the overview of what is caching in AM cloud service or in general in AM platform, be it on-prem, AMS or cloud service. So caching is basically storing the resources which are coming from AM which are accessed by the end user through the browser and storing them at different layers of the platform. It can be user browser, it can be a dispatcher or CDN. So why we need caching? So caching basically enhances the overall page performance. If you have a better caching at different layers of caching, the request to the end user can be served quickly, be it assets or pages or be it can be any resource on the page. And utilizing multiple layers of caching increases the overall page load and then thereby it looks a lot faster for the end user and then significantly enhancing the overall user experience for the end user. Page and site performance directly impact SEO because page speed is one of the key factors within SEO. So having the better page performance, page load performance gives a better SEO rating. And in this webinar we’ll look at various caching strategies and the best practices around AM performance improvement.

So if we look at in general architecture, there will be a browser and then a published tier and then author tier. So this particular diagram is much related to cloud service where CDN, dispatcher and published instance are managed as a single tier which is published here. But in general it can be the same, I mean it will have a similar kind of architecture for the other setup as well like AMS. End user tries to access the page from the browser, request goes to CDN, dispatcher and then the publish depending on whether requests can be served from either CDN or dispatcher, that’s fine. Otherwise requests will go to the origin server which is published and then page will be rendered and then returned to the end user. Okay so if we look at layers of caching, there are majorly three layers of caching in a conventional architecture. Like if we look at AM cloud service majorly, so these three are involved where caching at the browser. So browser can cache the content, you can set cache control headers to control how much time the cache of a particular resource needs to be present in managed, maintained in the browser cache before it gets invalidated.

And then the cache control headers and then expert headers are a couple of approaches with which we can manage how much time resource can exist on browser cache. So the cache control headers exist on browser cache. And then the second one is the CDN layer where you can cache the content at the edge and cache control header and then surrogate control header which is specific to fastly on the AM cloud service. These two are used to manage how long a particular resource resides on a CDN cache before it even gets revalidated or invalidated on the CDN.

And then the third layer of caching is on the dispatcher. You can define cache rule under the form based on the rules you can define what hierarchy of content you would like to cache on the dispatcher. So whenever a page is accessed depending on those rules, particular page will be cached on dispatcher cache under doc root.

And then one of the key element of dispatcher caching or how we manage dispatcher caching and then how long we have a valid content on the dispatcher depends on the stat files level configuration which can be configured through form file configuration in the dispatcher configurations and then based on that it creates a dot stat file in the hierarchy of the page content.

And then the slash cache is the directive where we will see a list of paths which can be cached for particular resource. There are a couple of references in the documentation.

This particular documentation clearly talks about what kind of a stat file level values can be defined for a particular content or particular site and then it clearly explains with different cache have different stat files value how the caching gets affected.

Yeah and then there is there are other documentation with respect to dispatcher defining grace period and all. Okay so that’s on the list of caching. So if we look at the overall architecture the browser level caching can be managed by using cache control or a max h header. We can also have e tag in some cases and which actually used by the weekend site if I look at. So depending on a max h value let’s say if I define max h as 300 which is 300 seconds. So the file which is being accessed on the browser resides on the browser cache for five minutes. So any request within that from the same browser if the user access the same resource it will be served from the browser caching. So that way it I mean the page loads faster for the end user.

The second one second layer of caching which is CDN even in CDN you can manage how long the cache can reside on a CDN at the edge based on cache control max h. So max h cache control max h value is respected by both CDN as well as the browser. So let’s say if you want to have a different caching TTL for CDN layer on cloud service which is fastly you can have additional header called surrogate control. S max h is basically going to override max h value. So you can use surrogate control header to set a specific value to the fastly CDN. Let’s say on fastly CDN you want to store the you want to have a cache TTL of like five minutes right which is 30 or maybe 300 seconds right or if you want about 10 minutes then you can have 600 seconds. So if we want to have a different value for browser as well as CDN you can use cache control as well as surrogate control on the same dispatcher configuration which will set the different value. And in the dispatcher you can have a start files level configured in the farm file which defines what is the invalidation of the content to which level the content invalidation happens on a content hierarchy which is stored in the dispatcher cache. So we will talk about that in detail in a second. Okay so we’ll quickly look at the demo. So let’s say I have a cache. So this is the weekend side which is there in my local docker setup in my SDK setup in my local and then this is the docker that is instantiated. So if we look at files in general the cache resides under OPT. So anything access that’s I’ll say I go to maxine sorry mount bar www HTML content. So if you see I have the the usc and access and the magazine so for that cache is formed. So the new pages which should keep accessing right those caches those cache files will be created under docker and then right now you don’t see any start file which is still here. So if I let me quickly delete the entire cache and then quickly show you a couple of use cases. So under HTML I can delete this and then start file. So let’s say if I access the adventure page or maxine page and if I go to content I have a cache created for that hierarchy. So it creates the FAQ page. So let’s say if I go to cache control if you look at a weekend repository the default stat files are configured in set to two which means that if you publish any page it is going to create a stat file level until the level of two. I mean the level starts from zero from HTML content and then until us you’ll see a stat file. So let’s go to a page in my local author and if we go to weekend em let’s say I have a maxine page and then I’ll just edit this. I’ll just say right here and then this is saved and then I’ll just say quick publish. Once I say publish if I go to the docker so you see the stat file level starting from the darkroot level which is where www.html and then the first level is zero after that is one and then two until weekend level the stat file gets created. So now if you let’s say if I access a HTML page right if I access a maxine page it is getting returned from the caching. So it’s getting loaded so when I update any page and if I try to replicate a page below maxine or probably adventures it is going to create a cache under maxine and then you are going to have a page. Let’s say if I update arctic surfing page right so if you look at the stat file which is generated one minute ago and then now if I just edit this page let’s say if I just edit this page and then I just publish this now if you see the docker it’s going to touch the in that hierarchy whichever the stat file level that it finds while propagating through the parent page. So the first stat file that it found it’s going to touch it. So what happens with this is irrespective of which page is updated the stat file is still getting updated at the parent level and then the content which is there below this entire site or site hierarchy below en is going to get invalidated. So when you try to access a page it’s going to check okay stat file level is just touched so it’s going to it’s going to create a cache again and then serve that to the user. So let’s say if I go back and then if I just try to check adventures right so before that let me go to docker and then I open the logs just clear this and if I just say adventures right so if you just search for action you see the the cache file is older than last flush even though the file that we flushed is below magazine and then if I check the entire pages the adventure page itself got invalidated right so it is going to create the cache again and then serve that to the end user. So with this what we see is that depending on a stat file level it’s going to check what is the nearest stat file level and then it’s going to see that okay after the last stat file in that hierarchy everything gets invalidated even though we just updated a single page right. So to avoid this what we encourage the customer is to generally to set probably a hierarchy of six or five and then if I go back and then just publish letter with most of your page right so let’s see if I go here sorry so if I just open this marks in western australia page and if we go to docker so under mags and you’ll see the western australia right so if I go back to the page and if I just update this page and and if I publish this page and go to you see now the stat file level is being created and until the level of uh magazine right so if you look at zero one sorry zero one two three uh the under magsine yeah so uh under until until uh magsine we got this created so which is six right so basically seven six plus seven so it starts with zero so it’s going to create a strat file level here now under a magazine if I go back and update a page it’s not going to touch the us or a level start file level like we have seen before right so let’s say if I go to san diego and I just publish this page okay let me just send you okay now if I go back to author and under san diego if I edit this if we quickly publish this okay let me just close this tab we can yes here if you see this got uh updated 23 seconds ago so and any other stat file level which is above this it will not get affected so I mean the entire hierarchy gets updated anyway the the latest one got updated here so anything updated it’s not going to touch anything uh under strat file 11 the same cache can be used so so that is the uh advantage with having a high uh strat file level configuration with which you can better manage this uh content invalidation and then thereby increasing the cacheability on the dispatcher okay the the next uh layer of uh caching is on the dispatcher sorry cdn on cdn there are a couple of use cases where we have seen with multiple customers in case where they want to use their own cdn and then altogether want to clear the cache on the or or not to use cache on the fastly cdn so in that case we can have a cache control of maxi which defines caching for the uh browser but for fastly if you want to in well if you want to use the data just a pass through or or don’t want to cache anything on the fastly cdn you can use private no store no cash for the surrogate control editor which is going to not which is not going to allow caching to be done on the fastly caching surrogate control is specific to fastly and then you’ll not see this in the browser request when it comes to the end user because it will be shipped off from the uh it does at the fastly level itself but this is used to define uh the caching on the uh fastly so this is uh normal structure uh this basically this location my directory can be uh are generally used in the vos file and define cache control header for each of the resource type like in in my case here i have an example for the html type we have for any uh js or cs or maybe assets generally for assets we have a larger uh maxi values like probably 10 days or maybe 24 hours right so that is uh one use case and then stale while re-evaluated would would indicate that okay uh let’s have resources access and then a cache gets created on the cdn cache and then that the the detail for that or maxi value for the artistic underletting right which is 10 minutes uh so in during after the 10 minutes if if somebody tries to access the page it tries to check whether uh a revalidation is done or not if it is not done it is still going to serve the the existing cache file which is present in cdn and then asynchronously it’s going to send the request to the uh to the dispatcher cdn uh dispatcher or am to get that cached well cached file uh back into cdn asynchronously so so with this what happens is even though it is invalidated uh content that is present in cdn it still gets served and then uh that way you can have uh a better uh caching or a better performance for the page so these values are generally defined uh for most of the static pages where the latest content being served to the end user is a priority these values will be much smaller uh or maybe sometimes you don’t need to add it so that is one example another example is where customers want to have a different maxi value or a cache value for cdn in the fastly as well as on the browser side so if you look at in here we see cache control maxi is 600 but for fastly we’re setting that as uh one which is 3600 seconds so with this what happens is what happens is the caching on fastly becomes one hour so the value with the cached page or cache resource which is there at the edge is going to get cached for one hour and and but the browser uh caching uh will be like used for uh 10 minutes so this is uh one way to define different cache values for uh browser as well as uh cdn in the demo let me quickly so if we uh okay so cache control is set for 600 which is 10 and then target control is set for 3600 which is 100 one hour on the cdn so if we quickly look at the uh demo let’s say if i go to uh cdn and then if i have uh my test sandbox uh yeah so if you look at this is the uh sandbox that i have and then if i look at one of the page i mean i had to use sandbox because that’s where uh the cdn is enabled right so if i look at here the the cache control header defines or a cache control header which we define in dispatcher i’ll quickly show that in here let’s say if i go to we can host okay so this is the uh the director which is setting the max age sorry um yeah this is the directory that we are using uh to set the cache control max is standard and then stay while you added 3600 uh for the resource for the html resources so if we look at here this defines what is the max age value with until which the cache value can be served from the browser cache itself and then another thing important thing here is that if you look at x cache it says hit that means that the the resource which we fetched is being cached at the cdn uh and then this resource is being served from the cdn cache and if i just refresh this page again you’ll see the same value and then uh yeah yeah so so these are the values that you can see on the browser side with which you can see okay how long the this is being cached on the browser side cache x cache uh and cache control are the uh two main headers with which you can see whether a putler file is being served from cdn cache or not okay so if we go back okay so the the next topic is about uh how we manage the dynamic content or or if you want to filter out a fragment of content from caching and still you want to leverage uh cdn or a dispatcher cache to cache the rest of the static page or where the dynamic uh where that fragment is a dynamic part so let’s say this can be uh used this can apply to use cases like a price on a on a product page or maybe returning some weather report on a specific page right it can be a multiple scenario so the using the uh loading a dynamic content on a page uh in am it can be done through two approaches one is sgi which is called sling dynamic include which is basically a specific dynamic include tag which will be processed separately at the dispatcher right and then this works fine on the ams and then this works on a cloud service as well but you have to disable caching of a particular dot particular resource or let’s say html those pages needs to be disabled on the uh cdn because if you cache the uh pages on a cdn even the content is dynamic on the dispatcher it’s being dynamically fixed on the publish it still is getting cached on the cdn and then the same will be returned to uh to the end user within that max age value that we define so sta can still be implemented in cloud service but cavities that we need to disable the caching for that particular page hierarchy in the uh cdn using surrogate control which we saw in our earlier uh slides where we can say no cache no store and private and then this is the documentation on the sling dynamic include which has very detailed documentation of what are the uh oj configuration that we need to do and then what is the uh dispatcher configuration that we need to uh have okay so uh the another approach to load the dynamic content efficiently on am cloud service is the exciting so it says include is is a feature that is being recently added i think last september or october uh and then uh the the esi configuration uh can be done or or needs to be done at the two levels one is at the osi level where we need to specify that okay particular section of the page needs to be dynamic right so that’s part uh part one the other part part two is basically how you process these pages on the cdn so if when you when you include uh esi component so the the steps to develop a esi component is that create a component uh try to render the dynamic content through the component logic right and then uh so for esi we can still use sling dynamic include setup where uh sling dynamic include osi configuration and then a particular value in the osi uh configuration has a option to select as a esi so if we look at the uh next slide the include type can be specified as esi so if you have if you’re in general uh building a hdi component or or implementing string dynamic include this particular include string dynamic include this particular include type will be a sdi and and sling dynamic include as an option to create a esi uh include in the uh in the page so so for esi you’ll select this as esi and then what are the component a dynamic component that you define which renders the dynamic content that needs to be specified in the resource type so that a cdn can recognize okay this particular uh uh published instance can uh identify okay this particular section of the page is an esi component and this needs to be wrapped with an esi tag so and and rest of the configurations are pretty much similar to uh hdi like no cache is basically used to uh segregate the resource type or or path of this component on the page so that way we can recognize this particular type in the dispatcher and accordingly apply our rules okay so if we come back to uh the esi there are a couple of considerations that needs to be uh checked before even going with the esi implementation one is esi tags are processed at the cdn sequentially not uh concurrently so having huge number or or or a big large number of esi components included in a page is going to add a latency and that may kind of uh slow or or have a page speed of a bit slow on the end user side so that is one thing so try to limit the uh the number of esi components on a page to smaller number and then a limitation on the maximum depth of esi is five because uh there are only at a certain level or or certain depth that esi components can be uh processed like let’s say if we have uh one esi component within another esi and then another component within that esi right so that hierarchy when that includes you can do only till level of five uh and then other uh limitation is that the number of esi components that you can include on a page cannot exceed 256 so that is uh one uh concentration before even uh you want to consider implementing esi okay so the first part that uh like i mentioned the it’s about configuration of uh esi esi configuration on the uh osa side on the publish so this is the sti uh sling dynamic include osa configuration within which you define a dynamic component in within the resource types and then uh you define i include type as esi okay so so once this configuration is done whenever a page is processed on the publish for the entire dynamic component part it’s going to generate a esi include tag and the same thing will be analyzed or processed by cdn uh at the edge okay so the part one is about the osa configuration this part two is about the configuration on the dispatcher like what are the different configuration that you need to do for a parent page as well as for the uh dynamic section of the page right so all the dynamic components are rendered with dot no cache dot html extension because if you look at uh the selector that we the selector that we gave for this esi component is dot no cache the the first thing that you need to consider is okay the first thing that you need to consider is about the xam esi you want to make sure that esi is enabled on the cdn so for that the header that needs to be added for the parent resource is xam esi on and then you also need to make sure the zzip is off between the dispatcher and cdn layer because if the zip is done uh it cannot analyze the esi tags within the page resource at the cdn so for that you need to have uh zzip disabled and then the rest of them are like what are the ttos that you want to define uh or cache control header deformed that you want to define for cdn as well as browser which are uh like common configurations for the caching so these two are important uh configuration one is xam esi as well as a no gzip environment variable and another one that you need to set is set xam compress on this gets applied once the processing done on the cdn it’s it needs to compress the page again before it even sends to uh end user so with this you will not have any issue if you don’t set it but the the the as a compression is not done or which is disabled at the dispatcher the same uncompressed uncompressed uh page resource will be will travel through network and erase the client browser which is uh which is going to take more time than you do a compression and then for the uh dynamic part of the content which has dot noka dot html which is the esi component within the page that needs to have a zzip disabled as well so uh no zzip is set to one which is true and then you need to make sure the the dynamic section of the page uh should not be cached on the uh either on the browser or on the cdn so these are the configurations that you need to have so uh xam esi is on and no zcp is set to true or one and then you uh set the am xam compilation header at the parent page level and then uh set up cache control private for that better esi resource at the browser as well as cdn and then you define nosy piece to one so uh these are the dispatcher components that you need uh for the esi to work uh and then we’ll have a quick uh demo on how this looks on the uh actual browser so this is my uh sandbox if you look at uh mags sorry magazine page i have a dynamic content so this is a time so if you just refresh this the entire page is getting cached but i’ll show that in a minute through network but the dynamic part is still getting uh updated so if i look at the overall page and if i just refresh this page and look at the network it still shows x cache it is hit which means that the entire page is still getting cached on the uh cdn so the x cash it means it’s being served from the cdn cache so entire page is still getting cache and the dynamic part of dynamic part of our page is still getting refreshed so so that is uh the esi component and then if you want to look at how this looks on the dispatcher let me i think okay let me quickly connect to vpn and then i’ll uh quickly show you that okay so meanwhile i can show you the dispatcher configurations which i have uh yeah so on on my vhost uh this is what uh this is what are defined uh sorry uh these are the two sections which defines configurations for the uh the esi component uh so the like i mentioned the header age is set to zero and then xam uh esi set to on gzip is off and then where again compression is setting on at the cdn and then for the dynamic section we have uh cache control set to private and then no gzip set to one okay so now let me go to this yeah so if i uh go back and then check dot net which actually bypasses uh the cdn layer and then if i look at uh the so if you look at you don’t see the dynamic section of the page dynamic component of the page here right so if i just inspect and then go to network storage um sorry if i go to inspect and then if i just say esi okay okay let me quickly okay so if you look at uh this is this is being served from dispatcher now so if you look at the cache file on the dispatcher it has esi include in the page source and this is being processed by cdn uh at the edge when you uh try to access that page on the cdn right so this is the dynamic cdn right so this is the dynamic content that gets heard uh on the browser so that is uh on the esi component and then we’ll also look at a couple of debugging uh approaches on each layer of the browser uh dispatcher or cdn uh to debug the issues on the browser the the configuration that you can do is on the network tab you can disable the cache so that uh you rule out a case where the the the response that you’re getting is from the browser cache or you can alternatively use curl command to uh retrieve uh the um the headers as well as you can use the private processing as well another approach is to use cache control uh header and you can say no cache max is zero which is going to bypass the cache on your browser as well right the other approach to by using the response headers using cache control max age and no store like here right so you can use max age zero and then no store or no cache that way you can invalidate the cache or you bypass the cache on the browser and there are certain use cases where if you find auth or a session token within the cookies even that is going to uh bypass your browser cache so that maybe i mean if you are observing that it is not getting cached from the browser you can check a butler cookie or present in uh in the cookies or not or uh you can replicate the browser request by using curl hyphen i hyphen h where you can mention cache control no cache and you can with this you can fetch all the header requests uh or response headers as well so this basically is going to replicate the use case you accessing from the private browser or or uh like disabling the cache another uh set of debugging uh approaches or debugging techniques to to debug the caching issue on the cdn is to check what is the x hyphen cache header value in your browser so if the x cache header value defines hit miss or a pass depending on that you’ll see whether but that is being served from the dispense cdn cache or not you can also check cdn log where it will have an attribute of action miss or action hit based on it is being used to check based on it is being served from the cdn or not you can also verify uh cache control headers on the dispatcher or on the cdn custom cdn to see what are the values that are defined and you can bypass the cdn by using life and uh cache control no cache which is going to bypass cdn and then uh provide you the response or you can use the uh like let’s say if you think it is being fetched from the cdn you can purge the cache on uh cdn by using purge api or or or maybe the caching control header mechanism the next one is about uh how you debug the issues caching issues on the dispatcher uh the first technique would be would be to define dispatcher log level to debug so if you if you generally don’t make you don’t generally make this as a debug in production to use this for a lower environments to debug the issue you can do that on production as well but for a very limited time because having a debug level on the uh for the dispatcher log level is going to write a lot of logs and you can check the dispatcher log which have action hit or action mess that defines whether a particular value particular resource is being fetched from the dispatcher cache or dispatcher or dispatcher cache or not you can also look at the http header and http access logs which basically is going to give you a cache action status what is the cache action status for patla resource whether it is a action hit or is it being served from the dispatcher or not it’s a hit or a miss will be will be present against this cache action status and you will also see whether a particular resource is being uh returned 200 or 304 or 300 300 to 1 etc there is one approach to to check whether a response is retrieved from a dispatcher cache or not right so you can have a slash info been set to one in in under the form section and that is going to enable a patla header it’s going to return x cache info which will take a value of hit or miss and and this header will be returned in the response headers when you send x-dispatcher-info header say i mean it can take any value basically you can just say x-dispatcher-info set to one right and you can you can have use this header to set it either through curl command or you can use like mod header plugins of the browser where you can set this value and then you can debug that and then you can use query parameters to bypass the cache and then but you need to make sure that query parameters are not configured to be cached either on a cd or on dispatcher and you also need to look at like let’s say a particular value is not being cached and then you see cache action as miss or maybe in the x cache info it says miss then you need to check whether a particular resource type that you are accessing is is included within a cache configuration or not yes so that ends the overall presentation and then we can have a set of q a yes bavan hi thank you for the presentation there is a very common question in the chat so let me just read it out to you and you can respond to it so the question is dispatcher cache invalidation is based on page activation and cdn cache invalidation is based on the ttl is there any solution or best solution to sync the dispatcher cache and cdn cache so whenever the page activation happens same time the dispatcher cache and cdn cache both gets invalidated so one approach is to and which which we generally recommend is to have a shorter max age value so that way even though cache is updated or even though page is published and then cache is invalidated on the dispatcher it’s not going to serve too many requests on the too many requests from the cdn before it gets stale while are invalid right so while it it basically is going to fetch and then update the cdn cache that is one approach the other approach is to use the the cdn purge api which is generally used on the on the publisher on the author people try to so depending on which resource is being published that resource is being invoked on the purge api to invalidate that page on the cdn so that way you will invalidate the particular page or resource cache at the same time on dispatcher as well as on cdn so that way end user will request the page from the publish when the next time when they access but the cache here is that accordingly the the max age value defined for cache control needs to be managed as well which should be like a shorter value because if your browser cache has a 10 minutes right let’s say if you set cache control max age to 600 which is a 10 minutes within that 10 minutes even though the the cache is updated both dispatcher as well as on cdn you still get that from the browser so that is one cache one cache we have yeah there is one more question so dispatcher logs are of huge sizes do we have any tools that will help to monitor the log real time except adobe iO and the next one is there any local tools that helps us helps us view the downloaded logs better so there is a documentation within adobe at least for em cloud service you can download em cloud service you can download the log there’s a i think there is a there is a tool that we have that can be used to analyze a log but at least to to manage the logs like i mean the size of log that you create it depends on a layer log level or kind of request that we are accessing right so the size of that you cannot like you cannot control but but the the the only way that i see most of the customers doing is using setting up their own splunk or elk tool to pull the logs from cloud service and then have reports generated on the splunk to so that they can analyze the logs better and faster anything else anish that’s pretty much i see in the chat and the question section okay i just see one more question coming in pavan so if you are using an api to purge the cdn how do you how do we know what are the resources is to clear other than the page you are often images and videos needs to be pushed to so generally generally when you publish a page that’s the page that you are going to invalidate right i mean if let’s say the page has a different asset that is being added so that is be that is going to get reflected on your page anyway when you publish it so accordingly that request will be sent to the assets and then fetched again right so i mean you just need to find out what is the resource that is being published and then that resource needs to be sent to purge api to clear the cache on cdn yeah thanks pavan the next question is can we use sdi on dispatcher and esi on cdn at the same time for the same resource um i think i think you don’t need that kind of a set of i’m not sure what is the use case that you’re trying to achieve generally you don’t need it i mean if you are able to do this through esi i would recommend doing that through esa rather than including sda because if you have uh said that is is said through sdi uh in if you remember the configurations the the parent level we define cache control header as max page value as 600 which is 10 minutes right so irrespective whether you have a esi or sdi component on that you are going to uh like you are going to get cached i mean let’s say you define sdi and you you you define uh cache control max age as 600 and then uh even though it is dynamic it is still going to get cached on cdn unless you you you make sure that you don’t cache that right i mean you can set a uh surrogate control no cache uh comma private if you said that no caching uh for that particular resource on the cdn and then a dispatcher gets uh the request gets sent to dispatcher directly and that is even you yeah yeah so just just to add the use case mentioned by mentioned here is because we don’t have cdn on localhost so developer won’t get to see the final result so that’s the reason this question yes yeah so but if you see the rd environments also provided with cdn uh nowadays so i mean that is that should so i think your requirement should drive how you uh implement right rather than uh the developer comfort so i think if the requirement is to load the content dynamically esa is the best approach because you can leverage caching at the edge and which will be much faster than you are getting that request from dispatcher yeah so we are on top of time but there is one last question bavan when we update a content fragment how do we invalidate all pages that is using the content fragment invalid the dispatcher and cdn um there is um uh so so it depends on actually because let’s say your pages of a particular hierarchy are using content fragments any fragment that is been updated you there is a acs commons uh module which you can use to set the osj configuration let’s say if you update something in the fragments you can define okay particular hierarchy let’s say i’m updating content fragments i want slash content slash weekend slash usn slash magazine hierarchy needs to be cleared i mean hierarchy that cache needs to be cleared on the dispatcher so you can have that kind of a rules to uh to define through the acs commons configuration and that is going to uh invalidate the content where these fragments are used but the disadvantage with that is you’re going to invalidate all the uh max-in pages yep that’s that’s all the questions bavan thank you okay yep thank you everyone thanks for joining uh have a great uh bed thank you