-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
load tests and number of concurrent connections #22
Comments
Yep you should put
|
Thanks for your reply, as the jedis client is not threadsafe, I put it at method level, and I did the same for your driver! |
Now its works perfectly, and it's very fast! My conclusions now are that the fastest test is redisscala with blocking code and a big thread pool (but the nb ofthreads will not be infinite...) , then the async redisscala, and then Jedis. Thanks for your help! |
Do you have numbers ? Could you show the "redisscala with blocking code" ? |
Yep, In fact I've relunched the load test and it's quite similar in blocking or not blocking mode (I hope it's readable on github) : blockingredissimulation : STATISTICS async redissimulation : STATISTICS The blocking redis code is very simple : def blockingRedisQuery(q: String) = Action {
val result = Await.result(redis.get(q), 10 seconds).map(_.utf8String).getOrElse("not found")
Ok(result)
} It uses the default thread pool with 500 threads |
Thanks. What was the number with Jedis? |
Also you should avoid doing many map on a Future when you can write it in one map : .map(_.get).map(_.utf8String).map( result =>
Ok(result)
)
.map(r => Ok(r.get.utf8String)) Each time you |
Thanks for the tip, I'll try like this |
I've removed the useless map operation I can put the benchmark on github if you wish |
Yep good idea, it might help other. |
I've pushed everything here : https://github.com/loicdescotte/play-redis-benchmarks |
Hi,
I'm trying to find the best way to use redis from a play framework application, to support a great number of connections and have a good request/second and response time ratio.
I made a few gatling tests : redisscala with async play features, redis-scala in blocking mode (with 'Await') and a bigger play thread pool, and finally Jedis/Sedis (synchronous and blocking).
My results are surprising : I reach the best scalability with the Jedis driver.
With Jedis I can easily reach 500 connected users (500 threads) but with redisscala if I use more than 100 threads to stress the app, it becomes very slow.
My code is very simple :
N.B : I've tried several execution context and thread pool configuration.
Did I miss something?
Thanks
The text was updated successfully, but these errors were encountered: