0

I want to make a centralized log web API, so it will have a large amount of data per seconds. the logs will comming from others WEB API

I was thinking if i make the REST API, all of the POST made need to return an answer and maybe can overload the server with so much request.

then I think in webSockets, establish a communication with the API that made the logs and only send data without necessary responses but I don't know how reliable are that.

So in this case, what method would be fastest and more reliable? Sorry if my english isn't good :(

regards.

Improve this question
3
  • None makes the solution performant. The key is not in the delivery only. It's at how the logging service handles the IO. The delivery Interface is not that important.
    – Laiv
    Commented Mar 23, 2019 at 20:43
  • Have you considered existing logging solutions such as Splunk? Especially when performance is an issue, reinventing the wheel might be suboptimal.
    – Hans-Martin Mosner
    Commented Mar 24, 2019 at 13:45
  • @Laiv well i've thing something like that, and im test fluentd and elasticsearch and kibana, but i want something raw.
    – Black Hole
    Commented Mar 24, 2019 at 17:59

2 Answers 2

Reset to default
0

WebSockets will be more efficient. Allowing you to stream your log records without having to deal with the overhead of a HTTP call for each record.

Improve this answer
3
  • I'm test two things, with REST post and with WebSockets, and the difference de time is something, I think if I put the WebSocket in the principal web API, I can make a connection with the WebSocket server of the logs, so always I'll have the possibility to send something
    – Black Hole
    Commented Mar 24, 2019 at 18:02
  • There's no such thing as so always I'll have the possibility to send something in distributed computing. You have the very same possibilities as with RESTful API Calls. As I suggested, the delivery layer should not be your main concern. It should be the logger architecture. On the other hand, Websockets are very sensitive to the network topology since not all the components between the client and server might support the protocol or have the sockets opened.
    – Laiv
    Commented Mar 25, 2019 at 7:58
  • No to mention about security or browser's incompatibility. Websockets are no more reliable than Http calls.
    – Laiv
    Commented Mar 25, 2019 at 8:00
0

I would suggest that using Websockets is perfectly fine for this. However, as others have pointed out; its less about REST vs Websockets and more about how you handle that ingestion at the server side and persist it. My suggestion would be to accept the messages and put them onto an inmemory queue and then use a seperate thread to persist them. Your main issue server side is “Head of Line” blocking on the websocket; if your persistence part takes too long

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.