search

h0x91b / redis-fast-driver

78 stars 13 forks source link

How to improve performance #27

Closed sirganya closed 4 years ago

sirganya commented 5 years ago

Hi,

I'm trying to get the maximum performance from uWebsockets + Redis. I'm not getting a difference in benchmark times writing and reading a small value between Redis-fast-driver and ioredis. I assume I'm creating a bottle neck in my code. Can you guide me to the best way to set up such a server.

Currently I have a function that calls fast-redis-driver and gets a record. uWebsockets calls that function every time a message is received. I'm using Tsung to test the server from another EC2 instance. The uWebsockets + Redis server is running on an a1.medium instance.

Any insights would be much appreciated.

h0x91b commented 5 years ago

Hi, ioredis is also a very fast library, and I am pretty sure that you are not utilizing this driver or ioredis driver for 100%.

The best performance using this driver you will get only when using bulks, e.g. if you sending/receiving 10 or 100 or even 1000 (bigger are better) commands in a row otherwise the async way will not give you any improvement. If you sending 1 command each time, async will work exactly as sync driver or even slower...

Websocket also isn't so fast, its pretty expensive to CPU... And one last thing - JS itself, if JS code not optimized it can be slow as hell. But usually, the network is more expensive than code.

If you can post here your code I can help you optimize it for better performance.

sirganya commented 5 years ago

Hi,

I set up 2 EC2 instances in the same zone. One creates 20,000 websocket connections and each connection sends 100 messages. Using uWebsockets and it's C++ bindings the instance handled it easily. Using JSON.parse on each message seems to add a significant load. Fast-driver does not add much overhead. I created a repo with some unscientific results here.

https://github.com/sirganya/uws-rfd

There is overhead in the testing suite Tsung as it has to create so many users and messages so the figures are not to be taken as representative of real performance. It was a way for me to see which of the stages was adding overhead.

I'd be interested to hear your thoughts. Thanks.