| Relationship Graph | View Issue Dependency Graph | |||
|
|
||||
|
||||
related to 
child of 
duplicate of View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0018128 | phpList 3 application | Interface - Administrator | public | 29-05-16 18:01 | 14-09-16 19:47 |
| Reporter | duncanc | ||||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.6 | ||||
| Target Version | 3.2.6 | Fixed in Version | 3.2.6 | ||
| Summary | 0018128: Community news sidebar causes delay on loading every page | ||||
| Description | The RSS feed for the community news in the right sidebar is having a connection opened on every page load, which leads to a delay on displaying the page. On my shared hosting it is between 0.5s and 1s. I guess the intention is to regenerate the sidebar infrequently but the onxy-rss package opens the url to get its modified time every time the parse() method is called (in the mod_time() method). | ||||
| Tags | No tags attached. | ||||
|
|
There seem to be two ways to stop this delay happening on each page 1) change onyx-rss so that it checks for the feed being modified only when the cached version has expired. Currently it checks for the feed modification regardless of cache expiry. 2) The expiry period appears to be 24 hours so it is a bit unlikely that a feed change will happen while an admin is logged-in. So an alternative is to generate the sidebar just once, cache the generated html and always display that while the admin is logged-in. |
|
|
Does https://github.com/phpList/phplist-ui-dressprow/pull/22 fix this? |
|
|
Also, would be good to check if the RSS feed can respond quicker. I guess if it's being DDOSsed because of this, that's not helping either. |
|
|
The pull request https://github.com/phpList/phplist-ui-dressprow/pull/22 is simply tidying-up the code, not addressing this problem. onyx-rss is using fopen() with a URI to retrieve the feed. I guess that the timeout on that can be set but that is not currently done. I suggest that, to reduce any impact of slow RSS feed response, generating the sidebar just once or twice (for either three or 10 items) looks the best way. But for the other approach I have made a change to my local onyx-rss to avoid the problem. It needed two code changes - Check for a modified feed only when the cache has expired - When the cache has expired and the feed has not been modified then re-start the expiry period by touch()-ing the file. Otherwise it keeps checking for feed modification. The changes just repeat some conditions, so are a bit clumsy, but seem to work. |
|
|
I guess that the variable delay in displaying pages is caused by the extra load on phplist news as more people upgrade to release 3.2.5. There is an extra connection to the feed on every page display. To reduce that load see https://github.com/phpList/phplist-ui-dressprow/pull/23 for two changes either or both of which can be applied. 1) avoid regenerating the sidebar on every page by caching the generated html 2) fix onyx-rss so that it checks for feed modification only when the cache has expired. This change also implements a time-out on the connection to the feed. |
|
|
Great, we should merge this soon and release another version. The delay may cause all kinds of issues. What would even be nicer is to fetch the feed non-blocking in the background and only display it once it's cached. |
|
|
Have you been able to confirm that the slow response was due to excessive requests? I guess that the web server access log would show the requests. |
|
|
The changes were applied. We haven't checked the server logs though. Not sure the RSS delivery has been the delay. |
