jeremyxu2010

我用redis-benchmark压测时也遇到这个问题了 压测命令： ```bash # redis-benchmark -h 9.77.34.64 -p 32149 -c 50 -d 3 -n 10000000 -r 1048576 Writing to socket: Connection timed out All clients disconnected... aborting. ``` 查了下predixy的日志，里有一堆这类的报错： ```bash...

> 看看压测时机器负载情况，是不是网卡打满了 从两边的系统负载来看，并没有发现网卡被打满的情况 @fortrue 压测端： ```bash # top -n 1 top - 10:03:30 up 7 days, 15 min, 4 users, load average: 0.33, 0.40, 0.30 Tasks: 155 total, 1 running,...

@fortrue 花时间仔细查了一下，终于查明原因了，可以忽略该问题了 因为我是使用[redis-operator](https://github.com/spotahome/redis-operator)将redis集群部署在kubernetes中的，在predixy配置文件里配置的`rfs-cluster-name:26379`，在测试时我尝试将redis集群的某些pod删除掉，这样redis集群中某些节点的ip发生变化了，因此predixy的日志里会不停地打印如下报错信息： ``` 2019-05-21 09:27:05.720599 N Handler.cpp:212 h 3 remove c 172.20.2.0:46783 19 with status 4 EventError 2019-05-21 09:27:05.720704 N Handler.cpp:212 h 1 remove c 172.20.2.0:46802 15 with status...

这也遇到过这个报错，最后查明原因是redis实例的地址发生变化了 `RefreshInterval: predixy会周期性的请求redis sentinel以获取最新的集群信息，该参数以秒为单位指定刷新周期，不指定的话为1秒` 这个配置貌似无效，并没有定期去请求获取最新的集群信息 @fortrue

> 1、如果你能找/写出一个性能比predixy更好的redis代理，告诉我，我去学习改进。在高并发情况下通过predixy来把后面redis cpu打满跟你直接连接redis打满，redis所能提供的吞吐量前者远远高于后者，看wiki https://github.com/joyieldInc/predixy/wiki/%E4%B8%8E%E7%9B%B4%E8%BF%9Eredis%E5%AF%B9%E6%AF%94benchmark > 2、现在可以通过命令行参数传递来实现 @fortrue 唐突了 1、 目前predixy确实是我在世面上能找到的性能最优异的redis代理，给你点个赞！！！ 我这里会给我的使用方说明一下，给他们两个选择： 1）使用predixy代理透明地访问后端redis集群，这个方案客户端很干净，但要承担predixy的资源消耗 2）客户端直接访问后端redis集群，客户端需要配置redis集群bootstrap地址列表，同时自行处理move等redis集群特有的指令，这个方案客户端要处理的工作较多，但不需要承担predixy的资源消耗 2个选择各有利弊，看使用方的场景了。 2、命令行参数传递`WorkerThreads`参数的功能后面我试一下，应该能解决我遇到的问题。

我也遇到这个问题，我们是将predixy部署到容器的，在predixy的配置文件里配置的是redis集群的service name(相当于dns名)，当service name指向的service ip发生变化时，predixy并没有感知，感下面这个配置并没有发生的作用 `RefreshInterval: predixy会周期性的请求redis sentinel以获取最新的集群信息，该参数以秒为单位指定刷新周期，不指定的话为1秒` @fortrue

I notice gophercloud's openstack library only supports v2/v3 authorize method. But I configure the swift access **with ceph only(without keystone)**, ceph **only support v1 authorize** method. @jdolitsky @gmauleon `https://github.com/gophercloud/gophercloud/blob/master/openstack/client.go` ```go...

@jdolitsky ceph itself (without keystone) only support v1 authorize method，so Can chartmuseum support ceph's swift or s3?

@jdolitsky I tried ceph object storage via S3, it's OK! But docker's registry CAN NOT support ceph's object storage via S3. See [here](https://github.com/docker/distribution/issues/2189), in this post, someone said docker registry...

很抱歉，由于目前在忙别的工作，确实很久没有更新该client库了。 `servicecomb-pack`项目的向前兼容做得很好，我试着跑了下测试用例，暂时还是可正常工作的。 从上述报错信息来看，应该是使用`saga.DecorateSagaStartMethod`或`saga.DecorateCompensableMethod`装饰的方法返回值个数不正确，被装饰的方法签名必须与声明的装饰方法签名相同，见[参考测试用例](https://github.com/jeremyxu2010/matrix-saga-go/blob/master/test/sagatx_demo.go)。 你也可以按以下指引先跑一遍测试用例看看 ```bash # 克隆并编译servicecomb-pack项目 $ git clone https://github.com/apache/servicecomb-pack.git $ cd servicecomb-pack $ mvn clean install -P 'mysql,!docker' -DskipTests=true # 初始化alpha-server依赖的数据库 $ mysql -uroot -proot -h127.0.0.1 -P3306 MariaDB...