Local versus Remote Super Smack
It's possible to run Super Smack against a database on the same system (either through local socket or TCP/IP), or remotely over TCP/IP.For network capable applications, it's normally beneficial to run the benchmarks remotely, so that the load imposed on the database system is only from the database workload itself, and not the load created by running the actual benchmark.
With Super Smack, and in particular with the MySQL database as its target, there are other considerations.
TCP/IP versus Socket
With MySQL, there's about a 25 percent performance gain in terms of queries per second when running through the socket connection versus TCP/IP. You can easily see this performance delta by running Super Smack locally through socket and locally through a local IP address (any local configured IP address, but not 127.0.0.1, Super Smack defaults to a socket connection when the loopback is specified).Network Overload
Another consideration is the type of network load that Super Smack generates. Super Smack creates very simple queries, and as a result the average packet size network traffic generated by Super Smack is extremely small, about 100 bytes.In my test scenario, I was running Super Smack against a dual processor PIII 1 GHz with both Intel 10/100 and a SysKonnect-based Gigabit Ethernet adapters, and the performance numbers were far below what I got when I ran it locally.
Theoretically, without the load of Super Smack running on the local machine, remote results should be better, not worse. I talked with Peter Zaitsev about this, and he suggested looking at the interrupt rate. It turned out the number of interrupts per second was around 15,000. This greatly reduced the ability of my test machine to respond to the queries.
Where I was getting 16,000 queries per second locally, I was getting 8,500 queries per second over the network no matter what operating system I ran. So in the case of Super Smack, it's sometimes actually better to run it locally.
Of course, your mileage may vary.