I want to use Redis RPUSH and LPOP as message queue in my project, and now I encountered a performance problem:

When I simply rpush a random Double nubmer using Jredis with a single thread from my java client, I notice that the throughout is just 4000 request/secs, which is much lower than what I expected.

Here is my redis Configuration:

timeout 300 save 900 1 save 300 10 save 60 10000

no memory limit with 4G memory.

and Java snippet:

    jredis = new JRedisClient(ip,6379);
    long bytesTransfered = 0;
    Date start = new Date();
    for(int i = 0; i < 100000 ; i ++){
        String s = Math.random()+"";
        jredis.lpush("testqueue", s);
        bytesTransfered += s.length();
    }
    Date end = new Date();
    double seconds = (end.getTime() - start.getTime())/1000f;
    System.out.println("REDIS:\t"+  (bytesTransfered/seconds)+"bytes/second,\t"开发者_StackOverflow中文版;+100000/seconds+"request/second");

Is there any other java client better than jredis? Thanks for your help!.

Try some tests without java - the client included with redis should do. There may be some overhead in the java client, but your issue is most likely the network connection. The network may be able to transfer large amounts of data fast, but lots of small keys gets you worst case performance for overhead and latency.

Your test has each operation happening synchronously, waiting for a response before sending the next command. Both client and server can handle more in normal usage - start another thread/connection and you will probably get much better numbers.

In general, the client only imposes space overheads (e.g. memory) and is optimized for high performance.

Single threaded synchronous request/reply is capped (regardless of what client you use, what language you use) at around 10-15K/sec. That is because you are using a tiny fraction of an MTU, and are further blocking waiting for the response.

In sync mode, the RTT of a single Req/Rep will partition the 1sec window. So if the RTT is say 1ms, you can only fit 1K request/replies in one sec. This is simply physics and there is nothing you can do about it. :) Your 4k Req/s implies that you are getting a 0.25 ms RTT (avg).

But, JRedis also provides you asynchronous Pipelines (which is ideal for your usecase). I suggest you use that:

With asynch pipeline, it is a simple matter of dividing 100mb / MTU_IN_BITS to get an idea of the ideal fully saturated link req/s rate (if your request payload is smaller than the MTU. (You can approach this limit with JRedis Pipelines.) Again, note that with pipelining, the message size itself determines the request/s throughput, but obviously byte throughput is constrained by network.

A full list of Redis clients can be found at http://redis.io/clients

For your answer, there are two different clients (out of 3 total):

1. JDBC-Redis (http://code.google.com/p/jdbc-redis)
2. Jedis (http://github.com/xetorthio/jedis)