While connecting from phpredis to redis server its working fine but when we connect to redis through twemproxy throwing below errors :

Fatal error: Uncaught exception 'RedisException' with message 'read error on connection' cacheRedis->get('667663b57db1d84...')

Hi all:

  we are using twemproxy with redis for sharding. There are 8 instances after proxy.When we used 80 clients, and each one sent about 100 ~ 200 commands one time to the proxy at the same time, the proxy's memory increased so quickly, after about 5 mimitues, it could consume 10G and then crashed.
we have used -m 512 and define NC_IOV_MAX to 512, it didn't work.

Could anyone help me fix this issue?Thanks.  

feature request for kqueue support.

$ ./configure
....
configure: error: required sys/epoll.h header file is missing

It would be nice to be able to use twemproxy/nutcracker while doing development on osx, as well as possible deployment onto FreeBSD. Would it be possible to add kqueue support?

hi, @manjuraj, I'm trying to import mget performance by rewrite it like this::

orig:

mget k1 k2 k3 k4 k5 k6 k7 k8 k9 

after rewrite:

mget k1 k3 k6
mget k2 k4 k7
mget k5 k8 k9

this will cost less time on req_done() function calls,

I use this redis-benchmark::

    if (test_is_selected("mget")) { 
#define N 1000
        const char *argv[N+1];
        argv[0] = "MGET";
        for (i = 1; i < N+1; i += 1) {
            argv[i] = "key:__rand_int__";
        }
        len = redisFormatCommandArgv(&cmd,N+1,argv,NULL);
        char tmp[1024];
        sprintf(tmp, "MGET (%d keys)", N);
        benchmark(tmp, cmd,len);
        free(cmd);
    }

here is the benchmark result on my laptop:

1000 keys mget::

ning@ning-laptop:~/idning-github/redis-mgr$ redis-benchmark -n 1000 -t mget -p 4001 -r 100000000
====== MGET (1000 keys) ======
  1000 requests completed in 21.66 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 1268 milliseconds
46.18 requests per second

ning@ning-laptop:~/idning-github/redis-mgr$ redis-benchmark -n 1000 -t mget -p 4000 -r 100000000
====== MGET (1000 keys) ======
  1000 requests completed in 1.64 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 102 milliseconds
611.25 requests per second  (improved )

(benchmark against redis got 1292 requests per second)

100keys mget::

ning@ning-laptop:~/idning-github/redis-mgr$ redis-benchmark -n 10000 -t mget -p 4001 -r 100000000
====== MGET (100 keys) ======
  10000 requests completed in 8.57 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 56 milliseconds
1166.59 requests per second

ning@ning-laptop:~/idning-github/redis-mgr$ redis-benchmark -n 10000 -t mget -p 4000 -r 100000000
====== MGET (100 keys) ======
  10000 requests completed in 1.88 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 17 milliseconds
5316.32 requests per second  (improved )

(benchmark against redis got 11668.61 requests per second)

the performance is about 5x-10x (about 1/2 of redis instance) @neeleshkorade will be happy to see this result (https://github.com/twitter/twemproxy/issues/158)

I need a detail benchmark later. and I need your advise.

Please ignore config in this message, there's a second message from me and it has better explanation of what needs to be configured to reproduce the issue.

"redis-cli -h <HOST> MGET {a}1 {a}1" - works fine
"redis-cli -h <HOST> MGET {a}1 {b}1" - produces the following:

Error: Server closed the connection

Config file:

## core Twemproxy config
redis1:
  listen: 0.0.0.0:6379
  database: 4
  redis: true
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  timeout: 400
  server_retry_timeout: 20000
  server_failure_limit: 3
  servers:
   - xxx:yyy:1
   - xxx:zzz:1
...

Note: hash_tag parameter is not specified!

The issue can't be reproduced on v0.3.0.

Let me know if I need to provide any more info.

Thank you in advance!

http://stackoverflow.com/questions/33487641/twitter-twemproxy-retry-not-working-as-expected

Wondering if anyone had insight into this? I even tried to sleep and create a new instance and I can't get it to hit a known good cache node. I set server retry to 1, and in code have retries set to 2 per the docs ( retries have to be > server retry).

We are seeing a few issues that I was hoping someone could help me resolve or point me in the right direction.

1. During high loads, we are seeing a lot of backup in the out_queue_bytes. On normal traffic loads, this is 0.

Example (sometimes goes into 2k/3k range as well): "out_queue_bytes": 33 "out_queue_bytes": 91 "out_queue_bytes": 29 "out_queue_bytes": 29 "out_queue_bytes": 174

In addition, it shows that our time spent in memcache goes up from 400 ms to 1000-2000 ms. This seriously affects our application.

2. auto eject also seems to not work as expected. Server goes down and our app freaks out - saying it cannot access a memcache server.

here is an example of a config:

web: listen: /var/run/nutcracker/web.sock 0777 auto_eject_hosts: true distribution: ketama hash: one_at_a_time backlog: 65536 server_connections: 16 server_failure_limit: 3 server_retry_timeout: 30000 servers:

• 1.2.3.4:11211:1
• 1.2.3.5:11211:1
• 1.2.3.6:11211:1 timeout: 2000

somaxconn = 128

What we tried and didn't help.

1. mbuf to 512
2. server connection from 1 to 200

Thank you for any guidance on this problem.

This issue is a follow up for #386 , while descovering logs we found that when closing connect to Redis twemproxy marks this operation as error, is this a correct behaviour or we missed anything?

[2015-10-01 11:56:32.773] nc_epoll.c:254 epoll 0001 triggered on conn 0x24d5740
[2015-10-01 11:56:32.773] nc_core.c:324 event 00FF on c 654
[2015-10-01 11:56:32.773] nc_util.c:228 malloc(32) at 0x24d66b0 @ nc_array.c:29
[2015-10-01 11:56:32.773] nc_util.c:228 malloc(16) at 0x24d66e0 @ nc_array.c:34
[2015-10-01 11:56:32.773] nc_message.c:319 get msg 0x24d64f0 id 923356 request 1 owner sd 654
[2015-10-01 11:56:32.773] nc_mbuf.c:99 get mbuf 0x24ec1d0
[2015-10-01 11:56:32.773] nc_mbuf.c:182 insert mbuf 0x24ec1d0 len 0
[2015-10-01 11:56:32.773] nc_connection.c:362 recv on sd 654 6 of 976
[2015-10-01 11:56:32.773] nc_redis.c:1643 parsed bad req 923356 res 1 type 0 state 0
00000000  51 55 49 54 0d 0a                                  |QUIT..|
[2015-10-01 11:56:32.773] nc_core.c:198 recv on c 654 failed: Invalid argument
[2015-10-01 11:56:32.773] nc_core.c:237 close c 654 '127.0.0.1:47266' on event 00FF eof 0 done 0 rb 28175 sb 50818: Invalid argument
[2015-10-01 11:56:32.773] nc_stats.c:1033 metric 'client_connections' in pool 1
[2015-10-01 11:56:32.773] nc_stats.c:1065 decr field 'client_connections' to -1
[2015-10-01 11:56:32.773] nc_stats.c:1033 metric 'client_err' in pool 1
[2015-10-01 11:56:32.773] nc_stats.c:1050 incr field 'client_err' to 7
[2015-10-01 11:56:32.773] nc_client.c:147 close c 654 discarding pending req 923356 len 6 type 0
[2015-10-01 11:56:32.773] nc_message.c:370 put msg 0x24d64f0 id 923356
[2015-10-01 11:56:32.773] nc_mbuf.c:191 remove mbuf 0x24ec1d0 len 6
[2015-10-01 11:56:32.773] nc_mbuf.c:121 put mbuf 0x24ec1d0 len 6
[2015-10-01 11:56:32.773] nc_util.c:274 free(0x24d66e0) @ nc_array.c:77
[2015-10-01 11:56:32.773] nc_util.c:274 free(0x24d66b0) @ nc_array.c:51

Could this be a reason because we close connection on Redis (twemproxy) with client.close() thus it triggers QUIT command that is send to twemproxy and twemproxy send it to Redis and this situation occurs?

//cc @manjuraj

This patch supports redis AUTH Command, but not as User Command. In req_forward, this patch add auth packet in Request Queue when redis and redis_auth's length is not 0.

so. nc_connection has first flag.

and add redis_auth keyword to conf file to use redis auth.

leaf:
  listen: 127.0.0.1:22121
  hash: fnv1a_64
  redis: true
  redis_auth: testpass
  distribution: ketama
  auto_eject_hosts: true
  server_retry_timeout: 2000
  server_failure_limit: 1
  servers:
   - 127.0.0.1:3001:1 server1
   - 127.0.0.1:3002:1 server2

add changes

1. support user's auth command. -> twemproxy filters client's auth command and status. and, if client is not admitted, then return -ERR

Half of this is the MD5 replacement as discussed in #120. The code is OpenSSL-compatible which is in turn RSA-compatible (even the function prototypes are similar) so this shouldn't functionally change the code. A simple test case seemed to produce the same output, it is however untested in a twemproxy environment.

The other part is the removal of the embedded yaml & contrib/. The commit message has all the reasoning behind this, let me know if you need additional clarifications on why I needed this.

(while the two may seem unrelated with each other, they're the only blockers I found on my way to packaging & inclusion in Debian main)

Found a strange bug when was trying to run twemproxy with cluster of elasticache (Amazon cloud memcached) servers. Amazon use CNAMEs as entry points for elasticache servers and twemproxy could connect to the backend memcached on start, but couldn't send any request to them. If I use "direct" hostnames for the backend servers, all requests are ok.

user@localhost:~$ telnet my.proxy.server 11311
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
get foo
SERVER_ERROR Connection timed out
^]

twemproxy config:

staging-cache:
  listen: 0.0.0.0:11311
  hash: fnv1a_64
  distribution: ketama
  timeout: 10000
  backlog: 1024
  preconnect: true
  auto_eject_hosts: true
  server_retry_timeout: 30000
  server_failure_limit: 3
  servers:
   - myserver.0001.use1.cache.amazonaws.com:11211:1
   - myserver.0002.use1.cache.amazonaws.com:11211:1
   - myserver.0003.use1.cache.amazonaws.com:11211:1
   - myserver.0004.use1.cache.amazonaws.com:11211:1

twemproxy was running as

[email protected]:~$ nutcracker -c /etc/nutcracker.yml -v 11

Here is part of twemproxy log: http://pastebin.com/DTE8gAva

When I modified servers section:

  servers:
   - ec2-xx-xx-xx-xx.compute-1.amazonaws.com:11211:1
   - ec2-xx-xx-xx-xx.compute-1.amazonaws.com:11211:1
   - ec2-xx-xx-xx-xx.compute-1.amazonaws.com:11211:1
   - ec2-xx-xx-xx-xx.compute-1.amazonaws.com:11211:1

I received response:

user@localhost:~$ telnet my.proxy.server 11311
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
get foo
END
^]

And, of course, *.cache.amazonaws.com could be resolved from instance where twemproxy is running:

[email protected]:~$ host myserver.0002.use1.cache.amazonaws.com
myserver.0002.use1.cache.amazonaws.com is an alias for ec2-xx-xx-xx-xx.compute-1.amazonaws.com.
ec2-xx-xx-xx-xx.compute-1.amazonaws.com has address xx-xx-xx-xx

P.S. Oct 26 code snapshot was used; Ubuntu 12.04.1 x86_64

Problem

redis script command not support.

Solution

Send the script command to all Redis servers for execution, and get one of the results and return it to the user client.

Result

> script load "return redis.call('hset',KEYS[1],KEYS[1],KEYS[1])"
"dbbae75a09f1390aaf069fb60e951ec23cab7a15"
> script exists dbbae75a09f1390aaf069fb60e951ec23cab7a15
1) (integer) 1

Hello, twemprodxy reported some error logs: NC_ request. c: 417 EOF C 249 discarding incomplete req 33270941169 len 4096, but I didn't understand what the error was, and then the error was reported. At the same time, the connection timeout occurred in the program at the same time, and the error occurred in the twoproxy at the same time_ The connection also fluctuates, so I want to find out where the problem is with the twoproxy.

For the development of one project, we wanted to perform some security checks on the configuration file. Is there any way to upload a configuration file through the web browser? If not through a web browser, then what is another way?

Amy suggestions?

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like A clear and concise description of what you want to happen.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.