Home
 

Number of Objects

Number of Objects

This section deals with the influence of the number of objects in a server.

Method

First, we create a number of objects in the server. Then we iterate through calling them.

        ...
        long t1 = 0;
        long t2 = 0;
        if (method.equals("sync_VV")) {
            RTT[] rtts = new RTT[objects];

            for (int i=0; i<objects; i++) {
                rtts[i] = factory.createRTT();
            }

            t1 = System.currentTimeMillis();
            for (int i=0; i<loops; i++) {
                // rotate through objects
                for (int j=0; j<objects; j++) {
                    rtts[j].sync_VV();  
                }
            }
            t2 = System.currentTimeMillis();
        }
        ...
        System.out.println(t2-t1);

Figure 4-10. ObjClient.java

Results

The standard ([5]) specifies the following for object references:

In general, GIOP profiles include at least these three elements:The version number of the transport-specific protocol specification that the server supports.The address of an endpoint for the transport protocol being used.An opaque datum (an object_key, in the form of an octet sequence) used exclusively by the agent at the specified endpoint address to identify the object.

Important is that the server may freely specify the object key, which must only be understood by him to access the object.

A simple implementation might even take the pointer to the object as the object key, thus nullify the influence of accessing a big number of it (cf the section called Number of Methods).

My findings are shown below.

Figure 4-11. Number of Objects RTT (1-1000)

Figure 4-11 shows some interesting instability between 1 and 100 objects. I initially thought that this may be due to some race condition, but Figure 4-12 seems to proof that wrong.

Figure 4-12. Number of Objects RTT (1-1000, 10ms sleep)

Even with a sleep of 10ms between each call (which is not included in the data) we see the anomaly. This effect is subject to further explorations.

Figure 4-13. Number of Objects RTT (1000-44000)[1]

Figure 4-13 shows the stress test. For more than 40000 objects the round trip time increases substantially. Between 45500 and 46000 objects the server ran out of memory.

In summary, the number of objects in the server had no obvious influence to the round trip time.

Note: The tests only include the round trip time. However, the server needs to be contacted for the creation of the objects too. For example, it took approximately 2 server minutes and 1 client minute to create 25000 objects (which is consistent with calling the server that many times). This is, as mentioned, not measured in our tests.

Notes

[1][1]

Usually, the server is called 1000 times for each test. In order to call each object at least once, I increased the number for this test to 50000 and normalized the results back to 1000 calls.