вопрос о производительности jredis - PullRequest
1 голос
/ 18 января 2011

Я хочу использовать Redis RPUSH и LPOP в качестве очереди сообщений в моем проекте, и теперь я столкнулся с проблемой производительности:

Когда я просто запускаю случайный Double Nubmer, используя Jredis, с одним потоком из моего java-клиента, я замечаю, что во всем это всего 4000 запросов / сек, что намного ниже, чем я ожидал.

Вот моя конфигурация redis:

Тайм-аут 300 сохранить 900 1 сохранить 300 10 сохранить 60 10000

без ограничения памяти с памятью 4G.

и фрагмент кода Java:

    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"+100000/seconds+"request/second");

Есть ли другой java-клиент лучше, чем jredis? Спасибо за вашу помощь!

Ответы [ 3 ]

2 голосов
/ 19 января 2011

Попробуйте некоторые тесты без Java - клиент, включенный в Redis, должен делать. В клиенте java могут быть некоторые издержки, но ваша проблема, скорее всего, связана с сетевым подключением. Сеть может быть в состоянии быстро передавать большие объемы данных, но большое количество маленьких ключей дает вам худшую производительность для издержек и задержек.

В вашем тесте каждая операция выполняется синхронно, ожидая ответа перед отправкой следующей команды. И клиент, и сервер могут обрабатывать больше при обычном использовании - запустите другой поток / соединение, и вы, вероятно, получите намного лучшие цифры.

1 голос
/ 07 декабря 2011

Как правило, клиент накладывает только накладные расходы на пространство (например, память) и оптимизируется для обеспечения высокой производительности.

Однопоточный синхронный запрос / ответ ограничен (независимо от того, каким клиентом вы пользуетесь, какой язык вы используете) со скоростью около 10-15 К / с. Это потому, что вы используете крошечную долю MTU и еще больше блокируете ожидание ответа.

В режиме синхронизации RTT одного Req / Rep разделит окно на 1 с. Таким образом, если RTT, скажем, 1 мс, вы можете разместить только 1 КБ запросов / ответов за одну секунду. Это просто физика, и с этим ничего не поделаешь. :) Ваши 4k Req / s подразумевают, что вы получаете RTT за 0,25 мс (в среднем).

Но JRedis также предоставляет асинхронные конвейеры (что идеально подходит для вашего случая использования). Я предлагаю вам использовать это:

При использовании асинхронного конвейера достаточно просто разделить 100 МБ / MTU_IN_BITS, чтобы получить представление об идеальной идеальной скорости полного насыщения канала (если полезная нагрузка вашего запроса меньше, чем MTU. (Вы может приблизиться к этому пределу с помощью JRedis Pipelines.) Опять же, обратите внимание, что при конвейерной обработке сам размер сообщения определяет пропускную способность request / s , но, очевидно, пропускная способность byte ограничена сетью.

0 голосов
/ 19 января 2011

Полный список клиентов Redis можно найти по адресу http://redis.io/clients

. Для вашего ответа есть два разных клиента (из 3 всего):

  1. JDBC-Redis(http://code.google.com/p/jdbc-redis)
  2. Джедай (http://github.com/xetorthio/jedis)
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...