next up previous contents
Next: Tests and examples Up: MySQL occam- API Previous: Applications   Contents

Benchmark

Operations as INSERT, UPDATE etc. is not of interest to benchmark, because the workload is on the server side. The most used time consuming operation on the client side is to retrieve larger set of rows with the SELECT statement.

The benchmark can be described as follows:

  1. Start timer.
  2. Query the server: INSERT INTO t1 (SELECT * FROM s2) - This will increase the number of rows in t1 by $ \Delta r$
  3. Query the server: SELECT * FROM t1.
  4. Retrieve $ r$ rows by iterating through the result.
  5. Plot $ r$ and timer value. Reset timer.
  6. Go to 1.

In this case $ \Delta r = 10000$ . Both the server and client ran on a Intel Pentium 4 CPU running 3 GHz with 3GB of memory. The machine was running Linux 2.6.12.

As can be seen form figure 3, the difference in performance seems to be linear. This is confirmed by figure 4, where the quotient of the performances is drawn. While not perfectly a straight line, the graph suggests that the overhead of using MoA is not above a factor 1.5 for large data sets, less for small sets.

Building an API on top on another API has a price, but in this case the price is a constant.

Figure 3: MoA(upper line) compared to the C API. The x-axis is the number of rows the SQL query selected ($ *10000$ ) and the y-axis is the time in seconds. The peaks where queries took up to 14 seconds are caused by disk-caching on the server side either by the operating system or the MySQL-server.
\includegraphics{gfx/compare.eps}
Figure 4: The quotient of the performance of $ \frac {MoA}{C\ API}$
\includegraphics{gfx/q.eps} .

next up previous contents
Next: Tests and examples Up: MySQL occam- API Previous: Applications   Contents
Espen Suenson 2006-07-07