Database and application communication performance for benchmarking & embedded databases

Question

In embedded databases, are the queries and the replies made through sockets as when using a database with a driver? Which is better in terms of performance?

What is the best way in general to access a database in terms of performance for a benchmarking?

Answer 1

It depends on the actual product on how the communication between the application and the database is handled. I am very familiar with one particular product that is marketed in the "embedded" space because I am a developer on that database product. It is not alone in that space certainly so this information applies to other embedded databases as well. This particular product includes both a client/server version as well as an in-process version. The client/server version uses sockets for communications when the client and server process are on separate machines and it uses IPC via shared memory when running on the same physical machine. The in-process version runs, as you might guess, in the process space of the client application as a DLL (Windows) or a shared object (Linux). So that's just one example, and it is not unique. So, basically, you would need to read the documentation of the product you are using to determine the specific answer for your case.

As to which is better in terms of performance, it is not a simple question to answer. It depends on many factors. A single request from the client to the database server will typically be faster in terms of the call itself for an in-process database. But some IPC mechanisms are almost as fast. And unless billions of "small/fast" requests are made, it may hardly be a factor in overall performance. And there are other issues to consider. If the database is running as a separate process, it may be faster overall because it may do more aggressive caching, take advantage of multiple cores, be able to run as a service, possibly run as a 64-bit process while the client is 32-bit, etc. Plus there is stability to consider. If the database is a separate process it can, for example, avoid corruption problems if the client application crashes while an in-process version may be more affected by the stability of the client.

For benchmarking, the best thing is to test with the type of environment and queries that the application will be using. A database may have the amazing numbers in some set of TPC tests, but if the target application is for a single user and is doing very simple queries and updates, then it probably doesn't matter what its TPC numbers are. So, if possible, perform tests that will mimic your actual environment as closely as possible. This is, of course, easier said than done in a lot of cases, but it is a good way to start thinking about it.