A kill switch is a fast and convenient way to turn a system off. Web site kill switches serve to turn off all software processes that drive the website, so that site traffic no longer causes web applications to run, or databases to be changed. This can be a useful feature in a few circumstances, eg.:
ExSite has a couple of built-in kill-switch features that may help in these circumstances. Unlike many CMS systems that are primarily dynamic in character, ExSite has both dynamic and static pages. Static pages provide a snapshot of the page at the time it was published, but do not require any software processing or database access after that, and so have a very low impact on server resources. It is normally quite safe to continue serving static pages in all of the above cases, so ExSite kill-switches do not stop serving static content; only dynamic content will be affected. (There is one case where you may want to stop serving static content as well, and that is when you are concerned about bandwidth usage. See the Bandwidth section below for tips on this situation.)
To stop dynamic page views altogether, add the following parameter to your exsite.conf file:
kill = 1
This has the effect of disallowing any execution of page.cgi. Any attempt to run page.cgi will be redirected to the killurl, which you can define in your conf file, eg.:
killurl = /website_not_available.html
It is a good idea to not include the website domain name, but do include the path to the killurl. This has the effect of keeping the page address the same as the originally requested page. Otherwise, the address will change to the killurl.
A default killurl is provided by the system if you do not specify one.
Other CGI programs (eg. your admin screens, home.cgi and ctrl-panel.cgi) will still function normally, so administrators can perform web-based system maintenance at this time.
Don't forget to unset the kill switch when you are ready for traffic again!
ExSite has a second kill switch that triggers automatically. It is sensitive to the 1-minute load average of the server, and if this exceeds a preset value (default is 10.0), then dynamic pages will be redirected to the busyurl. As with the main kill-switch, you enable this feature by turning it on in your exsite.conf file:
busy = 1
And provide an optional URL to handle the request:
busyurl = /server_is_busy.html
The default busyurl will attempt to reload the page after a 10 second delay. This has the effect of giving real viewers another chance to view the page, but blowing off robots and other automated agents.
To adjust the load threshold at which the busy switch triggers, use the busyload configuration parameter, eg.
# no tolerance for high traffic busyload = 1.0
The busy switch automatically disables when system load falls back to acceptable levels.
The simplest way to understand load is that a value of 1.0 means that there is enough work for 1 CPU core to work on flat out (no idle time). A load of 2.0 means enough work for 2 CPUs, which is great if you have a dual-core system, but not so great if you only have 1 CPU, since everything will run twice as slow. When load is more than 4 times your number of CPU cores, the system will start to feel very sluggish, and at 10 times your number of CPU cores, will feel barely useable. Under a serious DOS attack, loads of over 100 are possible, which can completely paralyze your server, even if it manages to stay up without crashing.
Note that the busyload parameter does not specify a maximum load that the system will go to; only the maximum load at which page.cgi will execute. The load could spike well above this if other processes on the server are also demanding resources.
Load is checked when page.cgi starts executing, after basic system initialization, but before any database connections are made. That means that even in an overloaded situation, the CGI program still has to start up, with whatever overhead is required for Perl to load and compile the program. This will actually increase the server load. However, once compiled, it will terminate and free up its memory immediately once it detects that the server is overloaded, preventing additional load from being incurred due to program execution, SQL calls, accumulation of data, etc. If you run in a Persistent Perl setup, where the CGI and Perl overhead is minimized, then the cost of starting up is low and it will not contribute significantly to the server load.
Note that the system load is retrieved from the system file /proc/loadavg. If your system does not have this file, then it does not support the busy kill switch.
Sometimes it's not the server's memory and CPU resources that you are concerned about, but rather your bandwidth consumption. ExSite does not monitor its bandwidth usage, and its kill switches do not really help with this problem, which is better handled at the webserver or firewall level. However, if bandwidth usage is unacceptably high, or is expected to become unacceptably high, then there are a few things that ExSite can help with: