WebSocket MicroService vs. REST Microservice
-
Upload
rick-hightower -
Category
Technology
-
view
11.395 -
download
3
Transcript of WebSocket MicroService vs. REST Microservice
![Page 1: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/1.jpg)
Rick Hightower - Mammatus Technology Inc.
WebSocket MicroService vs. REST Microservice
How does the performance of a REST microservice compare to a WebSocket MicorService?
![Page 2: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/2.jpg)
Comparison of Speed
❖ WebSocket is faster and uses less resources for more calls
❖ REST is slower due to each connection needing to wait for a response before it can send another request
![Page 3: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/3.jpg)
REST/HTTP vs WebSocket❖ With REST you have to wait for a reply before
you can send another request (over the same connection)❖ Unless you use pipelining which seems to
work better in benchmarks than the real world❖ With WebSocket you can stream requests and
stream responses and then marry them together❖ Still request/reply but WebSocket can send
responses while it is getting other requests
![Page 4: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/4.jpg)
Example uses QBit❖ QBit supports REST and WebSocket RPC❖ QBit allows you to stream requests over the wire
and receive responses over the wire. It employs micro-batching to batch requests and responses into larger chunks to minimize IO and thread hand-off costs
❖ QBit allows async REST calls and async WebSocket calls. (As well as internal services based on queues)
![Page 5: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/5.jpg)
wrk Testing tool for REST/HTTP
❖ To perf test REST code we use wrk ❖ wrk load tester capable of generating significant
load when run on a single multi-core CPU❖ wrk load tester uses multithreaded and event
notification systems ❖ epoll and kqueue
❖ wrk maximizes the number of HTTP requests per second
![Page 6: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/6.jpg)
Trade Service
![Page 7: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/7.jpg)
wrk LUA script
![Page 8: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/8.jpg)
Caveats About the Test❖ We can tweak server a bit and reduce the flush rate or reduce the batch size to get
higher throughput with lower connections❖ We can also tweak the OS so we can have more ephemeral ports available and then
use a lot more connections❖ experience tells me that we can get close to 90K TPS or so on a MacBook Pro
❖ We could test from two machines ❖ one of those machines being a Linux server with a tweaked stack
❖ This test has disadvantage of all being run on same machine❖ but same disadvantage that the WebSocket version will have so it is somewhat
fair❖ We could also employ HTTP pipelining to increase the throughput,
❖ great trick for benchmarks rarely works in production environments with real clients
❖ On commodity Linux server, we can get close to 150K TPS to 200K TPS from experience
![Page 9: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/9.jpg)
WebSocket Test❖ This will be a bit harder❖ No tool like wrk to test WebSocket RPC calls so
we will write our own❖ RPC calls are QBit centric and rely on JSON plus
some custom ASCII protocol ❖ Some overhead in the protocol because we have
to match responses to clients and requests need unique identifier (as well as the client needing a unique identifier)
![Page 10: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/10.jpg)
To use WebSocket we will need Async interface to service
![Page 11: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/11.jpg)
WebSocket PERF Test code
![Page 12: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/12.jpg)
WebSocket Perf code continued
![Page 13: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/13.jpg)
How does the WebSocket microservice do?
1 Million messages a second.
700K messages for a single WebSocket connection.
7.5x better than REST version.
![Page 14: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/14.jpg)
Overhead❖ Running code through perf showed it was waiting for IO
a lot. Better IO. Better NIC card. More TCP/IP stack tuning. You can expect better throughput.
❖ QBit has to marry requests with responses/client id combinations. There is overhead in doing this. QBit also uses JSON/ASCII protocol which could be optimized to reduce IO (gzip it or use message pack).
❖ Custom more efficient streaming can be implemented if needed (from experience, this is another 2x to 4x)
❖ But in general, WebSocket will do better than HTTP
![Page 15: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/15.jpg)
More Caveats❖ When using WebSocket, you also need service
discovery, and you need to implement your own failover ❖ You can’t just throw a bunch of microservices
behind a load balancer❖ QBit integrates with DNS and consul.io to
provide service discovery (also allows you to use push)
![Page 16: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/16.jpg)
Follow up❖ This slide deck as a blog post:
❖ http://rick-hightower.blogspot.com/2015/12/websocket-microservice-vs-rest.html
❖ The QBit project: ❖ https://github.com/advantageous/qbit
❖ Mammatus Technologies ❖ http://www.mammatustech.com/
❖ Rick Hightower❖ https://twitter.com/RickHigh❖ https://www.linkedin.com/in/rickhigh
![Page 17: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/17.jpg)
There is a lot more to QBit than this
![Page 18: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/18.jpg)
QBit supports reactive stream over WebSocket
![Page 19: WebSocket MicroService vs. REST Microservice](https://reader035.fdocuments.us/reader035/viewer/2022062218/587af0b61a28ab7f378b6713/html5/thumbnails/19.jpg)
QBit implements Service Actors