What bandwidth does EtherPad Lite use?

This was a difficult question to answer, because the Internet was quiet about this. There is a discussion about load issues with EtherPad Lite, essentially saying that the server-side overhead of EtherPad Lite is so low that nobody yet had scaling issues on the server side, even with 100+ person pads. Also it says, there is no user limit encoded into EtherPad Lite. The most server-side CPU load is caused by the timeslider feature, which can be disabled then. (There are some reports from riseup.net in that thread about experiencing a 60 user limit, but that seems due to their webserver setup or issues which have now been corrected.) It can however be important behind what web server one runs EtherPad Lite. An asynchronous one like nginx is recommended (again in the above thread).

But I only found one discussion about EtherPad Lite bandwidth usage, which boils down to: it’s not an issue server side, because other resources would saturate first. (Background: The text synchronization technique used in EtherPad Lite is called operational transformation.)

Test Results

So I had to do some own tests to get some numbers. I used nethogs, available in Ubuntu’s community managed repositories, to show the bandwidth usage of a browser instance that I used just for typing with EtherPad Lite. The pad I tested was a new, public one from piratepad.net.

Results:

• one user, typing at full speed:
  • sending 3 – 3.5 kB/s
  • receiving 1.3 – 1.5 kB/s
• two users, both doing nothing:
  • sending 0.0 – 0.12 kB/s
  • receiving 0.0 – 0.1 kB/s
• two users, one typing at full speed, one only receiving, measured for the receiving one:
  • sending 1.9 kB/s
  • receiving 1.8 kB/s
• two users, both typing at full speed:
  • sending 4.2 – 4.5 kB/s
  • receiving 2.9 kB/s

The given numbers are maximums, reached at a certain speed of typing, and not exceeded even when typing super fast. This is understandable by the way EtherPad Lite generates the change messages that cause the revisions: at most 2 per second for every user, so that one message will contain 7 characters or so when typing full speed. At least that is what I understood from the pad’s timeslider view, where there are max. 2 revisions per second and per user. However, one revision only contains changes from the same user – so the Etherpad server does not accumulate these server-side.

Extrapolation to more users

I don’t know about bandwidth requirements for more users. As a rough guess, I calculated with:

• sending for each user: 3.5 kB/s for own typing at full speed, plus 1 kB/s of sending receipt confirmations for every stream of change messages from an additional user, so 3.5 kB/s + 1 kB/s * n, where n is the number of concurrent users. Multiply the result by the number of users to get the bandwidth requirement for all.
• receiving for each user: 1.4 kB/s for each other user typing at full speed, so 1.4 kB/s * n, where n is the number of concurrent users. Multiply the result by the number of users to get the bandwidth requirement for all.
• factor for real-life usage: nobody is typing at full speed in real life all the time, so on average one could assume a factor of 0.1 – 0.25 to lower the above bandwidth requirements. This is just a guess though.

No guarantees for that, it’s really just a rough guess from the above measurements. If you have better estimates, please tell.

With the above guesstimates, the results are for 80 concurrent users (for example at a conference):

• 80 concurrent users, theoretical maximum: 80 * ((3.5 kB/s + 1 kB/s * 80) + 1.4 kB/s) = 6.79 MiB/s = 54.3 Mib/s
• 80 concurrent users, at 0.25 load factor: 80 * ((3.5 kB/s + 1 kB/s * 80) + 1.4 kB/s) * 0.25 = 1.70 MiB/s = 13.5 Mib/s
• 80 concurrent users, at 0.1 load factor: 80 * ((3.5 kB/s + 1 kB/s * 80) + 1.4 kB/s) * 0.25 = 0.68 MiB/s = 5.4 Mib/s

What to do when hitting bandwidth limits

In case you really run into bandwidth limits, like when working with lots of users at a conference with moderate bandwidth Internet, you could:

• Maybe reduce the bandwidth usage by decreasing the rate at which user EtherPads will fire the change messages.
• Install the EtherPad instance locally at your premises, as the LAN bandwidth (even if just 54 MBit/s WLAN) will very probably not limit the pads. You can even allow outsiders to contribute by also making the pad accessible via DDNS.