Chapter 3: The NodeWorx Webserver Management Interface Up Part I: Fundamental Webserver Management with InterWorx Chapter 5: Apache Modules 

4 Web Server Options

Figure 4.1 The Web Server Options box provides a graphical interface for the most important Apache configuration settings.
figure images/nodeworx/web-server/webserver-options.png
This part of the interface lets you set some of the main settings of the server that essentially dictate your server’s performance and ability to handle traffic. We will explain the settings in detail here.
HTTP Port
This is the TCP port on the server that the server will bind to on startup for HTTP connections. 99% of the time, this should be set to port 80 as the HTTP protocol spec dictates that the server be on port 80 and browsers by default connect to HTTP servers on port 80. The exception here might be if you are going to setup a proxy in front of the webserver on port 80 - such as a varnish cache or nginx. That is outside the scope of this documentation.
HTTPS Port
The HTTPS port that the webserver will listen on for HTTPS requests. Again, as with HTTP port, you will probably want this set to 443 unless you are putting some sort of proxy infront of Apache.
Server Limit
This setting limits the maximum number of processes you are allowed to set with the “Max Clients” setting. The thinking here is that if the configuration is re-loaded while the server is still live, you are allowed to change the Max Clients setting, but not the Server Limit setting. This will ensure that while the server is not fully restarted, the Max Clients setting cannot be raised above this limit. If you exceed Max Clients beyond this limit, you’ll get the something like this error:
WARNING: MaxClients of 750 exceeds ServerLimit value of 256 servers,lowering MaxClients to 256. To increase, please see the ServerLimit directive.
Max Clients
This controls the maximum number of processes that are allowed to be spawned by the Apache server. InterWorx ships Apache with the MPM prefork module, so each process is only capable of handling 1 HTTP request/connection. This means this limit essentially sets the maximum the number of simultaneous connections to the webserver. Keep in mind that raising this value will increase the CPU and Memory demands of the entire Apache process group and thus some consideration should be put into the hardware capabilities of your server prior to increasing this value outright. Also keep in mind that the “Server Limit” value must be increased too if you want to increase Max Clients higher than the value of Server Limit.
Start Servers
From the Apache Documentation:
The StartServers directive sets the number of child server processes created on startup. As the number of processes is dynamically controlled depending on the load, there is usually little reason to adjust this parameter. [E][E]http://httpd.apache.org/http://httpd.apache.org/docs/2.2/mod/mpm_common.html#startservers/2.2/mod/mod_status.html
If you have very tight system resources on a VPS and super low web traffic, it might make sense to lower Start Servers to reduce the footprint of the Apache process group. Otherwise there’s not much point as Apache spawns processes on demand as needed. Apache even will spawn processes and have them sit waiting idle if your traffic load goes up, just to ensure that new connections are not waiting on a process to spawn.
Spare Servers (min)
This is the minimum number of idle apache server processes that apache will have running at once. Idle means the process is spawned but there are no connections or requests coming in for it to service. Apache does this to always have extra processes available to handle new requests so there is little to no delay waiting on a new process to spawn. If the number of idle processes drops below this number, Apache will spawn new ones at the rate of 1 per second until the minimum spare server is reached. It is generally not recommended that this number be increased to high because the group of apache processes will begin consuming a large portion of memory and CPU, possibly deteriorating your machine’s performance or causing instability.
Spare Servers (max)
This controls the maximum number of idle apache server processes. If the number of idle apache processes goes higher than this value, apache will begin killing idle processes until this number is reached. This number should always be higher than Spare Servers (min), or apache will automatically set Spare Servers (max) to the (min) value plus one. Again, setting this value high is a bad idea. You don’t want your traffic to drop and then have a bunch of Apache processes sitting around consuming resources that the other busy apache processes and system services could be using.
Max Requests / Server
This setting controls how many requests an individual trial process may handle before being killed. With the prefork MPM (which is what InterWorx Apache uses), this essentially amounts to how many different connections a child process will handle before the master process steps in and kills the child. With KeepAlive turned on, only the first requests counts against this value, and thus this setting is truly unique connections per child process. Setting this to 0 will make the value unlimited, which is probably somewhat desirable. The impetus for manipulating this value is if you perhaps installed a module that might be leaking memory over time in which case this value would effectively limit the lifetime of a child process to a certain number of connections.
Timeout
Timeout affects the timeout values for a multitude of different parts of the webserver. It’s value is in seconds.
  • When waiting on the HTTP client to send data, this is the maximum amount of time that the server will wait on the client to send data.
  • When sending data to the HTTP client, this is the maximum amount of time that the server will wait on the client to acknowledge (via TCP) that the data has been recieved successfully.
  • With mod_cgi, this controls how long to wait for the CGI script to return data
  • With mod_ext_filter, this controls how long to wait on a “filtering process” - or program that intercepts the outgoing data and manipulates it. In most cases this is not extremely applicable because most hosts do not run external program filters. An example of a reason this filter module might be used is to append javascript advertising code to the outgoing HTML of a website if you offer free webhosting and want to advertise on the user’s sites.
  • With mod_proxy, this is the default timeout value if the ProxyTimeout value is not set. Proxying is used to have the webserver connect to another HTTP server and act as a middleman between the HTTP client and the endpoint HTTP server.
Keepalive
Keepalive enables the persistent connection feature of HTTP/1.1. This essentially allows a client to issue multiple requests utilizing the same HTTP connection. In HTTP/1.0, traditionally the client would have to make a new TCP connection per HTTP request they wanted to issue. This resulted in a lot of wasted overhead and CPU cycles on both the client and server side constantly bringing up new connections. The persistent connection feature allows the server to “feel faster” to the HTTP client as once a connection is established an entire site can be pulled down via a single TCP connection. Most sites these days have 10-20 assets per page load that each need an individual HTTP request to pull down. Keepalive is therefore recommended to provide the best experience to the enduser as it results in faster page loads.
Keepalive Requests (max)
With keepalive enabled, this limits the maximum number of HTTP requests that can be issued per TCP connection. It is recommended that this be a high-ish value for the best server performance. The default of 100 is typically fine for most hosts. Once an HTTP client on a single TCP connection hits the max keepalive requests, it must establish a new connection before continuing to issue new requests. 0 is unlimited.
Keepalive Timeout
The amount of time in seconds that a child process with Keepalive will wait for a subsequent request before terminating the connection. By default, it is 5 seconds. This usually is enough to keep a connection alive for a page load or two, but short enough that a child process isn’t waiting around longer than necessary for an idle HTTP client that isn’t going to issue more requests. On busy servers it might help to lower this slightly as for a page load, browsers will issue HTTP requests as fast as they are able to, and thus typically a 5 seconds is much longer than necessary. On the other hand, 5 seconds does allow for some leniancy for high latency clients.

4.1 Force Graceful Restart

This setting does not manipulate any configuration directive in /etc/httpd/conf/httpd.conf per say, but it does control how InterWorx issues restarts to the webserver. By default, InterWorx does a full restart by bringing down the apache process tree, and then starting it back up. In technical terms, InterWorx will issue the SIGTERM signal to the master apache process. The issue with this on servers with a lot of virtualhost configurations, (i.e. thousands of SiteWorx domains), this process might take a bit longer than necessary because it takes a long time for the server to completely process the entirety of it’s configuration during startup. As a result, InterWorx offers the abilty to do a Graceful restart, which sends a USR1 signal to the master apache process. Then the following occurs:
  1. The master apache will then advise it’s children to terminate when they are done handling the current HTTP request. This allows any currently active HTTP clients to continue accessing the webserver until they are done.
  2. The master apache process re-reads the entire webserver configuration and re-opens all log files. This allows for log rotation to occur if necessary.
  3. As children processes die off, the master apache process will replace them with a new generation of children that have the updated configuration settings.
This allows for a seamless restart without down time. The down side is that:
  • Certain settings, such as ServerLimit cannot be modified without a full restart. This might be an issue if you need to up this value.
  • The old generation children might still be writing to logs, so log rotation has no guarantee of whether it is safe to move logs around. As a result log rotation should wait an unspecified amount of time before trying to move logs around.
  • /server-status pages will not be zeroed out or cleared.

4.2 PHP Settings

Figure 4.2 PHP Integration Settings and Control
figure images/nodeworx/web-server/webserver-php.png
As PHP is the most popular web application programming language on the web, InterWorx mostly focuses on the integration of PHP and Apache as the main methodology for offering dynamic web application support to end users. The PHP Integration settings area of the Webserver Management Interface gives some basic control over PHP integration and is shown in figure 4.2↑.
PHP Version displays the version of PHP installed on the system that SiteWorx accounts will use and have access to.
PHP Mode controls how PHP is integrated into the webserver software. The two choices, “PHP Scripts run as apache” corresponds to mod_php and “PHP scripts run as SiteWorx user” corresponds to suPHP. The two differ in that mod_php has the PHP interpreter integrated into the webserver process while suPHP calls the PHP executable externally and runs it as the linux user associated with the SiteWorx account. This topic is covered in more depth in Chapter 8↓.
PHP Info Status Page will show you the current PHP server configuration as visible when the phpinfo() function is called. It will display the current setting from the /etc/php.ini configuration file, as well as all the PHP extentions that are loaded.
 Chapter 3: The NodeWorx Webserver Management Interface Up Part I: Fundamental Webserver Management with InterWorx Chapter 5: Apache Modules 

(C) 2017 by InterWorx LLC