During the release of ossec v1.0, I posted some performance numbers regarding that version. Even though I know most performance tests do not prove anything per se, I was able to see how many events per second an old PIII box with 512M of ram could handle.
Recently, I finished doing multiple performance improvements to ossec and I decided to re-run this test using the latest available CVS version.
I took the same steps as before, basically sending as many logs as possible to analysisd (main ossec process) and checking /var/ossec/stats/totals to see how many logs it was able to process per second.
I created 5 ossec configurations for logcolletor and initiated one separated daemon for each config. Each process was monitoring one log file. The operating system was OpenBSD 3.9 on an old PIII 700 with 512M of RAM.
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log1.conf
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log2.conf
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log3.conf
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log4.conf
# /var/ossec/bin/ossec-logcollector -c /var/ossec/etc/log5.conf
# tail /var/ossec/logs/ossec.log
2007/01/20 15:14:49 ossec-logcollector(1956): Analyzing file: ‘/data/test-logs/log1′.
2007/01/20 15:14:50 ossec-logcollector(20567): Analyzing file: ‘/data/test-logs/log2′.
2007/01/20 15:14:56 ossec-logcollector(32102): Analyzing file: ‘/data/test-logs/log5′.
2007/01/20 15:14:56 ossec-logcollector: Started (pid: 15448).
# cat /var/ossec/etc/log1.conf
To make it a fair testing, I chose 5 different log formats and wrote a simple script to keep filling the logs as faster as possible.
# cd /data/test-logs
# while [ 1 ]; do ./fill-logs.sh; done
# cat fill-logs.sh
cat PIX-sample >> log1 &
cat accesslog-sample >> log2 &
cat authlog-sample >> log3 &
cat messages-sample >> log4
cat squid-sample >> log5
To my surprise, my changes made a great improvement to the overall ossec performance. Previously, ossec was able to handle in average 1,238,000 events per hour (or 340 per second).
On the latest CVS version, this number jumped to 2,100,000 events per hour (or 600 per second). This is a big jump! Note that I am using real data and that this sample is generating an average of 1,000,000 alerts per hour (rate or 1 alert per 2 events). On a normal environment this value would be much lower.
Summarized stats output from the UI:
Hour Alerts Alerts % Total Total % Hour 14 1,046,427 5.0% 2,140,978 5.2% Hour 15 1,034,108 4.9% 2,142,076 5.2% Hour 16 1,041,571 5.0% 2,096,306 5.1% Hour 17 1,016,219 4.8% 2,048,642 5.0%
Performance values per version:
Version 1.0 1,238,000 per hour 340 per second Version 1.2 2,100,000 per hour 600 per second
If you have some spares systems to execute a similar test, let us know how it goes and we will publish the results.