roc230 / spymemcached

Automatically exported from code.google.com/p/spymemcached
0 stars 0 forks source link

Timeouts in set() due to synchronized java.security.Provider.getService() call #217

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
We are noticing large timeouts using net.spy.memcached.MemcachedClient.set(). 
In a small subset of all test cases, the inherent call to Provider.getService() 
takes up 56 ms.

Specifically, of 10,000 test runs with 100 parallel threads, 95% calls to 
getServices()/getService() finish in 0.5 ms, 96% finish in 1ms and 99% finish 
in 10ms:

public void run() {
    try {
        while (counter < 100) {
            MessageDigest md5 = MessageDigest.getInstance("MD5");
            new SecureRandom().toString();

            Thread.sleep(10);
        }
    } catch (Exception e) {
        e.printStackTrace();
        System.exit(0);
    }
}

public static void main(String[] args) throws InterruptedException {
    for(int i = 0; i < 100; ++i) {
        new MainThread(i);
    }
}

As we are using Memcached in a large scale environment, the 1% of cases that 
take longer than 10ms pose a significant problem. 

We understand that this issue is not specific to Memcached, but would like to 
suggest that the client reuses the provider obtained in 
net.spy.memcached.HashAlgorithm.computeMd5:130, instead of obtaining a new 
provider for every set() call.

We are using version 2.5.3.

Original issue reported on code.google.com by sebastia...@apple.com on 7 Nov 2011 at 10:29

GoogleCodeExporter commented 9 years ago
Makes sense, thanks for raising it.

Original comment by ingen...@gmail.com on 22 Nov 2011 at 4:32