0

The goal is to measure the performance of single queries (Insert, Delate, Update etc ...) that my Java application runs on different Mongo databases (same collections but differently structured documents). The queries (executed in java) are the same, for each type of operation (insert, update, etc.), on each databases.

The solution I am adopting is the measurement of the time that elapses from the beginning of the method to the end.

For example, I will show you how I am calculating the timing of Insert operations:

 long total_ms = 0;     
    
    for (int i = 0; i < number_of_insert; i++) {
        
        long start = System.nanoTime();
        
        mongo_export.Insert(new Document().put("Name", "Sam"));  //Insert Function
        
        long end = System.nanoTime();
        
        total_ms = end - start;
        
    }
    
    total_ms = TimeUnit.NANOSECONDS.toMillis(total_ms);

I use this solution because I cannot use MongoDB's "Database Profiler" because being "small" operations, milliseconds are either 1 or 0, and therefore I cannot use nanoseconds as they are not present in the Profiler (the same for the Explain in queue to queries).

The problem is that trying, for example N times 1000 insertions in the 3 databases, sequentially, the times (especially of the first 2 attempts) are very different from each other. Example:

/**
Time 1 is for DB 1, Time 2 for DB 2, Time3 for DB 3.

Time 1: 1055 ms
Time 2: 887 ms
Time 3: 1177 ms

Time 1: 880 ms
Time 2: 783 ms
Time 3: 882 ms

Time 1: 609 ms
Time 2: 603 ms
Time 3: 938 ms

Time 1: 623 ms
Time 2: 577 ms
Time 3: 698 ms

Time 1: 593 ms
Time 2: 590 ms
Time 3: 724 ms

Time 1: 604 ms
Time 2: 611 ms
Time 3: 790 ms

*/

What is the reason for this? Why do the times differ so clearly?

Do you know other methods to calculate these times, without using Mongo's Profiler or the various "Timestamps"?

Andrelan
  • 65
  • 6
  • 1
    Could be due to the JITter (just-in-time compiler) in the JVM not having done its thing yet, so your code is less optimized the first few times. Could also be because MongoDB is accessing disk the first few times, but has everything cached in RAM afterwards. A good way to get reliable results is to profile multiple times, like you did, and wait for it to stabilize. – Thomas Sep 09 '20 at 13:34
  • 1
    See https://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java for some ideas. Maybe using a framework like JMH is the logical next step for you – GhostCat Sep 09 '20 at 13:55

0 Answers0