Performance of Socket write vs disk write

Question

My java application logs a fair amount of information to a logfile on disk. Some of this logged information is more important than the rest; except that in rare cases the less-important info is needed to explain to the end-user why the code in production took a certain decision.

I was wondering if it will be a good idea to log the less important information to a socket instead of the file on disk. Is socket write significantly faster than disk write?

Update: Basically, I wanted to log to a socket in the same subnet or even the same machine, assuming that it would be faster than writing to disk. Another process (not part of my application) would then read from that socket at its convenience. I was thinking this would be logstash pulling from a socket. Async logging to disk using another thread is another alternative but I wanted to consider the socket option first if that is an easy solution with minimal performance hit.

Answer 1

You have few choices:

• local storage is usually faster than network
• you could use async logging to disk, so your process fires and forgets (which is fast!)
• logstash can read from Unix Domain Sockets, if you are on *nix; these are usually faster than I/O

If you are writing somewhere fast and from there it is being forwarded in a slower fashion (logstash logging over network to some Elastic instance) where is the buffering happening? Such setup will generate growing backlog of messages yet to be shipped if the logging happens at high rate for prolonged period of time.

---

In the above scenarios buffering will happen (respectively):

• direct sync write to disk: final log file on the disk is the buffer
• async logging framework: buffers could eat into your heap or process memory (when outside of heap, or in some kernel area, therefore in RAM)
• unix domain sockets: buffered in the kernel space, so RAM again

In the last 2 options things will get increasingly creaky in constant high volume scenario.

Test and profile... or just log to the local disk and rotate the files, deleting old ones.

Answer 2

Socket is not a destination. It's a transport. Your question "send data to socket" should therefore be rephrased to "send data to network", "send data to disk" or "send data to another process".

In all these cases, socket itself is unlikely to be a bottleneck. The bottleneck will be either network, disk or application CPU usage - depending on where you are actually sending your data from the socket. On OS level, sockets are usually implemented as zero-copy mechanism, which means that the data is just passed to the other side as a pointer and is therefore highly efficient.