Views: 2069 (Data available since 06.02.2017)
Last Modified: 10.10.2012

First of all, you have to get an estimation of your websiteís performance. Open Performance Panel (Settings > Performance > Performance Panel).

Click Test Performance to identify improper web server settings. It is important to bear in mind that the values in the Configuration row may vary significantly depending on the server load: the server will show the highest performance scores in the absence of load, while it may degrade severely at the peak load time.

The module would be of not much help if it showed only the web server performance scores. In fact, the main purpose of it is to find the bottlenecks preventing the website from normal operation. To do so, you have to keep the test running for a certain amount of time: a low traffic web project may require a hour or more, while a highly popular website needs less time. The system will register hits and gather statistics: page execution time, SQL queries and other parameters.

If your website is still yet to be launched, you may have to open pages manually or use some special testing software.

The performance score is the value inversely proportional to an average of ten execution times of the system kernel.

Reading the value on the screenshot shown above (performance = 16.23), one may deduce that the average generation time of a public webpage with an empty template and an empty work area is 1/16.23, or 0.0616 sec. In terms of speed, a web server is capable of creating 16 empty pages per second.

The performance score is in no way based on the performance of the file system, database, sessions or mail subsystem. The purpose of these and all other parameters are to help web developers and system administrators find weak points in the website.

The Configuration Tab

This tab shows the current performance values of the web server subsystems. The reference values are also provided.

If any subsystem is out of the optimum range, the report shows a link opening essential recommendations.

The Most Common Configurations Issues

  • No PHP accelerator installed.
    A PHP accelerator is a vital part of any up-to-date web server. Even if you leave all settings by default, your web pages will be generated three times faster, and the processor load will decrease threefold as well. Zend Server CE is objectively twice as faster than any other accelerator at the moment. However, it may become unstable on certain machines. If thatís the case, use APC, EAccelerator, XCache.
  • An open_basedir restriction is in effect.
    The most common issue of all shared hostings is the use of open_basedir to separate clients. This, in turn, brings about excessive CPU load because of additional pathname checks. The solutions is to use a private Apache instance. Remember that you have absolutely no need to install open_basedir on a dedicated server or VPS!
  • nginx is not installed or not configured.
    Not essential as it is, this may become a problem for an extremely high traffic website. All the static content (images, CSS files, scripts) must be relayed by nginx. Apache does not even have to know about static files. Check the Apache access logs: it must not show any access to static content whatsoever.
  • Database is not configured.
    Use InnoDB whenever possible; you will find the recommended settings on the DB Server performance monitor form. Another useful tool is a mysqltuner.pl script: itís simple to install and will help you much with MySQL.
  • Third-party hardware drivers are in use.
    This issue is common to RAID controllers: when installing it on Linux, the system usually offers open source drivers which may not be optimized to a particular controller model. Always install the latest drivers downloaded from the manufacturerís website.
  • PHP as CGI.
    Using PHP as CGI (not FastCGI) is a faulty practice because every time there is a request to a PHP script, the server is forced to run a new instance of PHP. Obviously, the performance is extremely poor.

Reading the subsystem scores

Performance Monitor has no direct access to system resources, therefore the scores obtained by running PHP scripts are a bit more about the PHP interpreter than the server itself.

  • Configuration is the performance score itself.
  • Average response time is a reciprocal of the performance score.
  • CPU. This test performs a large number of simple mathematical calculations. The task is not paralleled; the value is the performance score of a single CPU core. If a website is running on VPS, the CPU value clearly reflects this fact.
  • File system. This test creates, runs and deletes a large number of small files; it is more about how PHP handles files rather than the disk system. However, this value is highly dependent on the file system performance and the PHP accelerator. In general, this test is a good estimation of how well PHP is configured (without regard to database access).
  • E-mail system. Sends a test message to hosting_test@bitrix.ru reading "This is test message. Delete it." This test never sends any other information! If you are using cron to send e-mail messages, you can ignore this value.
  • Session start time. A session is started whenever a hit occurs, therefore this value adds to the page generation time. The most common issue with sessions is bad PHP session configuration causing hundreds of thousands session files to be amassed.
  • Database (read/write/change). Sends a large number of simple database queries. This test is a bit exaggerated: it does not show how the database will handle complex queries with large portions of data. It is obvious that a local computer will show better results than a remote web server; it is normal.

The Bitrix Tab

This tab shows the current system settings that have an immediate effect on the system performance, and the recommendations.



The Development Tab

This tab shows average times for the web pages accessed while testing, and potential development errors.

To view the error description, use the links in the Development errors column. On the screenshot above, the system suggests that a developer fix an uncached include ares.

To see the faulty page, click the page link in the first column.


The following figure shows hits and statistics for /catalog/furniture/index.php:

The /catalog/furniture/index.php page uses the Catalog composite component that uses SEF URL translation, thatís why the real URLís are different. The table is sorted by ascending page execution time: notice that the /catalog/furniture/illuminating page was first generated in 0.8 sec., while the subsequent requests took 0.7 sec each. The most efficient optimization was the component caching, which in turn decreased SQL queries.

Now letís see what components this page is using. Click the number in the Components column of a required page. The following screenshot shows the components for the hit #4 at /catalog/furniture/illuminating.

Here we can see the components the page was using, the number of SQL queries and the caching type. #4 is just the uncached editable area gracefully reported by Performance Monitor.

Now we can check the SQL queries for this page (for #4). But how do we know which area (there are four of them) goes uncached?

Get back to Performance monitor: Hits and click an arrowed link (>>) preceding the page URL. The page summary statistics window will open. Now we can see the longest page generation stage:

Close this window and click Performance (Performance> Statistics summary) on the toolbar.

If interested, youíll find more details on using Performance Monitor in the public section in Public Interface lesson.


The Scalability Tab

Since version 10.0 a built-in feature exist to test multithreaded and clustered systems.


Important Hints

  • The score is edition-dependent.
    Since the test measures kernel time, the score is obviously conditioned by the kernel size. The major Ultimate edition with all the modules installed and enabled will always show worse results than a simple Start edition on the same hardware. The reference score values was obtained from the Ultimate edition.
  • The score depends on the custom calls in /bitrix/php_interface/init.php.
    This file is included whenever a hit occurs, even when showing Control Panel pages. This file must not perform database queries, or any other resource consuming operations.
  • The score depends on the server load.
    Higher server load will produce lower score Ė thatís a rule. However, it should not fall below an empirically acceptable value (for example: not lower than 10 poins meaning 0.1 sec. per page).
  • The score does not display a systemís potential for scalability or lack thereof.
    A web server process is single-cored meaning it uses only one CPU core. Measuring the performance without a real-world load does not affect the score. Similarly, a multicore web server can withstand heavy loads without significant performance degradation.
  • A remote cluster database will decrease the score.
    A cluster is a scalable system: it is supposed to retain good performance at an increasing load. However, measuring the page acquisition time will show an unnoticeable, slight deceleration due to inter-server communications.



Courses developed by «Bitrix», Inc.