Apache Performance Tuning: Configuring MPM Directives

 

Our previous article in this series focused on defining and fitting MPM to match your environment.  Building off of our last tutorial we will be discussing specific details on how to adjust the previously mentioned Apache configuration directives on the various types of Liquid Web servers.  

 

 

Core-managed CentOS 6/7 Servers

On CentOS servers, Apache configuration files are located in /etc/httpd/.

  1. Log in to the server over SSH or FTP.
  2. First, create an optimization file. It’s necessary for the optimization file to be loaded last so that it will override all other previous settings. We suggest naming the file z-optimize.conf.touch /etc/httpd/conf.d/z-optimize.conf
  3. Open file for editing with your favorite editor:vim /etc/httpd/conf.d/z-optimize.conf
  4. Input necessary directive change, using IfModule statements for compatibility.Configuration example for Centos 6/7 servers.
  5. Save the file.
  6. Reload Apache.service httpd restart

Core-managed Ubuntu 14.04/16.04 LTS Servers

On Ubuntu servers, Apache configuration files are located in /etc/apache2/.

  1. Backup existing apache2.conf file:cp -p /etc/apache2/apache2.conf{,.bak.$(date +%F_%H%M%S)}
    ls -lah /etc/apache2/apache2.conf*
  2. Open file for editing with your favorite editor:vim /etc/apache2/apache2.conf
  3. Append the necessary directive changes to the very bottom of the config file. Configuration examples for Centos 6/7, Ubuntu 14.04/16.04 servers.
  4. Save the file.
  5. Reload Apache.apache2ctl reload

Fully-managed CentOS 6/7 cPanel Servers

Out of the box, our Fully-Managed cPanel servers come with general optimization suitable for most small and mid-range sites. cPanel servers use a sophisticated template system for managing Apache configurations. cPanel typically handles all configurations seamlessly by using the WHM and cPanel interfaces. However, it is still quite simple to set up an optimization configuration file. You have the choice to compose an optimized configuration file via command line over SSH/FTP or within the WHM interface.

Command Line Method (SSH/FTP)

The Apache configuration files on cPanel servers are stored in: /usr/local/apache/conf/includes/

You can use several included files for optimization. It’s necessary for the optimization file to be loaded last so that it will override all other previous settings. For this reason, the post_ include files work best, specifically the post_virtualhost_global.conf file.

 

  1. Log in to the server with SSH or FTP.
  2. Open the post_virtualhost_global.conf file in your favorite editor. (This file is typically empty and maybe missing entirely. This is okay and not unexpected.)vim /usr/local/apache/conf/includes/post_virtualhost_global.conf
  3. Input necessary directive change, using IfModule statements for compatibility. Configuration examples for Centos 6/7, Ubuntu 14.04/16.04 servers.
  4. Save the file.
  5. Reload Apache./scripts/restartsrv_apache
  6. Reload Apache PHP FPM servers./scripts/restartsrv_apache_php_fpm


WMH Method

  1. Log in to Webhost Manager (WHM) on the necessary server.
  2. Type apache in the quick find box.
  3. Click on Apache Configuration in the Service Configuration section.
  4. Click on Include Editor.
  5. Scroll down to Post VirtualHost Include.
  6. Select All Versions from the drop down.
  7. In the box input the necessary directives for optimization. Configuration examples for Centos 6/7, Ubuntu 14.04/16.04 servers.
  8. Click the Update button when finished to save the change.
  9. On the left-hand navigation pane in the Restart Services section at the bottom click on HTTP Server(Apache).
  10. Click on the Yes button.
  11. Back to the left-hand navigation pane in the Restart Services section at the bottom click on PHP-FPM services for Apache.
  12. Click on the Yes button to complete the configuration.

Fully-managed CentOS 7 Plesk Onyx 17 Linux Servers

Out of the box, our Fully-Managed Linux Plesk servers come with general optimization suitable for most small and mid-range sites. Plesk uses mostly a standard CentOS based Apache2 installation so that it can be modified in the same manner as our Core-managed CentOS 6/7 servers:

 

On CentOS servers, Apache configuration files are located in /etc/httpd/.

 

  1. Log in to the server over SSH or FTP.
  2. First, create an optimization file. It’s necessary for the optimization file to be loaded last so that it will override all other previous settings. Suggested name: z-optimize.conf.touch /etc/httpd/conf.d/z-optimize.conf
  3. Open file for editing with your favorite editor:vim /etc/httpd/conf.d/z-optimize.conf
  4. Input necessary directive change, using IfModule statements for compatibility.Configuration examples for Centos 6/7, Ubuntu 14.04/16.04 servers.
  5. Save the file.
  6. Reload Apache.service httpd restart


Our Heroic Support™ team is equipped with talented and knowledgeable techs who can discuss ways to enhance your environment.  After reading through our series if you still have questions our techs can walk you through the outlined steps. For our customer with Fully Managed servers, we are happy to pick up the torch and take the lead by directly implementing the changes in this article.  We are just a phone call, chat or ticket away from aiding you through the process.

Apache Performance Tuning: MPM Directives

How directives behave and which directives are mainly available hinges on the loaded MPM. As discussed in our previous series, MPM is short for MultiProcess Modules, and they determine the basis for how Apache addresses multiprocessing. Using our last article on Apache MPM Modules as a springboard, we will use this section to cover the following subsections:

Each part will focus on how the directives affect performance for their respective MPM and some common considerations that should be assessed when optimizing Apache with those specific MPMs.

Note:
Be sure to review this article in its entirety as the universal directives operate in the same manner regardless of the MPM chosen.

 

General Optimization

IfModule

An important directive to learn when working with Apache servers is the IfModule conditional statement. There are two parts to the IfModule statement. A beginning, which also accepts a module name or module source file name, as well as a closing statement. When the provided module is loaded into Apache, then all directives between the beginning IfModule statement and the closing IfModule statement are also read into the Apache running configuration. Please review the provided example below for further clarification:

 

<ifModule mpm_prefork_module>
MaxSpareServers 16
</ifModule>
Timeout 60
The above example defines the MaxSpareServers directive only when loaded by mpm_prefork_module. The Timeout directive is applied every time due to it being outside of the IfModule closing statement.

 

IfModule statements are used to maintain compatibility within Apache configuration between module changes. Maintaining compatibility is done by grouping directives into IfModule statements, so they are only used when the required module is loaded. Ensuring a syntactically correct configuration file even when swapping modules.

Rule of Thumb:
Appropriately wrapping everything in an IfModule statement is a best practice standard with Apache and should be adhered to for superior compatibility in config files.

Timeout

The numerical value of seconds Apache waits for all common I/O events. Apache will abandon requests fail to complete before the provided Timeout value.

Determining the right Timeout depends on both traffic habits and hosted applications. Ideally, Timeout should be as low as possible while still allowing the vast majority of regular traffic to operate without issue. Large timeouts, those above 1 minute, open the server to SlowLoris style DOS attacks and foster a long wait in the browser when it encounters a problem. Lower timeouts allow Apache to recover from errant stuck connections quickly. It becomes necessary to strike a balance between the two extremes.

Tip:
Avoid increasing the global Timeout when addressing issues with a single script, or user, that requires a long Timeout. Problems can usually be resolved by a .htaccess file or include file to increase the Timeout directive for that specific script.

KeepAlive

KeepAliveA simple on|off toggle enables the KeepAlive protocols with supported browsers. The KeepAlive feature can provide as much as a 50% reductions in latency, significantly boosting the performance of Apache. KeepAlive accomplishes this by reusing the same initial connections a browser creates when connecting to Apache for all follow-up requests which occur within a short period.

KeepAlive is a powerful feature and in general, should be enabled in most situations. It works great for reducing some of the CPU and Network overhead with modern element heavy websites. For example, an easy way to visualize KeepAlive is with the “hold the door” phrase. Imagine a queue of people entering a building through a single doorway. Each person is required to open the door, walk through it, then close the door before the next person does the same process. Mostly, that’s how Apache works without KeepAlive. When enabled, the door stays open until all the people in line are through the door before it closes again.

Two additional related directives also govern KeepAlive. MaxKeepAliveRequests and KeepAliveTimeout. Discussed in the next section, each one plays a vital role in fine-tuning of the KeepAlive directive.

 

MaxKeepAliveRequests

Sets a limit on the number of requests an individual KeepAlive connection is permitted to handle. Once reached, Apache forces the connection to terminate, and creates a new one for any additional requests.

Determining an ideal setting here is open to interpretation. Generally, you want this value to be at least as high as the largest count of elements (HTML, Text, CSS, Images, Etc..) served by the most heavily trafficked pages on the server.

Rule-of-Thumb:
MaxKeepAliveRequestsSet MaxKeepAliveRequests to double that of the largest count of elements on common pages. (Services like webpagetest.org or gtmetrix.com can count elements on a page).

KeepAliveTimeout

This directive is measured in seconds and will remain idle waiting for additional requests from its initiator. Since these types of connections are only accessible to their initiator, we want to keep KeepAliveTimeout very low. A low value prevents too many KeepAlive connections from locking out new visitors due to connection priority.

Tip:
KeepAliveTimoutA large MaxKeepAliveRequests directive with a very low KeepAliveTimeout allows active visitors to reuse connections while also quickly recovering threads from idle visitors.
Configuration: Set MaxKeepAliveRequests to 500+, Set KeepAliveTimeout to 2
Requirements: Works best on MPM Event.

MPM Event/Worker Optimization

This section details the use and performance considerations that are essential when running Worker based MPMs, including both MPM Event and MPM Worker. These MPMs are considered multi-threaded solutions and some directives behave differently based on the loaded MPM. The information provided in this section is only a portion about Worker based MPMs.

Note:
In Worker based MPMs: ServerLimit, ThreadsPerChild, and MaxRequestWorkers are intrinsically linked with each other. It is essential to understand the role of each one and how changing one affects the others. The following directives govern the fine-tuning of the thread handling capabilities of Apache web servers.
MPM Worker and MPM Event

The two modules, MPM Event, and MPM Worker for most intents and purposes operate identically. The difference is apparent in the way each handles KeepAlive requests. The MPM Worker locks threads for the duration of the KeepAlive process and directly affects the number of available threads able to handle new requests. The MPM Event uses a Listener thread for each child. These Listener threads handle standard requests, and KeepAlive requests alike meaning thread locking will not reduce the capacity of the server. Without thread locking, MPM Event is the superior choice but only in Apache 2.4. Before Apache 2.4 the MPM Event was unstable and prone to problems.

ServerLimit

ServerLimit represents the upper limit of children Apache is allowed. The practical usage for ServerLimit is creating a hard ceiling in Apache to protect against input errors with MaxRequestWorkers. The cap prevents spawning vastly more children than a system can handle, resulting in downtime, revenue loss, reputation loss or even data loss.ServerLimit

ServerLimit ties in directly with the thrashing point discussed earlier in this article. The thrashing point is the maximum number of children Apache can run before memory usage tips the scale into perpetual swap. Match the ServerLimit to the calculated thrashing point to safeguard the server.

 

ThreadsPerChild

Used to define the limit of threads that each Apache child can manage. Every thread running can handle a single request. The default of 25 works well for most cases and is a fair balance between children and threads.ThreadsPerChild

There is an upper limit on this directive as well, and the limit is controlled by the ThreadLimit directive, which defaults to 64 threads. The adjustments to increase ThreadsPerChild past 64 threads also need to be made to ThreadLimit.

Increasing this value allows each child to handle more requests keeping memory consumption down while allowing a larger MaxRequestWorkers directive. A key benefit of running more threads within each child is shared memory cache access. Threads from one child cannot access caches from another child. Boosting the number of threads per child squeezes out more performance due to this sharing of cache data. The major downside for increased threads per child occurs during child recycling. The capacity of the server is diminished by the number of threads configured for each child when that child process is eventually recycled (graceful restart).

MPM Event/Worker

Inversely the opposite reaction is achieved by lowering ThreadsPerChild. Fewer threads per child require more children to run an equal amount of MaxRequestWorkers. Since children are full copies of Apache, this increases Apache’s overall memory footprint but reduces the impact when recycling children. Fewer threads mean fewer potential “stuck” threads during the recycle procedure, keeping the higher capacity of requests available overall children. Having fewer threads per child provides increased shared memory isolation. For instance, dropping ThreadsPerChild to 1 gives the same request isolation of MPM Prefork but also inherits its massive performance tax as well, requiring one child per one request.

Tip:
When setting ThreadsPerChild always consider the server environment and hardware.

  • A memory-heavy shared server hosting numerous independent accounts might opt for a lower ThreadsPerChild, reducing the potential impact of one user affecting another.
  • A dedicated Apache server in a high capacity load balanced configuration can choose to increase ThreadsPerChild significantly for a better overall performance of each thread.

ThreadLimit

Used to set the maximum value of ThreadsPerChild. This directive is a hard ceiling for ThreadsPerChild. It helps protect against typographical errors with the ThreadLimit
ThreadsPerChild directive which could quickly spin a server out of control if too many threads are allowed due to an input error. This setting need to be adjusted in some high-end servers when the system needs more than the default of 64 threads per child.

MaxRequestWorkers / MaxClients

The directive sets the limit for active worker threads across all running children and acts as a soft ceiling with ServerLimit taking control as the hard limit. When the number of total running threads has reached or exceeded MaxRequestWorkers, Apache no longer spawns new children.MaxRequestWorkers/MaxClients

Determining the MaxRequestWorkers is a critical part of server optimization. An optimal setting is based on several changing variables. This means its configuration needs to be reevaluated and tailored periodically over time, changed by watching traffic habits and system resource usage. The Apache status Scoreboard is an effective tool for analysis of Apache performance.

 

It is typical of Worker based MPM systems to run an isolated third-party PHP handler like Mod_fcgid, PHP-FPM, and mod_lsapi. These modules are responsibleMPM Event/Worker2

for processing PHP code outside of Apache and frees up Apache to handle all other non-PHP requests such as HTML, TEXT, CSS, Images, etc… These requests are far less taxing on server resources which allows Apache to handle larger volumes of requests, such as those beyond 400 MaxRequestWorkers.

MinSpareThreads

The least number of Threads that should remain open, waiting for new requests. MinSpareThreads is a multiple of ThreadsPerChild and cannot exceed MaxSpareThreads, though it can match it.

Rule-of-Thumb:
Set MinSpareThreads to equal 50% of MaxRequestWorkers.

Spare threads are idle workers threads. These threads are merely waiting for new incoming requests and are governed by the Apache child process that spawned them. If there are less available threads than MinSpareThreads, The Apache parent will generate a new child with another ThreadsPerChild worth of threads.

MinSpareThreads

MaxSpareThreads

This directive governs the total number of idle threads allowed on the server across all children. Any threads above this limit direct their parent to shut down to reduce memory consumption during off-peak hours.MaxSpareThreads

Having a limit to the number of idle open threads is excellent for smaller servers with hardware constraints. However, it mostly unneeded on today’s modernizing hardware.

Tip:
Configuring Apache as an open throttle is a high-performance configuration for servers with significant RAM and multiple CPU cores. When running the open throttle configuration, all available threads become available at all time. Apache’s memory usage will stay near its peak at all times, a side effect due to running all the configured children into memory preemptively. This configuration will produce the best possible response times from Apache by maintaining persistent open connections ready to do work and removing the overhead of spawning new processes in response to traffic surges.

Configuration: Match both MinSpareThreads and MaxSpareThreads to MaxRequestWorkers.

Requirements: Make sure there is enough server RAM to run all MaxRequestWorkers at once.

StartServers

This directive governs the initial amount of children the Apache Parent process spawns when the Apache service is started or restarted. This is commonly left unchanged since Apache continuously checks the current running children in conjunction with ThreadsPerChild and compare it to MinSpareThreads to determine if more children get forked. This process is repeated perpetually, with a doubling of new children on each iteration, until MinSpareThreads is satisfied.

Rule-of-Thumb:
StartServerManually calculating StartServers is done by dividing MaxRequestWorkers by ThreadsPerChild, rounding down to the nearest whole number. This process forces all children to be created without delay at startup and begins handling requests immediately. This aspect is especially useful in modern Apache servers which require periodic restarts to load in directive changes.

MaxConnectionsPerChild / MaxRequestsPerChild

The number of requests a single Apache child process can handle equals a cumulative total on the child server across all threads it controls. Each request handled by a thread counts toward this limit to its parent. Once the child server has reached its limit, the child is then recycled.
This directive is a stop-gap for accidental memory leaks. Some code executed through Apache threads may contain memory leaks. Leaked memory are portions of memory that subprocess failed to release properly, so they are inaccessible to any outside processes. The longer a leaking program is left running, the more memory it will leak. Setting a MaxConnectionsPerChild limit is a specific method for assuring Apache is periodically recycling programs to reduce the impact of leaked memory on the system. When using external code handlers like Mod_fcgid, PHP-FPM or mod_lsapi, it becomes necessary to set MaxConnectionsPerChild to 0 (unlimited), doing so prevents periodic error pages caused by Apache terminating threads prematurely.

Rule-of-Thumb:
MaxConnectionsPerChild/MaxRequestsPerChild If the server encounters a memory leak never set the MaxConnectionsPerChild / MaxRequestsPerChild too low, instead start with 10,000 and reduce it incrementally.

 

MPM Prefork Optimization

This MPM Prefork section details the use and performance considerations for various directives when running this module. This MPM is a non-threaded multi-processor designed for compatibility. It consists of a single Apache parent process, which is used to govern all new Apache processes also known as children. The following directives show how Apache is capable of performance tuning when using MPM Prefork. Unlike Worker based MPMs, optimizing MPM Prefork is generally simple and straightforward. There is a 1:1 ratio of Apache processes to incoming requests. However, MPM Prefork does not scale well with hardware and the more traffic it encounters, the more hardware it will need to keep up with the pace. It should be noted that some directives behave differently based on which MPM is loaded. The information provided in this section is only the portion about MPM Prefork.

MaxRequestWorkers / MaxClients

Used to control the upper limit of children that the Apache parent server is allowed to have in memory at one time. These children (also called workers) handle requests on a 1:1 ratio. This translates into the maximum number of simultaneous requests the server can handle.

MaxRequestWorkers / MaxClientsIf this directive is too low, Apache under-utilizes the available hardware which translates to wasted money and long delays in page load times during peak hours. Alternatively, if this directive is too high, Apache outpaces the underlying hardware sending the system into thrashing (link to thrashing article) scenario which can lead to server crashes and potential data loss.

 

MinSpareServers

This directive defines a minimum number of spare children the Apache parent process can maintain in its memory. An additional server is a preforked idle Apache child that is ready to respond to a new incoming request. Having idle children waiting for new requests is essential for providing the fastest server response times. When the total idle children on the server drop below this value, a new child is preforked at the rate of one per second until this directive is satisfied. The “one per second” rule is in place to prevent surges of the creation process that overload the server, however, this failsafe comes at a cost. The one per second spawn rate is particularly slow when it comes to handling page requests. So it’s highly beneficial to make sure enough children are preforked and ready to handle incoming requests.

 

Rule of Thumb:
MinSpareServers Default settingNever set this to zero. Setting this to 25% of MaxRequestWorkers ensures plenty resources are ready and waiting for requests.

MaxSpareServers

MasSpareServers controls the maximum number of idle Apache child servers running at one time. An idle child is one which is not currently handling a request but waiting for a new request. When there are more than MaxSpareServers idle children, Apache kills off the excess.

If the MaxSpareServers value is less than MinSpareServers, Apache will automatically adjust MaxSpareServers to equal MinSpareServers plus one.

Like with MinSpareServers, this value should always be altered with available server resources in mind.

Rule of Thumb:
MaxSpareServersSet this to double the value of MinSpareServers.
Tip:
Configuring Apache as an open throttle is a high-performance configuration for servers with significant RAM and multiple CPU cores. When running the open throttle configuration, all available Apache children become available at all times. As a side effect of running open throttle, the Apache memory usage will stay near its peak at all times, due to running all the configured children into memory preemptively. This configuration will produce the best possible response times by maintaining persistent open connections. Furthermore, in response to traffic surges, it removes the overhead that comes from spawning new processes.
Configuration: Match both MinSpareServers and MaxSpareServers to MaxRequestWorkers.
Requirements: Make sure there is enough server RAM to run all MaxRequestWorkers at once.

StartServers

Created at startup, are the initial amount of Apache child servers.

This seldom changed directive only impacts Apache startup and restart processes. Generally not altered because Apache uses internal logic to work out how many child servers should be running.

Many modern servers periodically restart Apache to address configuration changes, rotate log files or other internal processes. When this occurs during a high load traffic surge, every bit of downtime matters. You can manually set the StartServers directive to mirror that of your MinSpareServers to shave off time from the Apache startup.

Rule of Thumb:
StartServersThe StartServers directive should mirror that of MinSpareServers.

 

ServerLimit

The ServerLimit directive represents the upper limit of MaxRequestWorkers. This setting is generally used as a safeguard or ceiling against input errors when modifying MaxRequestWorkers.ServerLimit Default Setting

It becomes necessary to adjusted ServerLimit when the server is expected to handle more than the default of 256 requests simultaneously.

ServerLimit ties in directly with the thrashing point. The thrashing point is the maximum number of children Apache can run before memory usage tips the scale into perpetual swap. Match the ServerLimit to the calculated thrashing point to safeguard the server.

Note:
Increasing ServerLimit is not recommended with MPM Prefork. Running more than 256 simultaneous requests is hardware intensive when using the MPM Prefork module.

ThreadsPerChild Default Settings

MaxConnectionsPerChild / MaxRequestsPerChild

This directive equals the number of requests a single Apache child server can handle.

This directive is a stop-gap for accidental memory leaks. Code executed through Apache may contain faults which leak memory. These leaks add up over time making less and less of the shared memory pool of the child usable. The way to recover from leaked memory is to recycle the affected Apache child process. Setting a MaxConnectionsPerChild limit will protect from this type of memory leakage.

Note:
MaxConnectionsPerChild/MaxRequestsPerChild Rule-of-Thumb: Never set this too low. If the server encounters memory leak issues start with 10,000 and reduce incrementally.

 

Apache Performance Tuning: MPM Modules

The keystone for understanding Apache server performance is by far the MultiProcessing Modules (MPMs). These modules determine the basis for how Apache addresses multiprocessing. Multiprocessing means running multiple operations simultaneously in a system with multiple central processing units (CPU Cores).

There are many MPMs to choose; however, this article focuses on the most commonly used modules found in Liquid Web Linux based servers. These modules are:

The self-regulating MPM Prefork derives its namesake from how it forks or copies itself into new identical processes preemptively to wait for incoming requests. A non-threaded process-based approach at multiprocessing, MPM Prefork runs Apache in a single master parent server process. This parent is responsible for managing any additional child servers that make up its serverpool. While using MPM Prefork, each child server handles only a single request. This focus provides complete isolation from other requests dealt with on the server. MPM Prefork is typically used for compatibility when non-threaded libraries/software, like mod_php (DSO), are required. From an optimization standpoint, MPM Prefork can be sorely lacking when compared to multi-threaded solutions, requiring vastly more resources to reach similar traffic levels as a threaded MPM. It is resource intensive due to its need to spawn full copies of Apache for every request.

MPM Prefork

Rule-of-Thumb:
Avoid using MPM Prefork whenever possible. It’s inability to scale well with increased traffic will quickly outpace the available hardware on most system configurations.

 

A hybrid pre-forking, multithreaded, multiprocessing web server. In the same fashion as MPM Prefork, MPM Worker uses the same approach with a single master parent process governing all children within its serverpool. However, unlike MPM Prefork, these children are multi-threaded processes that can handle dozens of threads (requests) simultaneously. MPM Worker has set the foundation for multithreaded multiprocessing in Apache servers which became stable in Apache 2.2. The threaded configuration allows Apache to service hundreds of requests with ease while retaining only a dozen or so child processes in memory. The MPM Worker make for both a high capacity and low resource solution for web service.

MPM Worker

Note
The KeepAliveTimeOut directive currently defines the amount of time Apache will wait for requests. When utilizing KeepAlive with MPM Worker use the smallest KeepAliveTimeout as possible (1 second preferably).

Based off the MPM Worker source code, MPM Event shares configuration directives with MPM Worker. It works nearly identical to MPM Worker except when it comes to handling KeepAlive requests. MPM Event uses a dedicated Listener thread in each child process. This Listening thread is responsible for directing incoming requests to an available worker thread. The Listening thread solves the issue encountered by MPM Worker which locks entire threads into waiting for the KeepAliveTimeout. The Listener approach of MPM Event ensures worker threads are not “stuck” waiting for KeepAliveTimeout to expire. This method keeps the maximum amount of worker threads handling as many requests as possible.


MPM EventMP

Tip:
MPM Event is stable in Apache 2.4, older versions can use MPM Worker as an alternative.

There is an assortment of additional MPMs available. These are typically part of Apache’s integration into Operating Systems other than Unix based systems. These have specific MPMs which are requirements or utilizing Apache on their respective system types. These types of MPMs are beyond the purview of this article. You can find more information on specific MPM in the MPM Defaults section of the official Apache Documentation.

MPM EventMP

Tip:
We recommend staying away from experimental and unstable MPMs. The unreliable nature of these types of software renders them unsupportable.

 

When considering optimization, it is essential to understand there is no such thing as a one-size-fits-all Apache configuration. Correctly choosing an MPM requires analysis of many moving variables like traffic, site code, server type, PHP Handler and available hardware. Every server is unique making the best MPM an entirely subjective choice.

If your application code does not support multi-threading, then your choice will inevitably be MPM Prefork purely on a compatibility basis. MPM Prefork includes software modules like mod_php (DSO). MPM Worker without KeepAlive performs very well if your application is a high-performance load balanced API system. The scalability and flexibility of MPM Event is a solid choice for hosting multiple small to medium sites in a shared hosting configuration.

Most simple servers setups operate well under the self-governing default configuration of MPM Event, making it an ideal starting point for optimization tuning. Once chosen, an MPM can then move onto Configuration Directives to review which settings pertain to server performance and optimization. Or check out our previous article in this series, Apache Performance Tuning: Swap Memory.

Apache Performance Tuning: Swap Memory

Before we get into the nitty-gritty of Apache tuning, we need to understand what happens when servers go unresponsive due to a poorly optimized configuration. An over-tuned server is one that is configured to allow more simultaneous requests (ServerLimit) than the server’s hardware can manage. Servers set in this manner have a tipping point, once reached, the server will become stuck in a perpetual swapping scenario. Meaning the Kernel is stuck rapidly reading and writing data to and from the system swap file. Swap files have read/write access speeds vastly slower than standard memory space. The swap files’ latency causes a bottleneck on the server as the Kernel attempts to read and write data faster than is physically possible or more commonly known as thrashing. If not caught immediately, thrashing spirals the system out of control leading to a system crash. If trashing is left running for too long, it has the potential of physically harming the hard drive itself by simulating decades of read/write activity over a short period. When optimizing Apache, we must be cautious not to create a thrashing scenario. We can accomplish this by calculating the thrashing point of the server based on several factors.

 

Pre-Flight Check

This article covers all Apache-based servers including but is not limited to, both traditional Dedicated servers and Cloud VPS servers running a variety of Linux distributions. We will include the primary locations where stored Apache configurations on the following Liquid Web system types:

Liquid Web Server Types

Calculating the estimated thrashing point or ServerLimit of a server uses a simple equation:

Caculating the Thrashing Point

  • buff/cache: The total memory used by the Kernel for buffers and cache.
  • Reserved: The amount of memory reserved for non-Apache processes.
  • Available: The difference between buff/cache and Reserved memory.
  • Avg.Apache: The average of all running Apache children during peak operational hours.

 

Important
Calculating the thrashing point/ServerLimit should be done during peak operational hours and periodically reassessed for optimal performance.

The thrashing point value is equal to the number Apache children the server can run; this applies to either threaded or non-thread children. When the number of children running in memory meets the calculated thrashing point, the server will begin to topple. The following example walks through a standard Liquid Web Fully Managed cPanel server to illustrate gathering the necessary details to calculate a system’s estimated thrashing point.

 

Buff/Cache Memory

On modern Linux systems, the buffer/cache can be derived using the /proc/meminfo file by adding the Buffers, Cached and Slab statistics. Using the free command, we can quickly grab this information, as in the example below:

free

Output:

Use the free command to get the buff/cache info

Don’t be fooled by the column labeled “available.” We are solely looking at the memory we can reappropriate, which is the buff/cache column (708436).

 

Reserved Memory

Reserved memory is a portion of memory held for other services aside from Apache. Some of the biggest contenders for additional memory outside of Apache are MySQL, Tomcat, Memcache, Varnish, and Nginx. It is necessary to examine these services configs to determine a valid reserved memory. These configs are outside the purview of this article. However, MySQL is the most commonly encountered service running with Apache. You can find tools online to help analyze and configure MySQL separate from this article.

 

Rule-of-Thumb:
Save 25% of the total buff/cache memory for any extra services ran on the server. Examples:

  • A standard cPanel server runs several services along with Apache and MySQL. A server with these services runs on the heavier side, needing 25% reserved for non-Apache services.
  • A pure Apache web node in a high capacity load balanced configuration does not need to reserve any additional ram for other services.

 

Average Apache Memory

Finding the average size of Apache processes is relatively simple using the ps command to list the RSS (Resident Set Size) of all running httpd processes. Note: some distributions use “apache” instead of “httpd” for process name.

This example uses a short awk script to print out the average instead of listing the sizes.

ps o rss= -C httpd|awk '{n+=$1}END{print n/NR}'

Output:

22200.6

 

This example is easy to average by hand, but larger servers will require more calculation.

ps o rss -C httpd

Output:

RSS
5092
27940
28196
27572

 

Calculate the Thrashing Point

Once collected divided the Available memory by Avg. Apache, rounding down to the nearest whole number. Available memory is the buff/cache memory minus the Reserved memory. Below is a summary of the calculation process in table form.

Thrashing point calculations

Conservative estimates are provided below for various memory configurations. These estimates can be used as a starting configuration but will require additional follow up performance assessments during peak hours to adjust directives by the servers.

General Thrashing Estimates

Install Multiple PHP Versions on Ubuntu 16.04

As a default, Ubuntu 16.04 LTS servers assign the PHP 7.0 version. Though PHP 5.6 is coming to the end of life in December of 2018, some applications may not be compatible with PHP 7.0. For this tutorial, we instruct on how to switch between PHP 7.0 and PHP 5.6 for Apache and the overall default PHP version for Ubuntu.

Step 1: Update Apt-Get

As always, we update and upgrade our package manager before beginning an installation. If you are currently running PHP 7.X, after updating apt-get, continue to step 2 to downgrade to PHP 5.6.

apt-get update && apt-get upgrade

Step 2: Install PHP 5.6
Install the PHP5.6 repository with these two commands.

apt-get install -y software-properties-common
add-apt-repository ppa:ondrej/php
apt-get update
apt-get install -y php5.6

Step 3: Switch PHP 7.0 to PHP 5.6
Switch from PHP 7.0 to PHP 5.6 while restarting Apache to recognize the change:

a2dismod php7.0 ; a2enmod php5.6 ; service apache2 restart

Note
Optionally you can switch back to PHP 7.0 with the following command: a2dismod php5.6 ; a2enmod php7.0 ; service apache2 restart

Verify that PHP 5.6 is running on Apache by putting up a PHP info page. To do so, use the code below in a file named as infopage.php and upload it to the /var/www/html directory.

<? phpinfo(); ?>

By visiting http://xxx.xxx.xxx.xxx/infopage.php (replacing the x’s with your server’s IP address), you’ll see a PHP info banner similar to this one, confirming the PHP Version for Apache:

Example of PHP Info page

Continue onto the section PHP Version for Ubuntu to edit the PHP binary from the command line.

Step 4: Edit PHP Binary

Maintenance of symbolic links or the /etc/alternatives path through the update-alternatives command.

update-alternatives --config php

Output:
There are 2 choices for the alternative php (providing /usr/bin/php).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/bin/php7.0 70 auto mode
1 /usr/bin/php5.6 56 manual mode
2 /usr/bin/php7.0 70 manual mode
Press to keep the current choice[*], or type selection number:

Select php5.6 version to be set as default, in this case, its the number one option.

You can now verify that PHP 5.6 is the default by running:
php -v

Output:
PHP 5.6.37-1+ubuntu16.04.1+deb.sury.org+1 (cli)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

Install Nginx on Ubuntu 16.04

Nginx is an open source Linux web server that accelerates content while utilizing low resources. Known for its performance and stability Nginx has many other uses such as load balancing, reverse proxy, mail proxy and HTTP cache. With all these qualities it makes a definite competitor for Apache. To install Nginx follow our straightforward tutorial.

Pre-Flight Check

  • Logged into an as root and are working on an Ubuntu 16.04 LTS server powered by Liquid Web! If using a different user with admin privileges use sudo before each command.

Step 1: Update Apt-Get

As always, we update and upgrade our package manager.

apt-get update && apt-get upgrade

Step 2: Install Nginx

One simple command to install Nginx is all that is needed:

apt-get -y install nginx

Step 3: Verify Nginx Installation

When correctly installed Nginx’s default file will appear in /var/www/html as index.nginx-debian.html . If you see the Apache default page rename index.html file. Much like Apache, by default, the port for Nginx is port 80, which means that if you already have your A record set for your server’s hostname you can visit the IP to verify the installation of Nginx. Run the following command to get the IP of your server if you don’t have it at hand.

ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//'

Take the IP given by the previous command and visit via HTTP. (http://xxx.xxx.xxx.xxx) You will be greeted with a similar screen, verifying the installation of Nginx!

Nginx Default Page

Note
Nginx, by default, does not execute PHP scripts and must be configured to do so.

If you already have Apache established to port 80, you may find the Apache default page when visiting your host IP, but you can change this port to make way for Nginx to take over port 80. Change Apache’s port by visiting the Apache port configuration file:

vim /etc/apache2/ports.conf

Change “Listen 80” to any other open port number, for our example we will use port 8090.

Listen 8090

Restart Apache for the changes to be recognized:

service apache2 restart

All things Apache can now be seen using your IP in the replacement of the x’s. For example http://xxx.xxx.xxx.xxx:8090

How to Install Cassandra on Ubuntu 16.04 LTS

Apache Cassandra is a free open-source database system that is NoSQL based. Meaning Cassandra does not use the table model seen in MySQL, MSSQL or PostgreSQL, but instead uses a cluster model. It’s designed to handle large amounts of data and is highly scalable. We will be installing Cassandra and its pre-requisites, Oracle Java, and if necessary the Cassandra drivers.

Pre-Flight Check

  • We are logged in as root on an Ubuntu 16.04 VPS powered by Liquid Web!
  • Apache Cassandra and this article expect that you are using Oracle Java Standard Edition 8, as opposed to OpenJDk . Verify your Java version by typing the command below into your terminal:

java --version

  • At the time of this article, Python 2.7.11 and later versions will need to install updated Cassandra drivers to fix a known bug with the cqlsh command. You can check your Python version similar to checking your Java version:

python --version

  • If you have Python 2.7.11+ or later, download the required driver by running the pip command. You will need pip installed. Within this tutorial, we will show you how to install pip. However, pip is usually pre-installed with Python by default.

Step 1: Install Oracle Java (JRE)

Cassandra requires your using Oracle Java SE (JRE) installed on your server. First, you will have to add Personal Package Archives to make the (JRE) package available.

sudo add-apt-repository ppa:webupd8team/java

After entering this command, it may prompt you to hit enter to continue.
Once it completes update the package database using the following:

sudo apt-get update

You can now install Oracle JRE with the following:
sudo apt-get install oracle-java8-set-default

A pink screen prompts you to agree to the terms and conditions of JRE. Hit enter to continue from this screen and accept the terms and conditions in the next screen.

Java Installer Screen

 

Once successfully installed verify the default version of Java by typing:

java -version

You’ll receive the following or something very similar :

Java Version Output

 

Step 2: Installing Apache Cassandra

First, we have to install the Cassandra repository to /etc/apt/sources.list.d/cassandra.sources.list directory by running following command (When we made this article Cassandra 3.6 was the current version. You may need to edit this line to reflect the latest release by updating the 36x value. For example, use 37x if Cassandra 3.7 is the newest version.):
echo "deb http://www.apache.org/dist/cassandra/debian 36x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list

Next, run the cURL command to add the repository keys :

curl https://www.apache.org/dist/cassandra/KEYS | sudo apt-key add -

We can now update the repositories:

sudo apt-get update

 

Note
If you get the following error: GPG error: http://www.apache.org 36x InRelease: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY A278B781FE4B2BDA
Add the public key by running the following command:
sudo apt-key adv --keyserver pool.sks-keyservers.net --recv-key A278B781FE4B2BDARepeat the update to the repositories:
sudo apt-get update

Finally, finish installing by entering the following:
sudo apt-get install cassandra

Verify the installation of Cassandra by running:
nodetool status

The desired output will show UN meaning everything is up and running normally.

Verifying Cassandra is Installed

 

Step 3: Connect with cqlsh

If you have an older version of Python before 2.7.11, you’ll skip this step and start using Cassandra with the cqlsh command. Good for you! You have successfully installed Cassandra!
cqlsh

You should see something similar to this:
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.6 | CQL spec 3.4.2 | Native protocol v4] Use HELP for help.

Note
For future reference, Cassandra’s configuration file, data directory and logs can be found in:

  • /etc/cassandra is the default file configuration location.
  • /var/log cassandra and /var/lib cassandra are the default log and data directories location.

However, if you get the following error,

Connection error: (‘Unable to connect to any servers’, {‘127.0.0.1’: TypeError(‘ref() does not take keyword arguments’,)}),

you’ll update the Cassandra drivers. These drivers have a known bug with Cassandra and later versions of Python. Check your Python version by typing:
python --version

Luckily, I am going to show you how you can fix this error in 3 easy steps by downloading the drivers.

 

Step 3a: First we will need pip installed. If you don’t have it already, you can get it with the following command.

sudo apt-get install python-pip

 

Step 3b: Once pip is installed, run the following to install the new Cassandra driver. Please note this command may take a while to execute. Grab a snack and wait for it to complete. It can take 5-10 minutes to install fully.

pip install cassandra-driver

 

Step 3c: Finally disable the embedded driver by entering :

export CQLSH_NO_BUNDLED=true

You should now be able to run the cqlsh command.

cqlsh

You should see this if successful :

Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.6 | CQL spec 3.4.2 | Native protocol v4] Use HELP for help.

To exit cqlsh type exit:
cqlsh> exit

Congrats! You have successfully installed Cassandra!

Note

Cassandra should start automatically, but you’ll want to stop Cassandra to make any additional configuration changes. Start and stop it with the following:

sudo service cassandra start
sudo service cassandra stop

Whitelisting in ModSecurity

Broken down into two parts our article’s first section hits on “how to whitelist IPs or URIs,” for people who are somewhat familiar with ModSecurity but want to know further about the process. Our second section examines why we configure ModSecurity and how to prevent the security of the server from getting in the way of our work. If you have a Fully Managed Liquid Web server reach out to our Heroic Support team for assistance with whitelisting!

How to Whitelist IPs or URIs

“ModSecurity is a toolkit for real-time web application monitoring, logging, and access control.” (modsecurity.org).  In simple terms, this means that ModSec, also called mod_security or ModSecurity, is a web application firewall that can actively look for attacks to the system and stop malicious activity. However, sometimes these rules trigger when legitimate work is taking place, blocking your IP and stopping you or your developer’s until you can remove the IP block. The way around for being blocked is known as whitelisting, which essentially allows for a specific IP to access the server.   There are a few ways to whitelist a request in ModSec, either by IP or by URI (URIs are specific pages on the website). 

Getting Started

  1. Find your IP or ask your developer for theirs. (You can find this by going to ip.liquidweb.com)If you or your developer have a static IP (one that will not change), one way you can whitelist the ModSec rules is by IP.
  2. Find the ModSec error in the Apache error logs with the following command (Be sure to modify the command with your IP in place of “IP here.”):
    grep ModSec /usr/local/apache/logs/error_log | grep “IP here”.
  3. The output of this command will give you a list of hits for ModSecurity from you or your developer’s IP, which you can see below. While this looks intimidating, you will only want to pay attention to 3 bits of information highlighted.  Please note, the output will not show these colors when you are viewing the files.
Note
Blue = client, the IP which tripped the rule
Red
= ID number of tripped rule within ModSec
Green = URI, the location where the error started from

[Fri May 25 23:07:04.178701 2018] [:error] [pid 78007:tid 139708457686784] [client 61.14.210.4:30095] [client 61.14.210.4] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "20000221"] [hostname "67.227.209.163"] [uri "/db/index.php"] [unique_id "WwjPWChxvG1CO4kz-D55eQAAACU"]

 

Whitelist By IP:

1. Once you have the correct ModSec error, you will need to edit the ModSec configuration. If you are using Easy Apache 4 you will find the configuration file with this path:
/etc/apache2/conf.d/modsec2/whitelist.conf

2. Open the file with your favorite text editor, such as vim, nano, or file manager like so:

vim /etc/apache2/conf.d/whitelist.conf

3.  The blue text above will be the IP address that you are whitelisting from the original error. You must keep the backslashes (\) and up-carrot (^) in order for the IP to be read correctly. Thus it will always look something like:

“^192\.168\.896\.321”

For for the id, noted in red, you will change the number after the colon, which will be the Apache error log like we saw above. This will look similar to:

Id:2000221

Add the following code with the colored sections edited to match your intended IP.

SecRule REMOTE_ADDR "^64\.14\.210\.4"
"phase:1,nolog,allow,ctl:ruleEngine=off,id:20000221"

 

Whitelist By URI:

If your IP is dynamic (changing) and you keep getting blocked in the firewall, it is best to whitelist it via URI, the yellow item in the ModSec error.

1. Begin by opening the Easy Apache 4 configuration file:

vim /etc/apache2/conf.d/whitelist.conf

2. Add the following text to the configuration. Remember to pay attention to the highlighted parts.  Change the yellow “/db/index.php” to match your URI and the red id to match the id of your error (Do not use the colon in this one).

<LocationMatch "/db/index.php">
SecRuleRemoveById 20000221
</LocationMatch>

3. The final step for whitelisting, before you finalize the process, is to ensure you have correctly set up the whitelist. For Easy Apache 4 you will run the command:
apachectl -t

As long as the command returns “Syntax Ok” you are safe to make the whitelist active by restarting Apache. Otherwise, review the whitelists to make sure the syntax matches up correctly with the above directions.

4. Lastly, restart Apache with the following command.

/scripts/restartsrv_httpd

You have successfully whitelisted yourself in ModSec!

 

Using ModSec

Cyber Security is a hydra; once one threat is cut off, two more grow back. While this is not a new analogy, it’s important to understand as we battle threats to our network, computers, and servers. With all the complexities that come with security, I want to talk about adequately configuring ModSec to deter threats while still allowing you to work on your websites. Often, when it comes to server security, too much protection can hinder effectiveness.

For example, say you have the following set up on your server:

  • You do not allow root SSH login to the server
  • utilize dual-factor authentication for any SSH logins
  • use an SSH key for the sudo user and require other security safeguards

While this type of configuration is secure, it takes longer to log into your system to make a quick edit to your settings, a double-edged sword; how can you keep the server safe while not tying your own hands?  A great example of how this plays out is using ModSec.

ModSec can block your IP if it falsely flags your work. While this module improves system security, you’ll need to be aware of properly implementing and “scoping” the technology. Scoping in this sense means to manage risks, the focus of what is important for security while still allowing work on the server with minimal interference. To tune out legitimate requests to your server, such as when you are editing your website’s code via a plugin, ModSec has the options to whitelist rules or IPs and keep your work on track.

Whitelisting an IP from the rules that ModSec follows is a great option so long as the IP never changes (i.e. a static IP, see article here to learn more https://support.google.com/fiber/answer/3547208?hl=en) and is limited to only people you trust. This method prevents ModSec from viewing your requests as malicious and blocking your IP. This practice has the drawback that if someone (say an unhappy employee) has access to your network, they now have a way around ModSec to attack your server.

With non-static (dynamic) IPs the problems of whitelisting an IP are readily apparent. With the continual change of a dynamic IP, it creates the potential of exploiting your server, as someone could use an old IP to access the server. Whitelisting specific rules comes to save the day! When you whitelist by rules, you can edit with granularity and limit the rules to particular domains and URIs, protecting the rest of the server from attacks related to that same rule!

Example of ModSecurity

ModSec reads a series of rules and applies them to incoming requests being made to the web server. An example of what a block looks like is:

[Sat Jun 30 02:21:56.013837 2018] [:error] [pid 79577:tid 139862413879040] [client 120.27.217.223:24397] [client 120.27.217.223] ModSecurity: Access denied with code 406 (phase 2). Pattern match "Mozilla/(4|5)\\\\.0$" at REQUEST_HEADERS:User-Agent. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "109"] [id "2000064"] [hostname "67.227.192.139"] [uri "/mysql/index.php"] [unique_id "WzchhAjuZ6wPAzo9AwW1WwAAAE8"]

This error shows Apache stopped a potential attack on a file at /mysql/index.php. This is an error similar to what appears when the code is being written or edited within programs like Drupal or WordPress.

Evaluating ModSecurity

If you are persistently being blocked in your firewall while working on your code, ModSec is the likely culprit. The ModSec errors can be found in the Apache error log (in cPanel the path is /usr/local/apache/logs/error_log). The phrase “ModSec” can be quickly isolated from the log (via the command ‘grep “ModSec” /usr/local/apache/logs/error_log’). By comparing you or your developer(s) IP to the log, you’ll be able to identify stopped requests that are legitimate. Verify these are valid requests by double-checking that someone in your organization made them. Once you have done so, you can move forward in setting up a whitelist for the error, per the steps above.

Again, we want to scope to allow the least amount of wiggle room for an attack and ensure we can keep working. If you are unable to have a trusted static IP, you’ll need to use the whitelist URI  method, providing the specific page as an exemption. Once completed, remove both whitelisted items from the configuration file, in case of a genuine attack.

On a parting note, I encourage you to explore ModSec and learn more of the ins and outs of the software. Exploring different methods of whitelisting can be a lot of for to learn and most importantly helps to tighten server security. As always, our Fully Supported Customers can contact our Helpful Human Support team for assistance. Check out articles on security in our Knowledge Base, like this one on Maldet! It’s another excellent way to learn about your server and develop an understanding of server security.

How To Install Apache Tomcat 8 on Ubuntu 16.04

Apache Tomcat is used to deploy and serve JavaServer Pages and Java servlets. It is an open source technology based off Apache.

Pre-Flight Check

  • This document assumes you are installing Apache Tomcat on Ubuntu 16.04.
  • Be sure you are logged in as root user.

Installing Apache Tomcat 8

Step 1: Create the Tomcat Folder

Logged in as root, within the opt folder make a directory called tomcat and cd into that folder after completion.

mkdir /opt/tomcat

cd /opt/tomcat

 

Step 2: Install Tomcat Through Wget

Click this link to the Apache Tomcat 8 Download site. Place you cursor under 8.5.32  Binary Distributions, right click on the tar file and select copy link address (as shown in the picture below). At the time of this article Tomcat 8 is the newest version but feel free to pick whatever version is more up-to-date.

Tomcat 8's Download Page

Next from your server, use wget command to download the tar to  the tomcat folder from the URL you copied in the previous step:

wget http://apache.spinellicreations.com/tomcat/tomcat-8/v8.5.32/bin/apache-tomcat-8.5.32.tar.gz

Note
You can down the file to your local desktop, but you’ll then want to transfer the file to your Liquid Web server. If assistance is needed, check out this article: Using SFTP and SCP Instead of FTP

After the download completes, decompress the file in your tomcat folder:

tar xvzf apache-tomcat-8.5.32.tar.gz

 

Step 3: Install Java

Before you can use Tomcat you’ll have to install the Java Development Kit (JDK). Beforehand, check to see if Java is installed:

java -version

If that command returns the following message then Java has yet to be installed:
The program 'java' can be found in the following packages:

To install Java, simply run the following command (and at the prompt enter Y to continue):
apt-get install default-jdk

 

Step 4: Configure .bashrc file

Set the environment variables in .bashrc with the following command:

vim ~/.bashrc

Add this information to the end of the file:
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64
export CATALINA_HOME=/opt/tomcat/apache-tomcat-8.5.32

Note
Verify your file paths! If you downloaded a different version or already installed Java, you may have to edit the file path or name. Older versions of Java may say java-7-openjdk-amd64 instead of java-1.8.0-openjdk-amd64 . Likewise, if you installed Tomcat in a different folder other then /opt/tomcat (as suggested) you’ll indicate the path in your bash file and edit the lines above.

Save your edits and exit from the .bashrc file, then run the following command to register the changes:

. ~/.bashrc

 

Step 5: Test Run

Tomcat and Java should now be installed and configured on your server. To activate Tomcat, run the following script:

$CATALINA_HOME/bin/startup.sh

You should get a result similar to:

Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JRE_HOME: /usr/lib/jvm/java-7-openjdk-amd64/
Using CLASSPATH: /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar
Tomcat started

 

To verify that Tomcat is working visit the ip address of you server:8080 in a web browser. For example http://127.0.0.1:8080.

Apache Tomcat 8 Verification Page

 

How To Install Apache Tomcat 7 on Ubuntu 16.04

Apache Tomcat is used to deploy and serve JavaServer Pages and Java servlets. It is an open source technology based off Apache.
Pre-Flight Check

  • This document assumes you are installing Apache Tomcat on Ubuntu 16.04.
  • Be sure you are logged in as root user.

Installing Tomcat 7

Step 1: Create the Tomcat Folder

Logged in as root, within the opt folder make a directory called tomcat and cd into that folder after completion.

mkdir /opt/tomcat
cd /opt/tomcat

 

Step 2: Install Tomcat Through Wget

Click this link to the Apache Tomcat 7 Download site. Place your cursor under 7.0.90 Binary Distributions, right click on the tar.gz file and select Copy Link Address (as shown in the picture below).  At the time of this article Tomcat 7 is the newest version but feel free to pick whatever version is more up-to-date.

Tomcat Version 7.0.90

Next, from your server, use wget command to download the tar to  the tomcat folder from the URL you copied in the previous step:

wget http://www.trieuvan.com/apache/tomcat/tomcat-7/v7.0.90/bin/apache-tomcat-7.0.90.tar.gz

Note
You can down the file to your local desktop, but you’ll then want to transfer the file to your Liquid Web server. If assistance is needed, check out this article: Using SFTP and SCP Instead of FTP

After the download completes, decompress the file in your Tomcat folder:

tar xvzf apache-tomcat-7.0.90.tar.gz

You will end up with a file called apache-tomcat-7.0.90.

 

Step 3: Install Java

Before you can use Tomcat, you’ll have to install the Java Development Kit (JDK). Beforehand, check to see if Java is installed:

java -version
If that command returns the following message then Java has yet to be installed:
The program 'java' can be found in the following packages:
To install Java, simply run the following command (and at the prompt enter Y to continue:
apt-get install default-jdk

 

Step 4: Configure .bashrc file

Set the environment variables in .bashrc with the following command:

vim ~/.bashrc
Add this information to the end of the file:
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64
export CATALINA_HOME=/opt/tomcat/apache-tomcat-7.0.90

Note
Verify your file paths! If you downloaded a different version or already installed Java, you may have to edit the file path or name. Older versions of Java may say java-7-openjdk-amd64 instead of java-1.8.0-openjdk-amd64 . Likewise, if you installed Tomcat in a different folder other then /opt/tomcat (as suggested) you’ll indicate the path in your bash file and edit the lines above.

Save your edits and exit from the .bashrc file, then run the following command to register the changes:

. ~/.bashrc

 

Step 5: Test Run

Tomcat and Java should now be installed and configured on your server. To activate Tomcat, run the following script:

$CATALINA_HOME/bin/startup.sh

You should get a result similar to:
Using CATALINA_BASE: /opt/tomcat
Using CATALINA_HOME: /opt/tomcat
Using CATALINA_TMPDIR: /opt/tomcat/temp
Using JRE_HOME: /usr/lib/jvm/java-7-openjdk-amd64/
Using CLASSPATH: /opt/tomcat/bin/bootstrap.jar:/opt/tomcat/bin/tomcat-juli.jar
Tomcat started.

 

To verify that Tomcat is working by visiting the IP address of your server:8080 in a web browser. For example http://127.0.0.1:8080.

Tomcat 7.0.90 Test Page