Concrete5 is designed for flexibility at the cost of performance.
A very simple page can typically make 3,000 - 10,000 database queries in a single request which is utterly staggering.
For public websites you will need to enable full page-caching (or run an HTML cache like Varnish) which reduces the need for so many queries. Some blocks and plugins run into issues with full-page caching, however. As of v5.7 our experience is that it's buggy and requires thorough testing.
On intranets and community sites (where users need to login and permissions need to be checked), full HTML caches will not always be effective. In these cases you may need to audit your custom code and minimise the use of query-heavy Concrete5 functions, replacing with your own custom SQL queries.
Even the CEO of Concrete5 admits this:
You’re right that concrete5 uses quite a few database queries to render a page. It’s also true that if one is designing an application from scratch to serve one purpose, it’s quite easy to solve most problems in a handful of queries. As you know however, concrete5 provides a tremendous amount of flexibility right in the core. While I’m sure there will always be opportunities to clean up queries and the number of objects loaded, you’re always going to hit the database a lot when you have page, block area, and block level permissions that can each include multiple exceptions, timed releases, etc..
Our experience has been that its more important to look at actual use instead of abstract terms and gut based rules. We see concrete5 being used in two very different fashions at the enterprise level. Sometimes organizations are building extranet/intranets for their staff, dealers or partners. These often require complex permissions and workflow, which concrete5 allows a product manager to do without touching code. These sites, even at the enterprise level, are usually serving tens of thousands offers, and can run just fine on a well provisioned web server.
Other times organizations are building front end focused informational sites. These tend to be pretty flat in terms of interactivity and complex permissions. The benefit is from the ease of editing. What we do in those cases is run Varnish cache before concrete5, which makes the site faster than apache and static HTML files. I think you’ll find this to be much easier than gutting parts of the system on an as needed basis.
– Franz Maruna, CEO concrete5, March 2013
His response came from this article which explains the query problem well: http://www.headenergy.co.uk/2013/02/concrete5-enterprise-ready-not-entirely/
Our development agency maintains several sites in Concrete5, but after encountering too many bugs and performance issues we've chosen not to build any future sites on Concrete5.
