How LinkedIn Scaled Its Instant Messaging to Hundreds of Thousands of Connections

Preface

LinkedIn's instant messaging system can handle hundreds of thousands of persistent connections per machine, the result of continuous tuning.

Recently, they published a blog describing the technology choices and key optimizations.

Basic Technology Stack

The basic requirement is a server that can push data to clients via persistent connections rather than the traditional request‑response model.

For this need, LinkedIn chose Server‑sent events (SSE) to implement.

SSE is simple and highly compatible; the client opens a normal HTTP connection and the server pushes a data stream when events occur.

Combined with the EventSource API supported by all modern browsers and available libraries on iOS and Android, compatibility is not an issue, which is why LinkedIn did not choose WebSockets.

The development language is Java , using the Actor model; Akka is a popular Actor library.

The framework is Play , which integrates well with EventSource and Akka .

Optimization Process

Socket maximum connection limit

Initial performance tests showed the concurrent connections could not exceed 128 , which was abnormal. The cause was a kernel parameter net.core.somaxconn that limits the backlog of TCP connections; many systems default to 128.

This parameter can be adjusted in /etc/sysctl.conf.

Temporary port limit

Load balancers use a temporary port for each connection to a server node; when a connection ends, the port becomes reusable. Persistent connections do not close like normal HTTP, so temporary ports can be exhausted, which must be considered when choosing a load balancer.

File descriptor limit

Under higher load, a java.net.SocketException: Too many files open appeared, indicating insufficient file descriptors. In Linux, everything is a file, including sockets.

Current limits can be checked with:

$ cat /proc/<pid>/limits
...
Max open files            30000

To raise the limit to 200000, edit /etc/security/limits.conf:

<process username>  soft nofile 200000
<process username>  hard nofile 200000

System‑wide file descriptor limits are set in /etc/sysctl.conf via fs.file-max.

Conclusion

The article summarizes several generic optimization points; the original post contains more details, including two JVM tuning tips. The full article is available at:

https://engineering.linkedin.com/blog/2016/10/instant-messaging-at-linkedin--scaling-to-hundreds-of-thousands-