Some podricers reported the problem of long stream loading times a couple of weeks back. Trying to understand a little bit more about the issue, I set up a logger to record the stream load time for all users of the pod. 2 weeks later, I'd like to share the statistics and some insights that I had.
A page load is considered to be one access to podricing.pw/stream and it counts after the stream loads. A page loading time is the time it takes for the stream to load. The data was taken directly from each user's browsing experience.
This is data from 2016-09-10 to 2016-09-24. We had 27 unique users and 2625 page loads, with the average of 175 loads a day.
The average page loading time is 7.3 seconds, with a minimum of 0.3 seconds and maximum of a worrying 30 minutes and 7 seconds. The graph below shows that for the most part the distribution of the loading times tend to be between 2-5 seconds with only exceptional cases exceeding 10 seconds.
In the past I had stream loading issues with a specific user. He reported that his stream wasn't loading at all. I suggested to him to remove some of the tags he was following, which he had, and a lot, on the assumption that because of the large amount of tags he had it was causing performance issues on the server when it tried to close the query with such large ammount of data from all public posts that were related to his tags, causing a large delay on the page loading time.
Reducing the amount of tags a user has, aspects, etc, worked at the time, so I assume this could also be the case. We see that the majority of users, myself included, have more or less the same page loading times, with the exception of a few of them.
The exact reason as to why there is such performance issues on the server for specific users can be further studied. Today I'd recommend for these users to remove some of their tags and check if there is any improvement on their experience.
When I first started running the pod, I experienced several crashes. The codebase was breaking daily. Eventually I had to upgrade the server so it could handle running the diaspora code. It works now, I don't have to restart very often, but still, I find the server very heavy and resource intensive and I wouldn't be surprised to find that the problem also relies in the diaspora source code. On the graph above, there is a strange spike happening on the 21h. I have no idea what happened, I might assume this must be some kind of error in the data.
On the graph above the animation shows how the average page load time per user changes over the course of days. I restarted the server just before I started this experiment, and I restarted it once again yesterday, September 23h. It can be observed that the page load time increases for many users overall, giving the indication that the server uptime must be related to performance. A problem on the source code is another issue seeking further investigation.
You can download the code for logging user interaction on webpages and for generating these graphs here: link