Example of scaling this ? about golongpoll HOT 2 CLOSED

Although I have not spent a whole lot of time rigorously profiling the library, anecdotally it seems to perform very well. A large (1000+) number of concurrent connections should be no problem since goroutines are generally much lighter in terms of resources than the threads you would see in a longpoll implemented in another language.

In periods of low event activity where most longpoll connections are just waiting until timeout, the resources should be very minimal and a very large number of connections should be absolutely no problem.

As far as scaling up whenever you would hit a resource issue... Yes, I have considered adding a database backend (since currently everything is in-memory). For scaling, you could also consider segmenting the traffic deterministically across mulitple instances so that each instance has it's own separate universe of data. I have done this myself with good results. But depending on what you're doing this may not be a viable solution--but if you can design the data needs up front so it's easy to segment, that works nicely.

I think the bigger benefit of a database backend would actually be for storage. If you stop your go program, any events in the buffer are gone. So in the future I may consider trying to add generic data backend support for both scaling and data retention across restarts.

I have created #10 as a placeholder to work on this. It may be a while before I get around to it tho 😄 (but I will make a priority to work on any bugs of course)

from golongpoll.

To follow up about current ways you can scale across multiple instances:

You can load balance (via nginx or other webservers) by URL so that all subscription categories of specific types go to the same instance.

So if you have subscriptions for category "user__actions", you could split the traffic modulo the userid. So all url's for even/odd userids go to one of two instances.

/events/user_1_actions   --> instance A  
/events/user_2_actions   --> instance B
/events/user_3_actions   --> instance A
/events/user_4_actions     --> instance B
...

and any url that publishes on one of those subscription category values should also map to the same instance.

/post/action/user_1  --> instance A
/post/action/user_2  --> instance B
/post/action/user_3  --> instance A
/post/action/user_4  --> instance B
...

You can look up specific webserver options to reverse proxy to one of several IPs/addresses based on the URL pattern.

I have personally done this with a game lobby application where all subscription events/actions were segmented modulo the game lobby id so traffic strain was only limited to the per-lobby level. That way, in order to support more game lobbies, I could add more machines and just update the reverse proxy settings in nginx to now point to more machines.

from golongpoll.