1. Use a Dedicated Server

   Database is the main bottleneck from Zabbix. Try to use a Dedicated Server for MySQL and make sure that server has great resources (CPU, memory and fast disks).

   This is the specs for an environment with 3000 values per second:

   Dell PowerEdge R610
   CPU: Intel Xeon L5520 2.27GHz (16 cores)
   Memory: 24GB RAM
   Disks: 6x SAS 10k with RAID10 by hardware

2. Create one file per table

   innodb_file_per_table=1

   By default, InnoDB creates all tables inside an unique datafile. With this option the new tables will have your own datafile. So after the change, You’ll need recreate the tables.

   It opens some possibilities like put your tables in different filesystems and makes backup with more consistency.

   Peter Zaitsev – http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
   innodb_file_per_table – If you do not have too many tables use this option, so you will not have uncontrolled innodb main tablespace growth which you can’t reclaim.

   Tristan – cPanel Staff – http://forums.cpanel.net/f43/innodb_file_per_table-converting-per-table-data-innodb-167942.html
   Issue with shared InnoDB /var/lib/mysql/ibdata1 storage
   InnoDB tables currently store data and indexes into a shared tablespace (/var/lib/mysql/ibdata1). Due to the shared tablespace, data corruption for one InnoDB table can result in MySQL failing to start up on the entire machine. Repairing InnoDB corruption can be extremely difficult to perform and can result in data loss for tables that were not corrupted originally during that repair process.

   Some discussions about this:
   http://dom.as/2009/05/21/innodb-tablespace/
   http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table

   Personally I lost all my data because the ibdata file crashed (all data inside one file).

   Ref.: http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html

3. Percona vs Community Edition

   Percona Server is a modified version from MySQL Community Edition.

   Some benchmarks show us about Percona performance advantages:
   http://www.percona.com/software/percona-server/benchmarks/

4. Use partitioning tables and disable the Housekeeper

   Housekeeper reduces the MySQL performance (see History Tables – Housekeeper). So a simple alternative is use the Partitioning native resource from MySQL.

   In this blog there is another article about it: Partitioning Tables

5. Use tmpfs filesystem for Temporary Files

   Using memory instead of local disks will allow a much faster creation of temporary tables on MySQL.

   First, create the mountpoint:

   mkdir /tmp/mysqltmp

   Add this line in your /etc/fstab:

   tmpfs /tmp/mysqltmp tmpfs rw,uid=mysql,gid=mysql,size=1G,nr_inodes=10k,mode=0700 0 0

   Make sure to adjust the size parameter. For reference, use 08~10% from physical memory.

   Finally, you need to define this path in /etc/my.cnf and restart MySQL:

   tmpdir = /tmp/mysqltmp

6. Set your Buffer Pool properly

   This is one of most important parameters in /etc/my.cnf. It defines how much memory InnoDB can use.

   I recommend something like 70~80% from physical memory:

   innodb_buffer_pool_size=14G

   Ref.: http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/

It’s the /etc/my.cnf sample for a server with 24GB RAM:

[mysqld]
# paths
datadir                         = /var/lib/mysql/data
tmpdir                          = /tmp/mysqltmp

# network
connect_timeout                 = 60
wait_timeout                    = 28800
max_connections                 = 2048
max_allowed_packet              = 64M
max_connect_errors              = 1000

# limits
tmp_table_size                  = 512M
max_heap_table_size             = 256M
table_cache                     = 512

# logs
log_error                       = /var/log/mysql/mysql-error.log
slow_query_log_file             = /var/log/mysql/mysql-slow.log
slow_query_log                  = 1
long_query_time                 = 20

# innodb
innodb_data_home_dir            = /var/lib/mysql/data
innodb_data_file_path           = ibdata1:128M;ibdata2:128M:autoextend:max:4096M
innodb_file_per_table           = 1
innodb_status_file              = 1
innodb_additional_mem_pool_size = 128M
innodb_buffer_pool_size         = 14G
innodb_flush_method             = O_DIRECT
innodb_io_capacity              = 2000
innodb_flush_log_at_trx_commit  = 2
innodb_support_xa               = 0
innodb_log_file_size            = 512M
innodb_log_buffer_size          = 128M

# experimental
innodb_stats_update_need_lock   = 0

# other stuff
event_scheduler                 = 1
query_cache_type                = 0

If you need, there are some references about MySQL parameters:
http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html
http://www.mysqlperformanceblog.com/

As the result is very small (around 30 MB), is possible run this backup many times per day.

https://github.com/xsbr/zabbixzone/blob/master/zabbix-mysql-backupconf.sh

#!/bin/bash
#
# zabbix-mysql-backupconf.sh
# v0.2 - 20111105
#
# Configuration Backup for Zabbix 1.8 w/MySQL
#
# Author: Ricardo Santos (rsantos at gmail.com)
# http://zabbixzone.com
#
# Thanks for suggestions from:
# - Oleksiy Zagorskyi (zalex)
# - Petr Jendrejovsky
#

# mysql config
DBHOST="localhost"
DBNAME="zabbix"
DBUSER="zabbix"
DBPASS="YOURMYSQLPASSWORDHERE"

# some tools
MYSQLDUMP="`which mysqldump`"
GZIP="`which gzip`"
DATEBIN="`which date`"
MKDIRBIN="`which mkdir`"

# target path
MAINDIR="/var/lib/zabbix/backupconf"
DUMPDIR="${MAINDIR}/`${DATEBIN} +%Y%m%d%H%M`"
${MKDIRBIN} -p ${DUMPDIR}

# configuration tables
CONFTABLES=( actions applications autoreg_host conditions config dchecks dhosts \
drules dservices escalations expressions functions globalmacro graph_theme \
graphs graphs_items groups help_items hostmacro hosts hosts_groups \
hosts_profiles hosts_profiles_ext hosts_templates housekeeper httpstep \
httpstepitem httptest httptestitem ids images items items_applications \
maintenances maintenances_groups maintenances_hosts maintenances_windows \
mappings media media_type node_cksum nodes opconditions operations \
opmediatypes profiles proxy_autoreg_host proxy_dhistory proxy_history regexps \
rights screens screens_items scripts service_alarms services services_links \
services_times sessions slides slideshows sysmaps sysmaps_elements \
sysmaps_link_triggers sysmaps_links timeperiods trigger_depends triggers \
user_history users users_groups usrgrp valuemaps )

# tables with large data
DATATABLES=( acknowledges alerts auditlog_details auditlog events \
history history_log history_str history_str_sync history_sync history_text \
history_uint history_uint_sync trends trends_uint )

# CONFTABLES
for table in ${CONFTABLES[*]}; do
        DUMPFILE="${DUMPDIR}/${table}.sql"
        echo "Backuping table ${table}"
        ${MYSQLDUMP} -R --opt --extended-insert=FALSE \
                -h ${DBHOST} -u ${DBUSER} -p${DBPASS} ${DBNAME} --tables ${table} >${DUMPFILE}
        ${GZIP} -f ${DUMPFILE}
done

# DATATABLES
for table in ${DATATABLES[*]}; do
        DUMPFILE="${DUMPDIR}/${table}.sql"
        echo "Backuping schema table ${table}"
        ${MYSQLDUMP} -R --opt --no-data	\
                -h ${DBHOST} -u ${DBUSER} -p${DBPASS} ${DBNAME} --tables ${table} >${DUMPFILE}
        ${GZIP} -f ${DUMPFILE}
done

echo
echo "Backup Completed - ${DUMPDIR}"

Use all information and scripts at your own risk. Make backups!

My suggestion is disable housekeeping and to partition some tables based on clock, an unix timestamp field. If you wanna know more about partitioning access the MySQL Reference Manual – Partitioning Overview.

The Concept

An easy way to handle partitioning is splitting the tables into two groups based on their growth:

Daily – basically the largest tables

• history
• history_log
• history_str
• history_text
• history_uint

See more information about history tables.

Monthly – other huge tables

• acknowledges
• alerts
• auditlog
• events
• service_alarms
• trends
• trends_unit

Step 1 – Preparing the Tables

To partition a table using the clock, the field needs belong to the primary key or not have one. So we need make some key changes on this tables:

ALTER TABLE `acknowledges` DROP PRIMARY KEY, ADD KEY `acknowledgedid` (`acknowledgeid`);
ALTER TABLE `alerts` DROP PRIMARY KEY, ADD KEY `alertid` (`alertid`);
ALTER TABLE `auditlog` DROP PRIMARY KEY, ADD KEY `auditid` (`auditid`);
ALTER TABLE `events` DROP PRIMARY KEY, ADD KEY `eventid` (`eventid`);
ALTER TABLE `service_alarms` DROP PRIMARY KEY, ADD KEY `servicealarmid` (`servicealarmid`);
ALTER TABLE `history_log` DROP PRIMARY KEY, ADD PRIMARY KEY (`itemid`,`id`,`clock`);
ALTER TABLE `history_log` DROP KEY `history_log_2`;
ALTER TABLE `history_text` DROP PRIMARY KEY, ADD PRIMARY KEY (`itemid`,`id`,`clock`);
ALTER TABLE `history_text` DROP KEY `history_text_2`;

Step 2 – Setup Monthly Partitions

Repeat this step with each table (see above) with appropriate months.

In this example, we’ll create the monthly partitions to events table since May 2011 until December 2011:

ALTER TABLE `events` PARTITION BY RANGE( clock ) (
PARTITION p201105 VALUES LESS THAN (UNIX_TIMESTAMP("2011-06-01 00:00:00")),
PARTITION p201106 VALUES LESS THAN (UNIX_TIMESTAMP("2011-07-01 00:00:00")),
PARTITION p201107 VALUES LESS THAN (UNIX_TIMESTAMP("2011-08-01 00:00:00")),
PARTITION p201108 VALUES LESS THAN (UNIX_TIMESTAMP("2011-09-01 00:00:00")),
PARTITION p201109 VALUES LESS THAN (UNIX_TIMESTAMP("2011-10-01 00:00:00")),
PARTITION p201110 VALUES LESS THAN (UNIX_TIMESTAMP("2011-11-01 00:00:00")),
PARTITION p201111 VALUES LESS THAN (UNIX_TIMESTAMP("2011-12-01 00:00:00")),
PARTITION p201112 VALUES LESS THAN (UNIX_TIMESTAMP("2012-01-01 00:00:00"))
);

Step 3 – Setup Daily Partitions

Repeat this step with each table (see above) with appropriate days.

In this example, we’ll create the daily partitions to history_uint table since 15th May until 22th May:

ALTER TABLE `history_uint` PARTITION BY RANGE( clock ) (
PARTITION p20110515 VALUES LESS THAN (UNIX_TIMESTAMP("2011-05-16 00:00:00")),
PARTITION p20110516 VALUES LESS THAN (UNIX_TIMESTAMP("2011-05-17 00:00:00")),
PARTITION p20110517 VALUES LESS THAN (UNIX_TIMESTAMP("2011-05-18 00:00:00")),
PARTITION p20110518 VALUES LESS THAN (UNIX_TIMESTAMP("2011-05-19 00:00:00")),
PARTITION p20110519 VALUES LESS THAN (UNIX_TIMESTAMP("2011-05-20 00:00:00")),
PARTITION p20110520 VALUES LESS THAN (UNIX_TIMESTAMP("2011-05-21 00:00:00")),
PARTITION p20110521 VALUES LESS THAN (UNIX_TIMESTAMP("2011-05-22 00:00:00")),
PARTITION p20110522 VALUES LESS THAN (UNIX_TIMESTAMP("2011-05-23 00:00:00"))
);

Maintaining the Partitions Manually

Adding new partitions:

ALTER TABLE `history_uint` ADD PARTITION (
PARTITION p20110523 VALUES LESS THAN (UNIX_TIMESTAMP("2011-05-24 00:00:00"))
);

Dropping partitions (Housekeeping):

ALTER TABLE `history_uint` DROP PARTITION p20110515;

Step 4 – Auto Daily Partitioning

Make sure that you created the partitioning correctly on the history tables (Step 3)

This script drops and creates automatically the daily partitioning.

The default is keep only last 3 days, if you wanna more days change @mindays variable.

Don’t forget to put it on cron:

mysql -B -h localhost -u zabbix -pPASSWORD zabbix -e "CALL create_zabbix_partitions();"

Procedures

https://github.com/xsbr/zabbixzone/blob/master/zabbix-mysql-autopartitioning.sql

/**************************************************************
  MySQL Auto Partitioning Procedure for Zabbix 1.8
  http://zabbixzone.com/zabbix/partitioning-tables/

  Author:  Ricardo Santos (rsantos at gmail.com)
  Version: 20110518
**************************************************************/
DELIMITER //
DROP PROCEDURE IF EXISTS `zabbix`.`create_zabbix_partitions` //
CREATE PROCEDURE `zabbix`.`create_zabbix_partitions` ()
BEGIN
	CALL zabbix.create_next_partitions("zabbix","history");
	CALL zabbix.create_next_partitions("zabbix","history_log");
	CALL zabbix.create_next_partitions("zabbix","history_str");
	CALL zabbix.create_next_partitions("zabbix","history_text");
	CALL zabbix.create_next_partitions("zabbix","history_uint");
	CALL zabbix.drop_old_partitions("zabbix","history");
	CALL zabbix.drop_old_partitions("zabbix","history_log");
	CALL zabbix.drop_old_partitions("zabbix","history_str");
	CALL zabbix.drop_old_partitions("zabbix","history_text");
	CALL zabbix.drop_old_partitions("zabbix","history_uint");
END //
DROP PROCEDURE IF EXISTS `zabbix`.`create_next_partitions` //
CREATE PROCEDURE `zabbix`.`create_next_partitions` (SCHEMANAME varchar(64), TABLENAME varchar(64))
BEGIN
	DECLARE NEXTCLOCK timestamp;
	DECLARE PARTITIONNAME varchar(16);
	DECLARE CLOCK int;
	SET @totaldays = 7;
	SET @i = 1;
	createloop: LOOP
		SET NEXTCLOCK = DATE_ADD(NOW(),INTERVAL @i DAY);
		SET PARTITIONNAME = DATE_FORMAT( NEXTCLOCK, 'p%Y%m%d' );
		SET CLOCK = UNIX_TIMESTAMP(DATE_FORMAT(DATE_ADD( NEXTCLOCK ,INTERVAL 1 DAY),'%Y-%m-%d 00:00:00'));
		CALL zabbix.create_partition( SCHEMANAME, TABLENAME, PARTITIONNAME, CLOCK );
		SET @i=@i+1;
		IF @i > @totaldays THEN
			LEAVE createloop;
		END IF;
	END LOOP;
END //
DROP PROCEDURE IF EXISTS `zabbix`.`drop_old_partitions` //
CREATE PROCEDURE `zabbix`.`drop_old_partitions` (SCHEMANAME varchar(64), TABLENAME varchar(64))
BEGIN
	DECLARE OLDCLOCK timestamp;
	DECLARE PARTITIONNAME varchar(16);
	DECLARE CLOCK int;
	SET @mindays = 3;
	SET @maxdays = @mindays+4;
	SET @i = @maxdays;
	droploop: LOOP
		SET OLDCLOCK = DATE_SUB(NOW(),INTERVAL @i DAY);
		SET PARTITIONNAME = DATE_FORMAT( OLDCLOCK, 'p%Y%m%d' );
		CALL zabbix.drop_partition( SCHEMANAME, TABLENAME, PARTITIONNAME );
		SET @i=@i-1;
		IF @i <= @mindays THEN
			LEAVE droploop;
		END IF;
	END LOOP;
END //
DROP PROCEDURE IF EXISTS `zabbix`.`create_partition` //
CREATE PROCEDURE `zabbix`.`create_partition` (SCHEMANAME varchar(64), TABLENAME varchar(64), PARTITIONNAME varchar(64), CLOCK int)
BEGIN
	DECLARE RETROWS int;
	SELECT COUNT(1) INTO RETROWS
		FROM `information_schema`.`partitions`
		WHERE `table_schema` = SCHEMANAME AND `table_name` = TABLENAME AND `partition_name` = PARTITIONNAME;
	
	IF RETROWS = 0 THEN
		SELECT CONCAT( "create_partition(", SCHEMANAME, ",", TABLENAME, ",", PARTITIONNAME, ",", CLOCK, ")" ) AS msg;
     		SET @sql = CONCAT( 'ALTER TABLE `', SCHEMANAME, '`.`', TABLENAME, '`',
				' ADD PARTITION (PARTITION ', PARTITIONNAME, ' VALUES LESS THAN (', CLOCK, '));' );
		PREPARE STMT FROM @sql;
		EXECUTE STMT;
		DEALLOCATE PREPARE STMT;
	END IF;
END //
DROP PROCEDURE IF EXISTS `zabbix`.`drop_partition` //
CREATE PROCEDURE `zabbix`.`drop_partition` (SCHEMANAME varchar(64), TABLENAME varchar(64), PARTITIONNAME varchar(64))
BEGIN
	DECLARE RETROWS int;
	SELECT COUNT(1) INTO RETROWS
		FROM `information_schema`.`partitions`
		WHERE `table_schema` = SCHEMANAME AND `table_name` = TABLENAME AND `partition_name` = PARTITIONNAME;
	
	IF RETROWS = 1 THEN
		SELECT CONCAT( "drop_partition(", SCHEMANAME, ",", TABLENAME, ",", PARTITIONNAME, ")" ) AS msg;
     		SET @sql = CONCAT( 'ALTER TABLE `', SCHEMANAME, '`.`', TABLENAME, '`',
				' DROP PARTITION ', PARTITIONNAME, ';' );
		PREPARE STMT FROM @sql;
		EXECUTE STMT;
		DEALLOCATE PREPARE STMT;
	END IF;
END //
DELIMITER ;

Each item on Zabbix can have your own housekeeper value. But this feature turns housekeeping process a performance killer, because delete_history() function executes a DELETE per item every turn. If you have 100k items, 100k DELETE queries will be executed.

This can be a big problem using InnoDB engine on MySQL, because DELETE is extremelly slow on large tables and deleted rows doesn’t release space on disk.

My proposed and tested solution is disable housekeeping and partitioning some tables.

To know more about it. read my post Partitioning Tables.

Moreover, in recent years Git gained much popularity among coders against the SVN (Subversion).

Gathered these needs, I created a read-only Git repository with a GitWeb interface:

http://git.zabbixzone.com

It is automatically updated every 4 hours from the official Zabbix SVN (svn://svn.zabbix.com) and is only recommended for research purposes.

Only changing 3 files inside images directory, I created new six colors: cyan, golden, green, grey, red and violet.

Installation Instructions (only for Zabbix 1.8.x)

1. Download zabbix1.8-colors.zip (all colors included) and extract on your computer
2. Upload the 3 image files from your favorite color to FTP on directory /images/gradients/
3. Reload the Page. Some browsers can need to force the refresh (CTRL+F5 or CTRL+R)

Preview

cyan

golden

green

grey

red

violet

But the numbers can be a little hard to understand. Let’s try make it easy:

Imagine that the last check from an item occurred at 11:05:00. It’s configured to check each 3 minutes (180 seconds delay), then the next check should be made ​​at 11:08:00.

Something happened (like Zabbix Proxy was down)  and this item was not checked at 11:08:00.

If the clock is now 11:09:10, this item is delayed 70 seconds, then it would appear in the column “1 minute”.

According to the image below, in the 5th line:

• 457 items are delayed between 5 and 10 seconds (x>=5 and x<10)
• 12 items are delayed between 10 and 30 seconds (x>=10 and x<30)
• 3 items are delayed between 1 and 5 minutes (x>=60 and x<300)
• 1 item is delayed between 5 and 10 minutes (x>=300 and x<600)

History

All collected data, doesn’t matter what type, will be stored on history tables.

Trends

Trends basically are the collected data (only numeric) consolidated by hour. Zabbix Server hourly takes all values from history tables and calculates minimum, average and maximum for one hour period.

Note: string items, like character, log and text, doesn’t have trends

Housekeeper

Both data still remains on database until Housekeeper from Zabbix Server deletes it based on Keep history and Keep trends configurations:

So if you have an item with 60 seconds Update interval and 7 days for Keep history it will generates (60*24*7) 10080 rows per-item on history table.

For trend table, with 730 days configuration, it will generates (24*7) 17520 rows per-item.

Database tables for history/trends and theirs item type:

• history – numeric (float)
• history_uint – numeric (unsigned integers)
• history_str – character (up to 255 bytes)
• history_log – log
• history_text – text
• trends – numeric (float)
• trends_uint – numeric (unsigned integers)

If you have a large environment, I recommend you to disable housekeeping, the explanation in this post.

Recommendations

1. Consider not more than 7 days for history (3 days for medium environments)
2. Avoid intervals less than 60 seconds
3. Keep your eyes on disksize from history/trend tables

Automation Tools like CFEngine and Puppet do this work well done, but unfortunately they aren’t used in many companies.

But it’s possible using a Dynamic UserParameter:

1) add two lines on zabbix_agentd.conf and restart the agent:

UserParameter=custom.getvalue[*],/etc/zabbix/zabbix_agentd/custom_getvalue $1 $2 $3 $4 $5
UserParameter=custom.updatescript,/etc/zabbix/zabbix_agentd/custom_updatescript

2) create the script file /etc/zabbix/zabbix_agentd/custom_getvalue

#!/bin/bash
ACTION=$1
PARAM1=$2
PARAM2=$3
PARAM3=$4
PARAM4=$5

case ${ACTION} in
# key: custom.getvalue[samplescript1,arg]
samplescript1)
  /bin/echo This is a test - ${PARAM1}
  ;;
# key: custom.getvalue[samplescript2,arg1,arg2]
samplescript2)
  /bin/echo This is another test - ${PARAM1} ${PARAM2}
  ;;
*)
  /bin/echo ZBX_NOTSUPPORTED
  ;;
esac

Don’t forget to set execute permission:

chmod 0755 /etc/zabbix/zabbix_agentd/custom_getvalue

Now when you need create a new script, you must update this script and restart is unnecessary.

Remote Updates

Finally, let’s create a script to update custom_getvalue script remotely. Before make sure to publish your custom_getvalue script on a WebServer.

Create the file /etc/zabbix/zabbix_agentd/custom_updatescript:

#!/bin/bash
/usr/bin/wget "http://yourdomain.com/zabbix/custom_getvalue" -O /etc/zabbix/zabbix_agentd/custom_getvalue -o /dev/null

Don’t forget to set execute permission:

chmod 0755 /etc/zabbix/zabbix_agentd/custom_updatescript

Remote updates can be done from Zabbix Server/Proxy using zabbix_get utility:

zabbix_get -s hostserver.yourdomain.com -k custom.updatescript

It’s a contribution from laneovcc:

in my way i config zabbix-agent.conf to include a UserParameter.conf then use system.run[wget http://server/UserParameter.conf -O /path/to/UserParameter.conf ] to update the UserParameter.conf and system.run[services zabbix-agentd restart] to restart the agent

eAccelerator is a free open-source PHP accelerator & optimizer. It increases the performance of PHP scripts by caching them in their compiled state, so that the overhead of compiling is almost completely eliminated. It also optimizes scripts to speed up their execution. eAccelerator typically reduces server load and increases the speed of your PHP code by 1-10 times.

For complete documentation and information, please visit http://eaccelerator.net/

Installation Tips

1. Don’t forget to restart the WebServer daemon (eg. Apache)
2. Source installation requires phpize utility, you can find it on php-devel package
3. Make sure that it’s all fine looking for eAccelerator information on a phpinfo() page

GZip Compression

Many pages on Zabbix outputs very large HTML content, using gzip compression (mod_deflate) is possible to reduce the network traffic significantly. On a simple test I reduced my Overview from 23k to 4k.

This is a cookbook configuration for Apache 2.2:

<Location /zabbix>
# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</Location>

Benchmark Tests using AB (Apache Benchmark)

• with eAccelerator

[root@localhost ~]# ab -c 50 -n 500 http://localhost/zabbix/overview.php
Time taken for tests:   7.363274 seconds

• without eAccelerator

[root@localhost ~]# ab -c 50 -n 500 http://localhost/zabbix/overview.php
Time taken for tests:  15.781082 seconds