Liquid Web has developed a Hosting Toolkit that provides web developers and curious technophiles a Performance Tool for website testing. We make it easier than ever to optimize and troubleshoot by providing connectivity tests from different geographical locations accompanied with an easy to read grading system for site performance. Continue reading “Website Performance Tool”
If there is one truth in the world of web hosting, it is that we always need more information. Information about configurations, servers, connections, delivery speeds and networking is essential in troubleshooting and optimizing our web presence. While this kind of information can be gathered from various providers and sites across the Internet, Liquid Web has developed a one-stop shop toolkit to gather some of the most vital troubleshooting tools in one convenient interface designed to make your life easier.
The Liquid Web Internet Webhosting Toolkit provides you with the data you need to verify connectivity, identify DNS issues, and test web page performance. We’ll continue to develop and share new tools that will make your job easier; it’s one of the ways that we are working to be the Most Helpful Humans in Hosting. Continue reading “How Do I Use Liquid Web’s Hosting Toolkit?”
What Does Server Load Mean?
Checking a server’s load allows us to evaluate server resources and confirm they are sufficient for any running application. It enables us to troubleshoot slow performance and reliably pinpoint any server resource that may need attention.
While there are many tools and options available, today let’s focus on Windows Task Manager as a way to help us quickly see what is going on, and interact with applications, processes, and services to identify the load. This article will also include an introduction to Resource Monitor as it can be opened from Task Manager to provide more detail.
Ways to start Task Manager
- Click the Start menu and type task… then choose Task Manager
- Right-click the Taskbar area and choose Task Manager from the menu
- Press Ctrl+Alt+End keys on the keyboard when in a Remote Desktop session
- Run the command taskmgr
Let’s bring up the Task Manager and take a look at what it has to offer.
On systems where it has never been used, you may find Task Manager offering this very uninteresting display. Click More details to discover the treasure trove of information it is hiding.
Task Manager provides quick access to Processes, Performance, Users, Details, and Services. We’ll go through each tab to see what they have to offer and discover what to look for when checking server load.
The Processes tab shows us everything that is running in the system and the amount of CPU and memory resources it is using. At the top, we can see the total CPU and memory utilization.
By clicking the CPU or Memory column headings, we can sort the processes list by that criteria, and use the sort arrow to determine whether to sort from highest to lowest usage or the opposite. You can click on any individual process and end the task, see resource usage, and more.
Performance tab has the most visual display of information and allows us to select from CPU, Memory, and Ethernet views to show activity over a 60 second period. With this view, we can identify spikes or see the trend over time to determine if a condition is temporary or sustained.
CPU performance information shows us the type of CPU and speed, the number of processes, threads, and handles in use, as well as the number of virtual CPUs, in most cases. We can also see how long the system has been up (up time). This last bit of information can tell us how long the server has been running, confirm if it successfully completed a restart, or if it rebooted unexpectedly due to running out of resources.
Memory Performance information shows us the total amount of memory in the system as well as what is in use and available. Committed represents virtual memory and the pagefile (an extension of RAM) on disk. Cached represents memory used by Windows, and the Paged pool represents memory used by Windows that can be paged out to the pagefile on disk if memory starts running low. Non-paged cannot be paged to the pagefile.
Ethernet performance information shows us the type of network adapter and the amount of resources it is using with a graphed line for both send and receive as well as numeric values for data being sent. We can also see the Adapter name, Connection type, and the IP address(es) assigned. Right-clicking on the graph will allow us to see network details including network utilization, link speed and state, bytes send and received, etc. On the Performance tab, we also have the option to launch Resource Monitor to see even more detail.
The Users tab shows us a list of all the users connected to the server and how much CPU and memory resources the user is utilizing. We can click on a specific user to Disconnect them, send them a message, or take over their session if we have Administrator rights. In the context of checking for load, we can determine if a specific user is consuming too many resources or has disconnected from a session, leaving it running in memory, and choose whether to log the user out to free up resources.
The Details tab shows us a list of all the running programs and processes along with their PID (Process ID) number, whether the program is running or suspended, the user name it is running under, the amount of CPU and memory it is using, and a description of the process. You can click any of the column names to sort by that column in highest to lowest or the opposite order. The PID number can be very helpful to track down a specific process that is referenced in event logs. Right-clicking an item allows us to choose options including:
- ending a process or process tree
- set a priority for the running process
- establish affinity to a specific processor or all processors
- additional options
The Services tab shows us a list of service names, their PID (Process ID) numbers, a description of the service, the status as either stopped or running, and the Group the service is running under. Right-clicking on a service allows us to start, stop, restart, and access additional options. We should be careful not to change the status of some services as they depend on others, and stopping the wrong one could have unintended consequences on the system or devices. To learn more about a service, we can right-click it and choose Search Online.
How Do I Check My Resouce Monitor?
Ways to start Resource Monitor
- Click the Start menu and type resource… then choose Resource Monitor
- Right-click the Taskbar area and choose Task Manager from the menu, then from Performance tab choose Open Resource Monitor
- Run the command resmon
Let’s bring up Resource Monitor and take a look at what it has to offer. You’ll find this has more depth but is very similar to the information available from Task Manager. For this reason, we’ll only cover the overview and a brief description of each tab in this article.
Overview provides us with data on CPU, Memory, Disk, and Network options and graphs all on one page with the option to expand or collapse each section. It will also show current usage of a resource as well as the highest active time. Clicking individual sections provides more detail.
CPU shows processes, services, associated handles, and modules, and will show individual CPUs and their load in addition to total CPU.
Memory shows processes in addition to a breakdown of the physical memory and graphs to show commit charge which relates to use of the pagefile and the number of hard faults per second which can be an indicator of how many times Windows has to access the swap file. If your system is showing hundreds of hard faults per second, this indicates a need more physical memory.
Disk shows the processes in addition to a breakdown of how much each task is reading and writing to disk. The graphs show total disk activity in addition to Queue Length. Disk Queue length indicates how many disk I/O operations are queued up waiting for their turn to be processed by the disk. If we find that the highest active time is above 80% and the disk queue length is 2 or higher, it means processes are waiting, and the performance of the disk is affecting the overall performance of the system. In many cases, this number will be high due to a system that lacks sufficient physical memory and is constantly paging information to disk or relying too heavily on virtual memory. It will often be accompanied by a CPU running above 90% for sustained periods.
Network shows the processes with network activity, in addition to TCP connections and listening ports, and graphs to show network transfer and TCP connections. Sustained high network utilization can indicate congestion issues and a need for more capacity.
Still having trouble determining what is bogging down your server? With Liquid Web’s servers, you can talk to a experienced support tech night or day. Our techs have the expertise needed to help determine bottlenecks in your system. Switch to Liquid Web today and get the support you’ve been looking for!
As discussed earlier in our MySQL Performance series, the InnoDB storage engine is designed to be a high-performance database for very large datasets. The row-locking technique it uses allows for many read and write requests to occur on a single table concurrently. This is a vast improvement in speed over traditional Continue reading “MySQL Performance: InnoDB Buffers & Directives”
The majority of work needed when adjusting the MySQL server is editing the applicable directives within a MySQL configuration file. There are multiple, optional configuration files that MySQL looks for when starting up. They are read in the following order: Continue reading “MySQL Performance: System Configuration File & Routine Maintenance”
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.
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>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.
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.
A 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.
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.
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.
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.
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 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 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.
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.
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).
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.
Used to set the maximum value of ThreadsPerChild. This directive is a hard ceiling for ThreadsPerChild. It helps protect against typographical errors with the
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.
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 responsible
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.
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.
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.
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.
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.
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.
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.
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.
If 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.
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.
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.
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.
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.
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.
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 Continue reading “Apache Performance Tuning: Swap Memory”
Memcached works to enhance performance by keeping a copy of commonly used script elements within the server’s memory in a form that is more easily read by the server thus reducing time. Continue reading “Install Memcached on Ubuntu 16.04”
A major factor in database performance is the storage engine used by the database, and more specifically, its tables. Different storage engines provide better performance in one situation over another. For general use, there are two contenders to be considered. These are MyISAM, which is the default MySQL storage engine, or InnoDB, which is an alternative engine built-in to MySQL intended for high-performance databases. Before we can understand the difference between the two storage engines, we need to understand the term “locking.” Continue reading “MySQL Performance: MyISAM vs InnoDB”