print Scorpio Performance Tuning

Basic tweaks and i18n tricks

Scorpio, like any other framework has a variety of configuration settings for the MVC layer. While many of these are documented in the configuration documentation, that article does not give guidance on how best to configure a website when using Scorpio. This article will look at what you can do for relatively easy performance gains, as well as some more involved tips that usually mean code changes.

Know your (master) options

The very first thing to do is make sure that you have a sensible log level. For a production deployment a log level of warning (8) should be sufficient, however if you need slightly more detail then notice (16) can be used, though it is not recommended. You should set this in the master config.xml file in /libraries. The option is: system -> logLevel

Next up, make sure that production mode is set in the master config file. This should always be done for several reasons, the first being that it suppresses as much error output as is possible and second it prevents debugging code-paths running altogether. Production mode can be toggled by setting the config option system -> isProduction.

Lastly: Scorpio checks that temporary and log file directories are accessible to the current script. So long as they are you can disable this check (not recommended for dev systems). This prevents two file stat calls during the system::init(). Set this again in the master config.xml file. The option is: system -> checkFolderPermissions.

Tweak your site options

Each site has its own range of options (including individual logLevels). Some settings though can cause issues if not correctly set-up first. With that in mind, the simplest options will be covered first.

The first option is to always enable static page caching. This ensures that any static page once generated will always be cached. Static pages are those that are accessed via the staticController (/static/my-page-name). Set the option: site -> cacheStaticPages.

Next disable or don't use un-necessary distributor plugins (Scorpio >= 0.2.0). This includes sessions, device detection or other custom plugins. You should maintain the log plugin as that creates friendly log files. Distributor plugins are configured in the distributorPlugins section. To disable a plugin give the full name as the option name attribute and set a value of 0 (zero). If a site inherits plugins, they will be disabled if specified in this manner. Naturally some plugins are dependent on one another (device detection requires session support for instance) so be sure to test in development / staging before rolling out.

And now the tricky options. By default the mvcAutoload system maintains and auto-builds a file cache. This contains all the classes and the FULL path to that class. For maximum performance, the cache should be enabled but the auto-save disabled. For this to work the entire cache for all controllers, models, views, custom libraries etc must be present in the cache file. Luckily this can be auto-built using the scorpio.php CLI tool. Once created the auto-save can be set to 0 and the related option alwaysPreloadSiteClasses set to 0 as well. alwaysPreloadSiteClasses forces the mvcAutoload to always parse and pre-load any classes that have been defined in the classes section; but as these have been stored in the cache, they can be disabled.

The cheaters i18n setup

So far we have only looked at configuration directives. That is by far the easiest means of getting some "free" performance boosts. What if you have to run an internationalised site? Well this depends on which template engine you have used and how you have setup your controllers, views and the cache times in the views. If you use the default Smarty engine for your view layer, your options suddenly become quite interesting.

By default, Scorpio includes a language prefilter that is always loaded with the MVC View Smarty engine. When i18n is in-active (the default) nothing happens and the plugin does nothing at all. However: when enabled, the prefilter will translate text using whatever configured options are set for the site. This has another affect; the view layer will automatically create compiler cache ids per language per template. What does this mean? Well for each language (e.g. you have English, French, German and Italian) as they are requested, the templates are compiled IN that requested language. So the translation layer only has to operate once per compile. After that the actual language has been cached at the compile level. Then each individual page can be fully cached afterwards. So not only is the script side cached, but full pages are also cached. A similar thing could be done using another template engine - if it is setup accordingly.

Of course, the downside to this strategy is that a huge number of temporary files are created which requries a lot of diskspace and everytime the language files are changed the caches have to be cleaned.