Steffen
Well-known member
This is something in-between a bug report and a feature suggestion and I feel bad for bringing this up so late in the release process of XenForo 2.1. I just didn't notice this potential issue earlier but I think it could be important especially (but not only) for bigger forums. The issue I see is that when XenForo sends push notifications it does so synchronously within the web request that e.g. saves a reply (in contrast to email notifications, which use an async queue).
The first bottleneck are network requests: The architecture of Web Push requires a separate HTTP request to be sent for every subscriber (to servers run by Google, Mozilla and possibly others in the future). In threads with many participants, this can result in dozens or hundreds of HTTP requests when a reply is saved. The Web Push library used by XenForo sends those requests in parallel but obviously the slowest request determines the required time. Needless to say, these requests can run into a timeout. Even if they don't, in larger threads there could be just too many of them. To somewhat alleviate this problem, XenForo reduces the default timeout of the Web Push library from 30 to 10 seconds.
The second bottleneck is CPU usage: The used Web Push library is quite slow because it does quite a lot of cryptography stuff in PHP. I've recently used it in my own project and my CPU (Core i7-4600U) was only able to create (not send, I commented that code out) about 600 push requests in 10 seconds. Today's server CPUs are maybe twice as fast but in general they just have more cores (which won't help because PHP is single-threaded).
There are three possible issues:
In case of emails, there even exists a workaround for needing a queue (just run an SMTP server on localhost that forwards mail to your real mail server). Unfortunately, no such workaround exists for push notifications.
The first bottleneck are network requests: The architecture of Web Push requires a separate HTTP request to be sent for every subscriber (to servers run by Google, Mozilla and possibly others in the future). In threads with many participants, this can result in dozens or hundreds of HTTP requests when a reply is saved. The Web Push library used by XenForo sends those requests in parallel but obviously the slowest request determines the required time. Needless to say, these requests can run into a timeout. Even if they don't, in larger threads there could be just too many of them. To somewhat alleviate this problem, XenForo reduces the default timeout of the Web Push library from 30 to 10 seconds.
The second bottleneck is CPU usage: The used Web Push library is quite slow because it does quite a lot of cryptography stuff in PHP. I've recently used it in my own project and my CPU (Core i7-4600U) was only able to create (not send, I commented that code out) about 600 push requests in 10 seconds. Today's server CPUs are maybe twice as fast but in general they just have more cores (which won't help because PHP is single-threaded).
There are three possible issues:
- A (possibly very) noticeable delay for the visitor who replies to a thread (up to 10 seconds for network requests + CPU time).
- Some push notifications may not be sent if there are too many of them and time runs out (situation: reply to a large thread).
- This can DoS on your own forum if all of your possibly few PHP-FPM workers are occupied with waiting for timeouts (situation: many replies to different threads at roughly the same time).
In case of emails, there even exists a workaround for needing a queue (just run an SMTP server on localhost that forwards mail to your real mail server). Unfortunately, no such workaround exists for push notifications.
Last edited:
Upvote
33
