Symphony.

Have you guys considered some sort of intermediary caching solution (something other than MySQL query caching)?

Absolutely. The reason there is no solution in the core of Symphony 2 is that everyone's caching needs are going to be different. To give you a couple of examples, we have a number of large'ish client sites running Symphony.

One uses Symphony as a staging platform and pushes static content to a proprietary CMS that serves the live site. In this instance they didn't need caching per se, but rather spidering to render out all pages of the site and a mechanism to upload the static content directly to the live site.

Another site runs Symphony on a live server and required different caching methods for different pages. Some are time based, others are completely static. Some need to update automatically when content changes, and other pages require no caching at all.

The common thing between these 2 is that neither needed the same "caching" method, and the built in caching of 1.7 was not suitable for either.

Our goal of Symphony 2 is to have it running well for majority of people out of the box. We intend on providing some Extensions that introduce various forms of caching for those that need it. And for the sites that need really heavy duty caching, we suggest custom solutions, be it hardware, server level software, like your scenario, or custom Symphony Extensions, like in the case of example 2.

Especially for sites with a lot of transient data and semi-static content.

Agreed. There are some simple things we can provide that will cater for majority of situations. Most of the data Symphony deals with is semi-static like you say.

The only problem I would see is preserving the relationships among sections / custom fields / values in the new table structure of S2.

Hence why we do not want to introduce this kind of headache into the core. ;)

I'll have to agree with your approach. There are so many different scenarios you run into with clients it would be impractical to attempt to create a 'doc-cure-all' to address them all. I think it would be best to just introduce a watered-down, generic solution, but leave the system open enough for users to introduce their own.

It also looks like you've discussed some of the potential database issues in detail with my good'ole business partner, Nick ( the topic starter ), so I won't pester you with any questions related to that. ;)

Great job all around, guys! Even though I have my own XML/XSLT framework I use for personal client projects, I'll always use Symphony as my no-frills solution. A very well-thought-out solution, indeed!

Thanks for all your hard work! :)

Couldn't the use of a php accelerator as a bytecode cache improve performance further?

Perhaps, however they are server side solutions really.

I know, but the ecommerce app Magento for instance isn't embarassed advising to use APC for better performance, so once the app is fully optimized, it seems no taboo in the opensource world to just ask people to get their servers up to snuff.

I agree with you, however we don't want Symphony to rely on these things under normal circumstances. For heavy traffic sites etc, it makes sense to have MySQL query caching enabled and use a server side opcode cacher (like the ones you mentioned). We would recommend that as a starting point, and also hope to have some simple Symphony side caching extensions in the near future for general consumption.

Since the project is evolving, thinking of advantages/drawbacks of including fields in sections.

@coupet could you elaborate — is that a question?

generating new tables for each section’s entry data… and the performance > increase was quite dramatic… for sections that didn’t have many entries.

Great!

create individual tables for each field in a section.

advantages/drawbacks ?