Lack of interest Realtime / Autoupdate Alerts

[majdi]

alerts should autoupdate using ajax, no need to refresh

 

[Kier]

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]

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.

 

[James]

I suppose you could use a socket?

 

[Kier]

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

Facebook uses long polling, which pauses when the page loses focus and restarts when the page regains focus.

 

[Luke F]

Facebook uses long polling, which pauses when the page loses focus and restarts when the page regains focus.

Ah fair enough, but it would work quite well to check just on focus anyway.

 

[Markos]

There are not an alternative system? I see that there are an addon to do that.

 

[Smiggy]

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?

 

[Kier]

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

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.

 

[Deebs]

For those running nginx check the following:

http://www.igvita.com/2009/10/21/nginx-comet-low-latency-server-push/

This implements long pollingon nginx without having to worry about things like a comet or orbit server.

 

[Kier]

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]

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]

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]

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]

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?

 

[dzv3]

Maybe we could use HTML5 websockets along with something like node.js or alike designed specifically for this purpose on the server side.

 

[zeropaid]

@kier Thanks for clarifying this.