Sanity Checks for CQ5 Installations

In this blogpost I listed some basic checks you can do after you have done a (production) installation of CQ5(.4). The checks can mostly be done via the browser, and will give you very quickly an rough idea whether you are almost done, or still has to start.

1. Admin screens

The following urls should not be accessible:

http://yourwebsite/system/console

http://yourwebsite/system/sling/cqform/defaultlogin.html

http://yourwebsite/crx/de/index.jsp

If these pages are accessible, then you have to revisit the security settings mentioned in this document :

http://dev.day.com/docs/en/cq/current/deploying/security_checklist.html#Restrict%20Access%20via%20the%20Dispatcher

2. OSGi-configuration

Go to the site, and try these two urls :

http://yourwebsite/somepage?wcmmode=edit

http://yourwebsite/somepage?debug=layout

If you see the page changed, that will give you an indication that the basic OSGi-configuration is not done, you can find these settings in this document :

http://dev.day.com/docs/en/cq/current/deploying/configuring_osgi.html

3. Basic error-handling

Go to your site and go to a non existing url/page :

http://yourwebsite/notthispage

This should result is a decent errorpage, and it should not redirect to the sling login screen.

Here a document that explains how to customize the error-pages

http://dev.day.com/docs/en/cq/current/developing/customizing_error_handler_pages.html

4. Dispatcher and caching

For the blogpost I just took Jmeter to generate some simple load on the website. When you are able to generate some load on your installation it is much easier to see whether particular setting are working. And it will give you a first idea on the load on the machines.

(screenshot from Jmeter)

Begin with some very simple urls, like :

http://yourwebsite/homepage

http://yourwebsite/homepage/about-my-company.html

Now you can check your dispatcher and loadbalancer (if installed) if they are working as it should be. You should be seeing entries in the log-file.

When caching is configured on the dispatcher, you can easily verify that by changing the url to http://yourwebsite/homepage?a=b . Because the dispatcher doesn’t cache pages with a ? in it, all these requests will handled by the publish instance. And therefore the throughput will go down a lot.

Here you can find some basic dispatcher documentation:

http://dev.day.com/docs/en/cq/current/deploying/dispatcher.html

Handy documentation

Here some handy documentation around performance and the general knowledge base.

http://dev.day.com/docs/en/cq/current/howto/performance_monitor.html

http://dev.day.com/content/kb/home/cq5.html