mod_performance
What is this module? It is a standard Apache 2.x module for Linux. According to its documentation:
- The module is designed to collect and accumulate statistics on resource usage (CPU and memory, script execution time) by the Apache 2.2 web server;
- The module allows analysis of the collected data.
What does all this mean? It means that it allows you to monitor how much resources a request received by the web server consumes. Each time, it saves the following information:
- The virtual host to which the request was sent;
- The file being requested;
- The request URI;
- CPU load in %;
- Memory usage in %;
- Request processing time.
And for the accumulated statistics, it allows analysis. SQLite is used as the database for storage and analysis.
As the resource usage analyzer, it uses glibtop, not the scoreboard as in mod_status and perl extensions.
The module allows tracking both absolutely all requests and specific ones filtered by a rule using regular expressions. More precisely, the module ALWAYS processes only those requests that match the filter containing the regular expression.
How to view accumulated data
The module provides two interfaces for viewing and analyzing data: 1) global; 2) the so-called per-host.
Each interface is attached to a handler:
user-status — per-host
performance-status — global
Access to the interfaces is configured as in the mod_status module, i.e.:
<Location /perf-status>
Order allow,deny
SetHandler performance-status
Allow from 1.1.1.1
</Location>
The global interface allows viewing and analyzing accumulated data for all virtual hosts, while the per-host interface displays and analyzes information only for the host to which the interface is attached. For example, if you call the host test.test.test/user-status, all displayed statistics will relate only to this host. Statistics for other hosts will not be displayed.
The global module management interface looks as shown in the figure below:
In the main form, as shown in the figure, you can see the following fields:
Mode — data display mode.
Period — number of days, the display or analysis period starting from the beginning of the current day.
Period begin — start of the period, specified in the YYYY-MM-DD hh:mm:ss format.
Period end — end of the period, specified in the YYYY-MM-DD hh:mm:ss format.
If Period begin and Period end are specified, data limited by these parameters is displayed, and the Period field is ignored. Otherwise, the analyzed segment is defined by the Period parameter.
Hostname(SQL) — filter to display data only for the specified host. The syntax is similar to the LIKE clause in SQL. For example, if you specify “%test”, all hosts ending with “test” will be selected.
Script name(SQL) — similar to the previous parameter, but it analyzes the name of the called script.
URI(SQL) — similar to the previous parameter, but it analyzes the request URI.
Graph Mode(Y/N) — display data graphically or as text.
The approximate output looks like this:
The host shown in the example image is purely test data; if it matches a real host, I apologize.
The graphical display mode is shown in the figure below:
Analysis Modes
Show output without analytics – display collected information without analysis, filtered by host, script, and URI (graphical and text modes).
Maximal %CPU – display only records with the maximum %CPU value (considering filters).
Maximal memory % – display only records with the maximum %memory value (considering filters).
Maximal execution request time – display the longest-running script.
Host requests statistics – display statistics of requests to hosts, sorted in descending order (as a percentage of the total, considering filters).
Execution history screen(use Period begin) – allows calculating the list of requests being executed at a specified time.
Number of requests per domain – display statistics of requests to hosts, sorted in descending order (not as percentages, but as absolute counts).
Average usage per host – display the average server load for each host (sum of % CPU, sum of % MEMORY, sum of script execution times, average % CPU over the period, average % memory usage, average script execution time).
I will not go into detail and will leave some modes unmentioned.
How to Install the Module
Here I provide an installation example for RPM-based systems. All actions must be performed as the root user.
1) Install the necessary packages for building:
yum install httpd-devel apr-devel libgtop2-devel sqlite-devel gd-devel
2) Create a temporary directory for the source code:
mkdir ~/my_tmp cd ~/my_tmp
3) Download the module source code, extract the archive, and navigate to the extracted directory:
wget http://lexvit.dn.ua/utils/getfile.php?file_name=mod_performance_tar201104233487.gz -O mod_performance.tar.gz tar zxvf mod_performance.tar.gz cd mod_performance/
4) Build the module:
make
5) Ignore warnings. The main thing is that there should be no errors. If everything builds correctly, then:
make install
or
cp .libs/mod_performance.so <путь куда копировать>
Configuring Apache
The configuration will be performed for a standard Apache installation, i.e., modules are located in the /etc/httpd/modules directory, the /etc/httpd/conf.d/ directory exists, and it is included in /ect/httpd/conf/httpd.conf.
1) create a module configuration file:
touch /etc/httpd/conf.d/mod_performance.conf
2) insert the following into it:
LoadModule performance_module modules/mod_performance.so <IfModule mod_performance.c> PerformanceHistory 5 PerformanceEnabled On PerformanceMaxThreads 80 PerformanceScript \.php PerformanceStackSize 1 PerformanceUseCanonical On <Location /admin-status> Order allow,deny SetHandler performance-status Allow from 1.1.1.1 </Location> </IfModule>
3) save the file and restart Apache:
service httpd restart
The configuration file serves only as an example. All parameters must be adjusted for a specific server.
The above module configuration allows tracking requests to PHP scripts.
A description of all configuration parameters can be found in the module documentation.