We often joke in presentations that you could throw the CMS out of the office window and your website would still be fully-functional; perhaps an extreme example but it demonstrates the point.
All files are sent via FTP to the web server. All you need do on the web server, using IIS as an example, is simply configure the FTP and configure a website to point at it. There is no need to install any Contensis software on the server at all. This means that once you have a server available for Contensis to publish to, it will take care of the rest for you. We deploy the entire bin directory through FTP, configure the web.config and publish all the ASPX pages.
If you want a new server in your load balancer, or just a hot replacement server for the event of failure, then, assuming the server has an OS and IIS installed, your site can be publishing to it in less than five minutes.
Some may ask, if you are publishing pure flat files, and the system is decoupled, then how do we produce dynamic data or render menus. See how our navigation XML makes this possible.
We do not charge for extra front-end web servers; requiring only a standalone server per front-end server, the cost of resilience and scalability is low.
More detail on disconnected publishing.
Supported web servers
As Contensis publishes using FTP, you can use any web server which serves files. If you want to use our standard .NET web controls, you'll need a Microsoft IIS server. If you are happy to develop your own controls, or wish to use Java, PHP or JSP, simply configure this against the templates and define a standard publish template.
We support publishing to any web server. Examples include Apache, Domino, Zues, Yaws, Microsoft IIS (Internet Information Services) and Zope, to name a few. Read a brief comparison of web servers.
System resilience and scalability
Resilience and scalability for the front-end is very simple; just add any number of web servers you like, frontend with an IP load balancing system. There are no extra licence costs, just pay for the server and operating system licence, then the system can be up and running in as little as ten minutes.
Contensis does not rely on a single or cluster database server, ensuring we don't have a single point of failure from a performance perspective.
If customers are expecting high traffic, we recommend load balancing their web server to ascertain a level at which it will happily serve requests and, if necessary, introduce extra servers to cope with extra load.
When we are looking at performance, load is obviously an issue but what you can get out of a single server is very important too. Contensis has had literally hundreds of tests applied to ensure we get the most we possibly can from the code. We use tools such as Ants Profiler to examine, line by line, our source code to ensure that there is no better of more efficient ways to achieving the same result. We find that often a switch from using a regular expression to a brute force code search, for example, has improved areas of the system by as much as 500%.
When running in a .NET environment, we naturally utilise ASP.NET page output caching, which we have found can improve performance by up to ten times. However, this should be configured carefully in situations where you have dynamic elements such as a news homepage, as you want to make sure that the caching is not preventing new news from coming through for too long.
Typically, a caching implementation is done on every new system that goes live, and generally it can be configured in a few minutes. The difficult part is just ensuring you agree the principles from a management perspective – i.e. how long are we happy to wait for the latest news article to appear; one minute, five minutes, an hour? As each page of the site or type of page can have a different cache profile, we simply need to decide these profiles and then implement them.
Disaster recovery is important for all of our customers. We provide scalability and disaster recovery solutions at a fraction of the cost of our competitors by publishing data, if required, to each of the front-end servers. This means there is no requirement for a SQL cluster in the front-end web architecture.
Removing the requirement for a SQL cluster, and SQL Express being used for each of the individual web servers, can offer a saving of over £20,000.
You may wonder how SQL Express can be used in an enterprise scenario, but bear in mind that Contensis operates a disconnected publishing platform, so the database is used only as an index for certain data and rarely exceeds the 4GB limit even in configurations with 50,000+ web pages.
Probably the most important area to consider is the cost saving, which in today's economic environment is an important factor. Contensis offers the same resilience and scalability at a fraction of the cost.
Cost is important, but so is time; a complex solution is much more onerous and requires far more maintenance.
Web architecture - resilient A
Contensis can be deployed in an environment with any number of front-end web servers.
There is an optional SQL cluster; you only require an SQL database if you use specific Contensis modules or features which require one. You could be using a different database server such as Oracle to service dynamic data.
Web architecture - resilient B
This architecture is the most cost effective way of delivering Contensis within a totally resilient solution.
Contensis can publish a separate set of data to each of the SQL servers installed on the web servers. Even with the largest implementations this SQL database rarely exceeds 4GB, meaning SQL Express can be used, which is free.
This architecture gives you database resilience without the need for an SQL cluster and the extra hardware and licences that they require.
Web architecture - non-resilient A
This architecture gives you a single server deployment, which means that if the server fails for any reason, your website could go down.
This architecture includes an SQL server on the web server to serve any dynamic content. Often SQL Express could be used in this scenario.
This solution is likely to be the most cost effective architecture. If you run VMWare or another virtualisation technology, restoring the system in the event of a disaster has minimal configuration requirements.
Web architecture - non-resilient B
This architecture is identical to non-resilient A but has a separate database server. The solution is simple but again non-resilient if the single server fails.
The database server would normally be separated for performance reasons, but could simply be because you already have a SQL server configuration in the web hosting environment.The SQL server could be a SQL cluster if required.