Hi
Is there a maximum number of customisation one can have for a given design?
The system sets no limit - but the processing is intensive and PHP runs out of memory or time at some point.
So, yeah, there is a limit to most designs, but it depends heavily on the hardware/number of design areas/number of associated files etc.
The rule of thumb we've been using for clients running a dual-processor Xeon server with 2gb of RAM is 5 customisations per design. That tends to work well. However, as Greg says, it depends on the nature of the design. I have one client with a design that has over 10 customisations and is still parseable, as it only has two associated files and very few design areas within the parsefile itself.
This is all news to me - I dont think I have read this before or been told it at any stage.
The fact that we are doing a very large website (thousands of pages) with many distinct areas (possibly as many as 50) I was hoping to do a customisation for each area. Even though I have now put a lot of initial work into setting this up, it seems that I should probably stop.
Is there any way to have that many customisations? None of the customisations have any associated files but there is about 6 design areas in the parse file.
At the moment, I'm recommending to my clients to create multiple design assets to support that amount of customisations. Remember that associated files (like CSS and images) can be shared across multiple designs, if necessary. Essentially, you use the same parsefile to create several identical designs, each with their own set of 5 customisations.
In this way, you'll need 10 Design assets to comfortably support 50 customisations. I am aware of clients with far more than this (upwards of 30 identical designs), so the process does work.
I will probably be in SteveB's situation with a very large number of customisations for one master template.
I don't quite understand what is intensive (or should the question be when is the process intensive)? Are you saying that a page with a customisation applied to it will take more or less time to load for the end user depending on how many customisations the design has?
I don't mind going into a technical explanation of how designs and customisation are called when a page is requested (data flow diagram, architecture design, anything would do…).
[Would an alternative option be to clone the design and limit the number of customisation per design? Edited: Avi answered this question above while i was writing my post]
The frontend performance is absolutely not affected by this issue.
The problem is based on how Matrix creates the designs. When you commit a parsefile, Matrix analyses the file and creates a design_file.php, which is a the design in PHP code format. Each customisation gets its own design_file.php, so when you commit a new parsefile, or manually reparse, Matrix has to analyse the parsefile and write out the design_file.php for the master design and each customisation.
This process uses a lot of memory and takes a long time. The limit to customisations is based on how many design_file.php files Matrix can create until the PHP process either runs out of memory or time.
Also, I don't recommend using the Clone feature to create multiple designs. Rather, create a new design and upload the same parsefile to it. Then, use the "New Link" option to link the existing Associated Files from one design to another. That way, if you modify the CSS, for example, the changes will be applied to all the designs that use that CSS file.
Avi,
what do you mean by "At the moment"? Do you guys see this problem being resolved or is it here for the long run? It seems you are technically restricted by things you cannot necessarily control (eg PHP memory/timeout) so I guess the problem is here for a long while.
This problem seems to reinforce a growing concern of mine that Matrix is written more for smaller sized websites with centralised publishing than larger websites with a distributed publishing model.
Steve.
Definately an "at the moment" problem. We are very aware of the issue and will be working to resolve it as soon as we are able. Matrix is designed from the ground up to scale to millions of assets and is geared towards very large, distributed authoring environments. We are actively working to make this easier and more usable as the sites scale in size.
I am glad to hear this. I am currently up to around 30 customisations (this eventually will be 100+) and already I am having trouble keeping the parse files in synq with each other.
While other parts of Matrix seem perfectly capable of managing very large sites, this issue alone is very limiting. You can't get away with half a dozen customisations on a 10,000 page site, but you don't want to be managing 50 duplicate parse files and their associated css files!
Any Ideas when this work will be underway?
Summary of the (old) post:
- "At the moment", there is no way to have 1 design with a large number of customisations (20+).
[quote]Any Ideas when this work will be underway?
[right][post=“4121”]<{POST_SNAPBACK}>[/post][/right][/quote]
Just prompting this again.
I know there is a lot of development going on, but I was wondering if there was some progress in that regard? I’ve noticed Bug #252 is marked as “Will not fix” since July 05. Does that mean the issue is not on the agenda anymore?
Cheers.
I currently have designs with 20 or so customisations on v3.6 with an optimized PostgreSQL database. However, there is no current development to resolve this in the v3.x branch of MySource Matrix. I know that its one of the concerns of our internal discussion into the architecture of the v4.x branch, which is due to begin development next year.
At the moment, the limit to the number of customisations is purely hardware/resource based: You can have as many customisations as your setup can parse in a single load. Different installations will have a different maximum number of customisations (which is also design based: the more design areas you have, the more processing is required to parse the design).
Some comments based on our experience which may be useful.
Our setup:
We have one master parse file and a bunch of customisations.
1
2
2a
2b
2c
3
3a
3b
3c
4
4a
4b
5
5a
5b
6
6a
6b
6c
6d
6da
There are no associated files under any of these.
All image files are linked either via CSS designs, which are statically coded into the parse file, or directly.
The CSS Designs are not assocaited files either, being hard coded.
This mostly came about as we wanted to use a CSS browser exclusion technique, so had to code things manually in the parse file.
The only downside is having to have a customisation to enter the static asset number for the CSS file for each section's customisation.
(If you look at radionz.co.nz you'll see each section is colour branded - this is all done via CSS and one body class. The body class and the CSS file link are customisations in the parse file).
The above parse file has 18 possible customisable areas and takes 8 seconds to parse on a dual Xeon with 8 gigs of RAM.
When we used to have a lot of assocaited files it used to take a lot longer to parse.
Avi can probably comment on how much impact moving out associated files in this way might have on other systems.
cheers,
Richard
But i shouldn't dream of 100+ customisations right? 
Would forking the process of parsing and generating the design.php be an option? (big stab in the dark there…)
We have tried a few different things to try and resolve this issue. I'm not sure if forking has been attempted or not, that's best answered by the development team.