Scalable Publishing Models
Movable Type provides a number of publishing options. Users can elect to publish their web site statically or dynamically, or selectively choose which components are static and dynamic.
By default Movable Type publishes static HTML files that collectively make up a user’s entire web site. This static publishing model has many benefits, including:
- an intuitive and well establishing scaling process - nothing scales more easily and more cost effectively to meet the demands of highly trafficked web sites then static HTML files
- higher reliability and availability of content - static HTML files have no dependency upon a database, therefore all of the following could happen without affecting the availability of your content:
- your backend publishing system can easily be taken offline for maintenance
- you could suffer a major outage
- your website receives an unanticipated spike in traffic due to popular web content
- your website receives an unanticipated spike in traffic due to external factors outside your control such as DoS attacks
- more integration options with legacy publishing systems and application servers - Movable Type is not limited to publishing HTML alone. Movable Type can also publish PHP, JSP, ASP and files coded in a variety of languages for a variety of platforms; this means that you can more easily integrate Movable Type with existing systems and code bases
By default Movable Type performs all publishing in a synchronous manner. Meaning, that when a change is made to content, the application “blocks” while the necessary files on the web server are updated with the newest content. For the vast majority of users this is not a time consuming process, but for some, this can be undesirable depending upon a combination of one or more of the following factors:
- the size of the web site - when a Movable Type installation exceeds 10,000 entries or pages, not to mention their comments, publishing times may slowly increase
- template structure and architecture - some templates are not configured for pagination resulting in Movable Type having to publish extraordinarily large files; plus the unique requirements of a web site may require templates to be structured or written in such a way that might not be optimized for publishing speed
In an asynchronous publishing model, publishing is not handled by the core Movable Type web application. Instead, publishing is deferred to one or more backend processes. When handled in this way, publishing times, or the latency between the time content changes and the time that change is reflected on a live web site can be dramatically reduced.
When asynchronous publishing is enabled, whenever a change is made to content on your web site, Movable Type adds a task to re-publish a file to a job queue for each of the affected pages on your website. This process is very fast and allows the Movable Type web application to return control to the user much more quickly.
Meanwhile, another process running on your web server, or elsewhere in your network, monitors the Movable Type job queue for work to be done. As soon as a task appears on the queue, it is claimed by a “worker” to be completed.
One of the advantages of Movable Type’s Asynchronous Publishing system is its ability to scale to meet the needs of any web site. Very popular, or very large web sites may very quickly generate too much work to be accomplished quickly by a single publishing daemon or “worker.”
To address this, Movable Type can be configured to have multiple daemons running concurrently to increase the throughput of your publishing system. Furthermore, daemons can run on dedicated machines creating a very logical segmentation between your Movable Type application server and your Movable Type publishing system. This allows network engineers to scale these two critical components independently from one another to meet the demand of your unique environment.
Furthermore, publishing daemons can be deployed to multiple machines allowing for the tasks of publishing and keeping the files of your web site fresh to be shared by as many resources as you can afford or need. This allows for you to:
- build redundancy into your system and eliminate single points of failure.
- create a higher performant system by splitting the needed processing time across multiple machines.