Communique Performance Guide
Since I have recently been involved in a number of performance optimization exercisesI dug up some ancient slides on the "CQ Performance Optimization Methodology" and compressedthem methodology to five very simple rules that can be followed to avoid performance issuesfrom the get go.
It is important to understand that these rules apply mostly to web projects in generaland I think this guide is mostly relevant to project managers and managers to ensure thattheir projects do not turn into being performance challenged when launch time comes.
Rule #1: Plan.
While one would assume that it is obvious to plan for performance optimization it isa matter of experience to understand how to plan for performance optimization the rightway
In my experience there it is good practice to leave a around 10% of the projects effortsfor the performance optimization phase. While depending on the level of complexity of yourproject and the experience of your project team you may not use up the allocated time itis definitely good practice to plan for it.
I always recommend to have a soft-launch to gather real-life experience without havingbig communication internally or externally to avoid additional "political" pressure if possible
Once you are "live" performance optimization is definitely not over since this is thepoint in time where you experience the "real" load on your system and it is important toplan for "clean-up" from a performance stand-point after the launch.
Since your system load changes and the performance profiles of your system shifts overtime I definitely recommend to do a performance "tune-up" or "health-check" every 6-12 months.
Rule #2: Iterations.
Performance tuning is an iterative process that involves, measuring, analysis, optimization and validationuntil the goal is reached. It needs to be planned that way.
Try to implement an agile validation process in the optimization phase rather than aheavy-weight full blow testing after each iteration. This largely means that the developerimplementing the optimization has a quick way to tell if the optimization actuallyhelped reach the goal
one more thing: If you reached your goal, optimization is over.
Rule #3: Goal.
To get a good solid performance goal really is one of the trickiest areas, but I wouldreally recommend to get real-life logs from a comparable website (for example the new website'spredecessor). While it is absolutely ok to add margin on top of the website since one willgrow the website it is under no circumstances acceptable to just make assumptions about the traffic.
In my experience this is a very important step and once people are locked into theirperformance goals, even if they are based on wild assumptions, it is very hard to change themafterwards
Rule #4: Get Real.
If you go live with a website and you find out after the launch you run into performanceissues there is only only one reason for that: Your load and performance tests did notsimulate reality close enough.
Simulating reality is difficult and it is up to the project how much effort you want toinvest into getting "real". "real" means not just "real code" but also "real content"especially size and structure wise. Keep in mind your templates may behave completelydifferently depending on the size and structure of the repository.
Rule #5: One at a time.
It is important to optimize one bottleneck after the other. If you do things in parallelwithout validating the impact of the optimization one will lose track of which optimizationmeasure actually helped.
Comply with Day's performance guidelines
Please find the performance guidelines for CQ applications and templates here:Guideto good CQ performance. Generally speaking, keep your uncached html requests to less than 100ms.
Usual suspects
Based on experience there are a certain number of issues that frequently contribute to performanceissues which mainly revolve around (a) dispatcher caching inefficiency and (b) the use of query innormal display templates.
JVM and OS level tuning usually don't lead to big leaps in performance so I usually avoid themto the very tail end of the optimization cycle.
Your best friends during a usual performance optimization exercise are the request.log, component based timingand last but not least a java profiler.
http://docs.day.com/en/home/communique_4/cq42/development/developer_s_guide/performance/measuring_performance/what_is_good_performance.html
It is definitely impossible to mimic reality 100%. In my experience the differences between the test system and the production system (for example in terms of content size) are in orders of magnitude. Let's say 10k pages on the test system and then 1m pages on production.
So I think you just need to be reasonably close in the respective axis (content, code, setup...), 20% off either way or just testing on fewer machines (or just one) if scaling horizontally is perfectly fine. That's also why you build margins into your performance goals.
It is fairly simple, if you go live and your performance does not stack up with reality. This means that your test was not close enough to reality.
regards,
david
we try to avoid to have these differences between the productive systems. We improved the tests and now have a behaviour on our live systems, which is quite similar to the benchmark data.
I see the problem that loadtests which modify content cannot be undone, when your system keeps track of every activity (as CQ does). So every time you run the test you may get a slightly different result, one worse than the one before, because your systems handles more data than before.
regards
Jörg