|
Did you find this page useful? If so, please consider linking to it
- or use the bookmark facility at bottom right. Thank you.
How does CMS work?
A website CMS or content management system is often the best way to run a large website, or indeed any site where regular edits or changes are made.
The term CMS means the singular or the plural, since it also stands for content management systems. These website applications work in a different way from normal sites, in that there are usually no pages at all on the webserver, apart from error pages and the like. Instead, there are configuration and application files (i.e. the 'works'), plus image and graphics directories, and a database. The pages are constructed on the fly, from text in the database, graphics or any other subsidiary files needed, and publishing parameters (instructions) - also from the database.
All CMS use a database (DB) of some type, the most common being a variation on the SQL theme ('structured query language'). If no SQL database is available, then there is an alternative: a flat-file DB, which is essentially a text file. Naturally, these flat-file CMS applications are limited in terms of the maximum number of pages possible, but they can nevertheless be a better proposition than a standard HTML site for some purposes. If content is changed regularly, on a smaller site with no SQL on the server (or no access to the management apparatus), then a flat-file CMS could be the answer.
There are also a very small number of client-side CMS apps: these have the main application resident on the local PC instead of the server, and pages are generated locally then uploaded to the server. It is debatable whether this method of operation should be called a CMS or perhaps a website generator. It is used when there is no database on the server; when there is no access to the server management or even a control panel; or, finally, when the pagecode of the dynamic CMS is unacceptably script-heavy and a lightweight HTML alternative is needed.
So let's lay that out in short form:
1. On a normal website, the web pages exist on the server.
2. On a CMS site, there are no web pages on the server.
3. The CMS will normally use an SQL database of some kind to store the page text in.
4. The pages are built on demand and do not pre-exist.
How a page is created
A normal HTML website's operation is completely different from the way a CMS works. On a standard site, all the pages exist on the server. However, with a server-side web application such as a CMS, pages are built on the fly; they do not exist before a browser requests one. The sequence might go as follows:
1. The visitor's browser requests a page from the server.
2. The server (often Apache) looks in its cache to see if that page is in memory, having been previously served within a set time period. If yes, it supplies the page and its associated files.
3. If not, the server requests the page from the CMS.
4. The CMS looks in its own cache, if it has one, and if it locates the page pre-built, it then supplies it.
5. If not, it builds the page: it gets the publishing parameters and the text from the database, then graphics, images and other components from the relevant folders, builds the page, and passes it to the server app.
6. The server passes the page along to the browser. It also carries out
a multitude of other tasks simultaneously: it queries the top-level
htaccess file, queries the local htaccess file for all sorts of options
and variables, serves the page's associated scripts such as CSS and JS
scripts, executes any scripting, hands out one or more cookies, hands out the favicon, logs all the traffic involved with that page request, logs any errors; and all in 0.25 of a second - hopefully.
This
sounds a bit involved but normally takes little time even for the
longest process (provided that all parameters are optimal, which they
hardly ever are). In reality there are some drawbacks.
Server overhead
This
procedure requires some server overhead, building the CMS pages and
carrying out the other tasks. It uses CPU time, memory, and all other
resources on the server computer. This translates into two things:
server load and extended page loading times.
This can be measured by benchmarking, which is built in to Apache server and therefore fairly easy to measure. As an example, while serving ordinary flat HTML pages, servers commonly benchmark at between 100 and 400 pages per second. The lower figure is a more realistic one, higher numbers only being possible when all parameters are absolutely optimal, which is unlikely in a production environment.
This means over a hundred visitors can be catered for per second on a standard webserver, all being well. This is a phenomenal number since if you calculate it as a visitor number per day, it comes out to over eight million. Even allowing for a factor-ten error, it is still far more than is ever likely to be encountered on most sites or even most multi-user servers. However, these are in effect theoretical figures because it is extremely unlikely a production server could supply pages this fast, multiple sites on the server will introduce all kinds of other problems, production servers have to execute other queries, a server cannot run at this load indefinitely, and neither can the network supply such a load to a single server. Even a factor-one hundred reduction in the page per second figure might not be sufficient for production.
However, when a CMS is used, pages served commonly drops to around four per second on the benchmark tests. Whoops! This is actually a much more realistic figure for a production server in any case; but because of the difference between a testing environment and a production server, as we saw above, the actual real-world figure is probably lower. Even four pages per second is a vast number that would not normally be required on a dedibox, though it might be needed on a busy multi-user server; but due to the difference between reality and benchmarking, the real figure in production is in any case probably even lower still.
These time lag and server load questions are partly resolved by caching - the 'memory pool' on both the CMS (usually) and the server which keep popular pages in memory, ready for instant serving. If nothing else this shows that a server needs plenty of RAM and fast disks. It also explains why server disks are more likely to fail than desktop PC disks.
Types of CMS
Content management systems can be divided into many different kinds, for several different purposes. Firstly, there are website CMS and non-website CMS. The former are designed to serve content on the Internet, the latter to contain and organise an enterprise's information in a private environment. Here, we are only concerned with website CMS.
The next division is between the various classes of function, for example:
- The lightweight class
- The rich media type
- The online brochure type
- The community / news model
- The provider-consumer model
- The enterprise-level publishing class
- The ecommerce-enabled type
The most basic division is probably between the community / news model, and the provider-consumer model. These model types refer to whether a CMS is best suited to many people providing content, or one person or a small team doing so. The community model can be further subdivided into two sections: those suitable for one group or those suitable for multi-group use.
And so on, for other classes of CMS (see elsewhere on the site). In fact most CMS can perform several functions, although there is one feature that must be available in order for the CMS to work as a community type: frontend content editing and upload. Here, people can login via the frontend (as against the backend, which is the standard method and just for admins), and either input material or edit it online.
Often a CMS will function well in two or more classes, perhaps depending on what extensions are provided. It is possible to produce two or more versions from one basic CMS core, each being particularly suitable for one type of function.
A community / portal type CMS will function satisfactorily as a provider-consumer type with no modifications. The latter type is simpler because it requires fewer features, especially in the area of ACL. This refers to access control lists, or if you like, user rights - group or individual privileges such as editing, publishing and so on. This feature set is the most complex to provide, and to get right. An enterprise-level CMS must have a core feature set of elevated capability, including full ACL (group roles), versioning, workflows, and audit trails. It is therefore the most complex.
Factors affecting how a CMS worksThe vast majority of CMS work the same way, but there are a small number of factors affecting this. A few CMS can work additionally as a client-side application, and one or two only work this way. That means the application resides on the local machine (the PC) and the pages are generated there, then uploaded to the server. Thereafter, the CMS works in the same way as a normal flat HTML site - meaning that there is no scripted interaction between user and website.
Different types of DB affect how some CMS operate (SQL or flat-file), though this is transparent to end-users. A CMS normally functions as a managed content publisher, rather than a library of pages; and so it needs to be seen in a different light to flat HTML websites. It is best used as an interactive repository of information, whether that be at the first level, simply between owner and application; or at the second level, between visitors and the application.
The capability of individual CMS decides how many jobs they can do, how well, and in how many different ways. As new plugins are developed, new functions become available. From just being a convenient way of editing text, they now act in some cases as fully-interactive central community facilitators.
Servlets
Some CMS cannot run independently and need an additional application as a buffer between the CMS and the server app. Such an application is called a servlet, servlet container, or an application server, examples being Apache Tomcat and Zope.
CMS using these are much more restricted in the type of servers and hosts they can be used on, and in many cases require a dedicated server; support is also likely to be more restricted and expensive. For this reason they are best avoided unless your enterprise has specific needs that can only be addressed by using one of these applications.
Here is a list of application servers:
Apache Tomcat
JRun
WebSphere
BEA WebLogic
Sun-ONE
Zope (can run standalone or as middleware for another app)
This brief run-through of how CMS works / what cms means / what a cms does, should have filled in most of the gaps for you. We would appreciate any further questions, or comments, so the page content can be improved.
|
