GreyDNS Benchmarkergebnisse

Die Werte variieren je nach Aufruf des Benchmarks, die Tabelle dient nur zur Orientierung.

Man erkennt (so denke ich), dass der Client den Server nicht ausreizt, weder über das Loopback noch über eine 100 MBit-Leitung. Mein iBook ist als Client mit zwei parallelen Benchmarks schon bei Volllast.
Einen schnelleren Benchmark als dig -f Datei habe ich leider auch nicht gefunden.

Perl-Implementierung

Client	Medium	Server	Anfragen	Zeit	Anfragen/s	ca. %CPU (Server)
Apple iBook G4 PPC, 1.3 GHz	loopback	Apple iBook G4 PPC, 1.3 GHz	10.000	6 s	1666
	loopback	Apple iBook G4 PPC, 1.3 GHz	100.000	72 s	1388
	100 ME	Intel Pentium 3, 600 MHz	10.000	7-9 s	1111-1400	47%
	100 ME	Intel Pentium 3, 600 MHz	100.000	71-85 s	1176-1408	47%
	100 ME	Intel Pentium 4, 2.2 GHz	10.000	5 s	2000	33%
	100 ME	Intel Pentium 4, 2.2 GHz	100.000	47 s	2127	33%
Intel Pentium 4, 2.2 GHz	100 ME	Apple iBook G4 PPC, 1.3 GHz	10.000	6 s	1666	60%
Intel Pentium 4, 2.2 GHz	100 ME	Apple iBook G4 PPC, 1.3 GHz	100.000	46-76 s	1315-2173	60%
Apple iBook G4 PPC, 1.3 GHz (2 bench parallel)	100 ME	Intel Pentium 4, 2.2 GHz	10.000	5-7 s	1400-2000	40%
Apple iBook G4 PPC, 1.3 GHz (2 bench parallel)	100 ME	Intel Pentium 4, 2.2 GHz	100.000	42-79 s	1265-1923	40%

C-Implementierung

Die Datenbank ist in einem shared memory Dateisystem (tmpfs) untergebracht.

Client	Medium	Server	Anfragen	Zeit	Anfragen/s	ca. %CPU (Server)
Apple iBook G4 PPC, 1.3 GHz	loopback	Apple iBook G4 PPC, 1.3 GHz	100.000	32.23 s	3102.5	20%

valgrind

Während der kompletten Entwicklung habe ich konsequent mit valgrind nach Speicherfehlern gesucht.
Das empfehle ich jedem, der mit C entwickelt.

==5088== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5088== malloc/free: 2,047,593 allocs, 2,047,593 frees, 78,818,678 bytes allocated.
==5088== For counts of detected errors, rerun with: -v
==5088== All heap blocks were freed -- no leaks are possible.