[JAVA-864] Lookups in replica set take 20% of CPU time Created: 05/Jul/13  Updated: 11/Sep/19  Resolved: 18/Jul/13

Status: Closed
Project: Java Driver
Component/s: Connection Management
Affects Version/s: 2.11.2
Fix Version/s: None

Type: Task Priority: Critical - P2
Reporter: Nic Cottrell (Personal) Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 6


Attachments: PNG File Screen Shot 2013-07-05 at 1.26.08 PM.png    

 Description   

We have a replica set with 2 nodes and a arbiter. We originally had the java driver configured using the hostnames and about 40% of the CPU time reported by JProfiler was getByName. I've now configured so that it's the IP address specified in the ServerAddress()... but it's still 20% via ServerAddress.updateInetAddress. Is it perhaps because the config of the replica set itself it still specified with hostnames not IP addresses?

I saw a mention of configuring a cache timeout for mapping, but I couldn't find it in the docs. Also, I saw that in the 3.x Java driver that caching is going to be removed completely. What am I missing? How can this take so much CPU?



 Comments   
Comment by Jeffrey Yemin [ 18/Jul/13 ]

Closing this now but please open a new issue if you want to request a feature enhancement.

Comment by Jeffrey Yemin [ 18/Jul/13 ]

I don't think the driver should be getting involved. There are already JVM settings available that are under the user's control that can influence the caching behavior (see http://stackoverflow.com/questions/12099526/setting-java-dns-cache-ttl), so anything that the driver does just adds another layer, which is something that has confused many of our users.

Comment by Nic Cottrell (Personal) [ 18/Jul/13 ]

Looks like I have caching of one minute (this applies to both hostnames) and decent results after the first:

{{
1: 1009.395ms
2: 0.081ms
3: 0.081ms
4: 0.063ms
5: 0.084ms
6: 0.079ms
7: 0.05ms
8: 0.042ms
9: 0.078ms
10: 0.083ms
11: 0.059ms
12: 0.064ms
13: 0.053ms
14: 0.066ms
15: 0.062ms
16: 0.097ms
17: 0.069ms
18: 0.048ms
19: 0.079ms
20: 0.053ms
21: 0.052ms
22: 0.074ms
23: 0.067ms
24: 0.048ms
25: 0.071ms
26: 0.066ms
27: 0.055ms
28: 0.062ms
29: 0.063ms
30: 0.066ms
31: 0.639ms
32: 0.056ms
33: 0.072ms
34: 0.062ms
35: 0.039ms
36: 0.046ms
37: 0.039ms
38: 0.051ms
39: 0.084ms
40: 0.082ms
41: 0.079ms
42: 0.065ms
43: 0.074ms
44: 0.065ms
45: 0.042ms
46: 0.035ms
47: 0.063ms
48: 0.065ms
49: 0.061ms
50: 0.062ms
51: 0.047ms
52: 0.04ms
53: 0.051ms
54: 0.07ms
55: 0.046ms
56: 0.034ms
57: 0.113ms
58: 0.078ms
59: 0.041ms
60: 0.045ms
61: 1004.906ms
62: 0.042ms
63: 0.054ms
64: 0.052ms
}}

Is it worth increasing the caching? Will risk making it hard to move servers around if a hosting environment goes down....

Comment by Jeffrey Yemin [ 08/Jul/13 ]

Try running a program like this:

    public static void main(String[] args) throws UnknownHostException, InterruptedException {
        for (int i = 1; i < 1000; i++) {
            long start = System.nanoTime();
            InetAddress.getByName("www.google.com");
            System.out.println(i + ": " + (System.nanoTime() - start) / 1000000.0 + "ms");
            Thread.sleep(1000);
        }
    }

substituting your server's hostname in the call to InetAddress.getByName. When I run this I get very reasonable response times of under 10ms for the first call and under 1 ms for subsequent calls, showing the effect of the JVMs built-in DNS cache.

Generated at Thu Feb 08 08:53:15 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.