Hi,
what would be best in terms of system performance:
- placing designs' associated files in a web browsable directory (outside Matrix) and Alias it in Apache's config.
- placing thoses associated files in Matrix.
Cheers, Eb.
Actually, Matrix does that for you.
When an associated file (or any file asset, for that matter) goes Live, with Public Read permission, Matrix moves it to the system_root/data/public location. This is already aliased in Apache as "/__data".
Then, Matrix replaces all URLs inside the content (and design) with the new "/__data" URLs. These files are then served directly by Apache.
In fact, in the Dev version of Matrix, you can chose to offload these files to a completely different webserver. We provide a new "Static URL" configuration option for you to configure a static file URL for Matrix.
Isn't there a mysource_files/ parsing that needs to occur if the files are associated?
[quote]Isn’t there a mysource_files/ parsing that needs to occur if the files are associated?
[right][post=“6740”]<{POST_SNAPBACK}>[/post][/right][/quote]
Yes, but Matrix does this automatically too. The design code that is written out will automatically use the correct URL for the associated file, whether that’s a Matrix friendly URL (because the associated file is either not live or not publically readable or both) or a direct URL. The output HTML will contain the correct URL.
Cool, thanks.
Just a clarification: The mysource_files/ location parsing is done when the Parsefile is saved (or a manual parse is chosen). This is then saved as an array of URLs for the design.
When a page is requested (i.e. when surfing the frontend), Matrix just retrieves the URL array and replaces the URLs on output. Therefore, there is some processing, but its very fast.
However, for ultimate performance at the sacrifice of being able to manage the static files within Matrix, you could replace all the mysource_files/ references with absolute static URLs for content. However, Matrix will obviously then not control those files, so they will always be available. On the other hand, Matrix will also to absolutely no processing to create the output HTML for those files either.
My personal opinion is that the performance benefit would only be really noticable on a design that had 50+ associated files with a userload of more than 20 simultaenous requests. The URL retrieval system Matrix uses is pretty quick. 
Though, that does highlight a design tip: Always use as few design areas as possible, to reduce the overall processing that is required. So, instead of using constant button design areas, if the destination of the link never changes, hardcode the link instead: Less processing, better performance.
We've also addressed this in the development version of Matrix, and have now allowed design areas to cache themselves as well. This will also dramatically improve performance on designs with lots of design areas.