Difference between revisions of "PowerDNS OpenDBX Backend/Comparison"
(→Environment) |
(→Conclusion) |
||
| Line 92: | Line 92: | ||
* A PostgreSQL server needs optimized settings before it can perform well | * A PostgreSQL server needs optimized settings before it can perform well | ||
* SQLite is a good alternative for systems without dedicated server | * SQLite is a good alternative for systems without dedicated server | ||
| + | |||
| + | == Optimizations == | ||
| + | |||
| + | I would like to know which settings are needed to get comparable performance figures for PostgreSQL. If you have any suggestions please add them here. | ||
---- | ---- | ||
Back to [[PowerDNS OpenDBX Backend|Overview]] | Back to [[PowerDNS OpenDBX Backend|Overview]] | ||
Revision as of 17:55, 15 October 2005
Contents
Comparison
Environment
The test environment consisted of two different machines both running Debian 3.1 (Sarge) with the latest official patches applied. The following packages were used:
- PowerDNS
- Version 2.9.18-svn (rev 474, 2005-09-03)
- PowerDNS OpenDBX Backend
- Version from 2005-10-15 (more)
- OpenDBX
- Version 0.9.5 (more)
- MySQL
- Version 4.1.11a, including libmysqlclient14
- PostgreSQL
- Version 7.4.7
- SQLite3
- Version 3.2.1
One hosted the PowerDNS server while the other was responsible for running the test suite (queryperf is included in the BIND sources):
- PowerDNS + database server
- VIA C3 533MHz, 256MB RAM
- Benchmark client
- Pentium M 1.5GHz, 512MB RAM
Both machines were connected by a 100MBit network and they were the only ones attached to the hub.
Settings
All test were done with default settings for each database - no further optimizations were applied except if stated otherwise.
To get raw database and backend performance, caching in PowerDNS was switched of generally. Otherwise we would get much higher but false results due to packet caching done by PowerDNS. The "slave-cycle-interval" parameter was set to a value high enough so checking for unfresh slaves had no negative influence:
- cache-ttl=0
- negquery-cache-ttl=0
- query-cache-ttl=0
- recursive-cache-ttl=0
- master=yes
- slave-cycle-interval=300
Test description
The test was based on the records in the example.com zone available in the regression-tests directory of PowerDNS. The zone file was converted by zone2sql (part of the PowerDNS distribution) to a set of SQL queries inserted into the database tables created by specific "create table" statements for each DBMS (available along with the OpenDBX backend sources).
- Lookup speed
- This was tested by running queryperf with a query set of 10000 A records (host-0.example.com to host-9999.example.com) three times in a row. Afterwards these results were averaged to be a good rule of thumb for real live environments (cache hit rate of 60 to 70 percent).
- AXFR speed
- Zone transfer measurement was done by running "host -l example.com <serverip> 1>/dev/null" 100 times in a loop while timing the test. Possible variation of the results due to the operating system should be minimal.
Results
Values for queryperf results are the averaged number of queries per second determined by queryperf.
| Backend | gmysql | OpenDBX mysql |
OpenDBX pgsql |
OpenDBX sqlite3 |
|---|---|---|---|---|
| 1. queryperf | 446 | 454 | 270 | 839 |
| 2. queryperf | 1033 | 1118 | 272 | 848 |
| 3. queryperf | 1033 | 1118 | 272 | 844 |
| Lookup (avg) | 837 | 897 | 271 | 844 |
| AXFR (sec) | 198 | 160 | 271 | 224 |
Conclusion
- The OpenDBX backend outperforms the native MySQL backend by ca. 7 percent in lookups
- OpenDBX backend zone transfers are even 20 percent faster than gmysql backend
- A PostgreSQL server needs optimized settings before it can perform well
- SQLite is a good alternative for systems without dedicated server
Optimizations
I would like to know which settings are needed to get comparable performance figures for PostgreSQL. If you have any suggestions please add them here.
Back to Overview
