4 Replies Latest reply on Oct 26, 2012 3:55 PM by Colin-P

    How does dispatcher on Author increase performance?


      Hello CQ Experts,

          I'm finally getting round to running a dispatcher in front of our Author instance as all the documentation indicates it's a good thing for performance (and security).

          While I can see the security benefits and I can understand the potential benefits of caching all those Javascript / CSS files that make up the CQ authoring application I'm rather puzzled by my results and the actual config.

          I took the config from the standard Knowledge Base article (http://dev.day.com/content/kb/home/cq5/CQ5SystemAdministration/HowToConfigureDispatcherFor AuthoringEnvironment.html) but when I install this and run it (Apache 2.2 / Dispatcher 4.1.1) the only files I can see cached in my Apache htdocs directory are some files used on the author login page.

           On looking at the dispatcher log file all the requests for files AFTER logging in are being 'not cached' by dispatcher with the following message:

           no cache due to authorization header.


      which of course is perfectly correct because the supplied config has the following entry:

      /allowAuthorized "0"


          So it looks to be doing exactly what the config is telling it but I don't currently see the performance benefits of running dispatcher in front of author as the only thing being cached is some elements of the login page. I know I can now add 'expires' headers to the JS/CSS files but thought that was just a side benefit.


          Am I missing something - I feel I must be?


      Thanks for any help.


        • 1. Re: How does dispatcher on Author increase performance?
          Jörg Hoh Adobe Employee

          Hi Colin,


          For the authoring usecase it makes sense to set /allowAuthorized to "1", so even files, which are requested with security enabled (e.g basic auth) can be cached (according to the caching rules). The security risk is very minor, since on authoring only javascript, CSS and images of /libs, /apps and /etc/designs should be cached. Content must not get cached.


          Caching these elements and adding expiration headers on them will give you a performance boost while working on authoring with a browser. If you have ever checked how many files a switch to the editmode or the siteadmin are requesting, you see that more than 50 files are downloaded, the vast majority being CSS, Javascript and small images. When switching in editmode, only 5-6 requests are made which cannot be cached (the .html file plus some json requests to populate the page dialog, the sidekick etc).


          So if you are able to eliminate (more than) 90% of all requests based on simple caching, you will get a huge boost in rendering the page, especially if the latency to the server is higher. For me this boost is worth the additional effort of setting up a dispatcher.


          (Usually I don't care about invalidating these files. When a new release is deployed on authoring, the cache is dropped as part of the deployment process, so that's not a problem.)



          • 2. Re: How does dispatcher on Author increase performance?
            Nainan Markose

            More importantly if you access the author over a slow network do also configure gzip on the Apache so that the widgets.js ~6-7 MB and other heavy files come zipped

            1 person found this helpful
            • 3. Re: How does dispatcher on Author increase performance?
              Colin-P Level 1

              Thanks Jörg and marking as the correct answer, changing the /allowAuthorized to 1 does then give the benefits I was expecting. Perhaps someone from Adobe could update the files they provide (kb article) to have this as the default as it seems strange that the one they offer doesn't cache much.



              • 4. Re: How does dispatcher on Author increase performance?
                Colin-P Level 1

                Thanks Nainan - good point. I'd thought of setting expires headers to ensure browser caching but you're right that widgets.js would clearly benefit from a gzip.