VietMX Staff asked 3 years ago
By its very nature, long-polling is a bit of a hack. It was invented because there was no better alternative for server-initiated data sent to the client.
Maintaining an open webSocket connection between client and server is a very inexpensive thing for the server to do (it’s just a TCP socket). An inactive, but open TCP socket takes no server CPU and only a very small amount of memory to keep track of the socket. Properly configured servers can hold hundreds of thousands of open sockets at a time.
On the other hand a client doing long-polling, even one for which there is no new information to be sent to it, will have to regularly re-establish its connection. Each time it re-establishes a new connection, there’s a TCP socket teardown and new connection and then an incoming HTTP request to handle.
HTTP connections, while they don’t create open files or consume port numbers for a long period, are more expensive in just about every other way:
- Each HTTP connection carries a lot of baggage that isn’t used most of the time: cookies, content type, conetent length, user-agent, server id, date, last-modified, etc. Once a WebSockets connection is established, only the data required by the application needs to be sent back and forth.
- Typically, HTTP servers are configured to log the start and completion of every HTTP request taking up disk and CPU time. It will become standard to log the start and completion of WebSockets data, but while the WebSockets connection doing duplex transfer there won’t be any additional logging overhead (except by the application/service if it is designed to do so).
- Typically, interactive applications that use AJAX either continuously poll or use some sort of long-poll mechanism. WebSockets is a much cleaner (and lower resource) way of doing a more event’d model where the server and client notify each other when they have something to report over the existing connection.
- Most of the popular web servers in production have a pool of processes (or threads) for handling HTTP requests. As pressure increases the size of the pool will be increased because each process/thread handles one HTTP request at a time. Each additional process/thread uses more memory and creating new processes/threads is quite a bit more expensive than creating new socket connections (which those process/threads still have to do). Most of the popular WebSockets server frameworks are going the event’d route which tends to scale and perform better.
