Lack of interest Realtime / Autoupdate Alerts

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.
This suggestion has been closed. Votes are no longer accepted.

Kier

XenForo developer
Staff member
You mean server resources?
To do realtime updates as Facebook does, it is necessary to implement long polling, a function that would rapidly kill any Apache installation. You need a very specialised setup to implement it properly, and not one to which most of our customers have access.
 

Luke F

Well-known member
To do realtime updates as Facebook does, it is necessary to implement long polling, a function that would rapidly kill any Apache installation. You need a very specialised setup to implement it properly, and not one to which most of our customers have access.

Why not do as I've suggested before and check for new alerts on the page focus event like Facebook did/does.
 

Smiggy

Member
To do realtime updates as Facebook does, it is necessary to implement long polling, a function that would rapidly kill any Apache installation. You need a very specialised setup to implement it properly, and not one to which most of our customers have access.

Kier, I'm sorry if this sounds dumb, but how has ajaxboy achieved the desired result with his script? Or am I missing something? :confused:
 

Kier

XenForo developer
Staff member
Kier, I'm sorry if this sounds dumb, but how has ajaxboy achieved the desired result with his script? Or am I missing something? :confused:
To answer this I need to explain the internals of web servers, and the nature of long polling.

Most web servers have at their core the function to build a web page and display it as quickly as possible. While doing this, large amounts of system resources are dedicated to building that web page in order to deliver it fast. In its default configuration, Apache only allows a relatively small number of pages to be built concurrently, and any requests it receives while maxed-out will be queued waiting for those to complete. As the pages are expected to be built very quickly (in a second or less), one rarely notices this queuing.

Long polling works by sending a request for the web server and leaving it open - the script effectively goes to sleep and polls its data source at regular intervals, any sending a response back to the client when it has new data. This means that the connection can remain open for minutes at a time. While the script may not be doing anything, the web server has to maintain the connection - and for most webservers, as I said above, there will be a large amount of resources allocated to that request in the expectation of a fast return. If one is long-polling on Apache, one will very quickly reach the maximum number of concurrent connections, and as a result normal page requests will end up being queued for a potentially very long time, delivering a truly awful user experience.

There are specialist webservers out there that are optimised for long polling, but Apache is most certainly not one of them, and one is highly unlikely to have access to them on any kind of shared or non-dedicated host. For those comparing Facebook functionality, it's worth noting that Facebook's long-polling requests are directed to a completely different set of servers from those that handle regular page loads.

So, the answer is that while we could implement long polling in XenForo, it would be highly inadvisable for most of our customers to actually enable it on their webservers, and therefore in the interest of developing features with the broadest appeal and applicability, we have not done so.
 

Kier

XenForo developer
Staff member
If one is long-polling on Apache, one will very quickly reach the maximum number of concurrent connections, and as a result normal page requests will end up being queued for a potentially very long time
FWIW, there's another name for this - it's called Denial of Service.
 

Smiggy

Member
To answer this I need to explain the internals of web servers, and the nature of long polling.

Most web servers have at their core the function to build a web page and display it as quickly as possible. While doing this, large amounts of system resources are dedicated to building that web page in order to deliver it fast. In its default configuration, Apache only allows a relatively small number of pages to be built concurrently, and any requests it receives while maxed-out will be queued waiting for those to complete. As the pages are expected to be built very quickly (in a second or less), one rarely notices this queuing.

Long polling works by sending a request for the web server and leaving it open - the script effectively goes to sleep and polls its data source at regular intervals, any sending a response back to the client when it has new data. This means that the connection can remain open for minutes at a time. While the script may not be doing anything, the web server has to maintain the connection - and for most webservers, as I said above, there will be a large amount of resources allocated to that request in the expectation of a fast return. If one is long-polling on Apache, one will very quickly reach the maximum number of concurrent connections, and as a result normal page requests will end up being queued for a potentially very long time, delivering a truly awful user experience.

There are specialist webservers out there that are optimised for long polling, but Apache is most certainly not one of them, and one is highly unlikely to have access to them on any kind of shared or non-dedicated host. For those comparing Facebook functionality, it's worth noting that Facebook's long-polling requests are directed to a completely different set of servers from those that handle regular page loads.

So, the answer is that while we could implement long polling in XenForo, it would be highly inadvisable for most of our customers to actually enable it on their webservers, and therefore in the interest of developing features with the broadest appeal and applicability, we have not done so.

Thank you Kier. :)
 

ibnesayeed

Well-known member
To answer this I need to explain the internals of web servers, and the nature of long polling.

Thanks Kier, I do understand that Long Poling (or HTML5 websocket) is the real solution. But, can't we have a regular plain AJAX request with admin configurable frequency mixed with the active tab detection?
 

Kier

XenForo developer
Staff member
Thanks Kier, I do understand that Long Poling (or HTML5 websocket) is the real solution. But, can't we have a regular plain AJAX request with admin configurable frequency mixed with the active tab detection?
You could, but you would instantly double the load on your server.
 

ibnesayeed

Well-known member
You could, but you would instantly double the load on your server.

I completely agree. But, having an option to auto-update it on tab focus and/or every 1-5 minutes (if not instant, depending upon admin configuration), will be worth additional web requests. Also, we might limit this feature to certain groups (like admins/mods etc.). Or, why not varying frequencies for various groups? :)
 
Top