Painful browsing the forum, like wading through treacle

[#1]

Hi @Anonymous

I have indeed and I have just looked again...

8** seconds to call 78 file requests to load 1.3M of data, of which 96% looks as though it ought to be static (Scripts, Style Sheets, Graphics and Fonts.

Note AIUI these tests do not run over the PN network - they run direct from the test server to the community server, not from the client requesting the test.

There were 4 resources with 6+ second concurrent waits, one of which is a graphic.

https://community.plus.net/aptgm87544/api/2.0/jsearch

https://community.plus.net/aptgm87544/api/2.0/ui/lang/ng-common?board.id=Community

https://community.plus.net/aptgm87544/api/2.0/ui/lang/ng-community?board.id=Community

https://community.plus.net/beacon/27106389119_1550054060400.gif

** a second test took 14 seconds to load and there were a fair few resources with concurrent 6 second waits, again a number of them being graphics.

In comparison I did a similar test on community.bt.com - still a 5+ second page load but nothing with a substantial wait time as seen with the above pages.  For that site Script and CSS component proportions were similar to that for Plusnet, but the Font portion was markedly higher whilst the graphics portion was significantly lower.  One wonders if the Plusnet graphics have been made resolution friendly for web pages? 

The questions Lithium need to answer are...

1. Why are they not doing these diagnostics for themselves?
2. Given that these are calls to the FORUM service (Lithium platform) why does the Plusnet instance see these issues whilst other users appear not to ?
   Remember that the Plusnet implementation was the first using the responsive layout and therefore might not be identical to the other instances not seeing these issues.
3. Are they really interested in fixing this at all?  They requested information to help over a week ago and have not responded to the information provided?
4. Does Plusnet get the same level of support as do other users?

[#2]

---

@Townman wrote:

The questions Lithium need to answer are...

1. Why are they not doing these diagnostics for themselves?

Even I don't know what diagnostics they're running, the only thing they've asked for right now are the wiresharks you've kindly provided.

Are they really interested in fixing this at all?  They requested information to help over a week ago and have not responded to the information provided?

Lithium are unlikely to respond here, I have provided them with the information and they may well have responded. I'm not in the office right now so cannot get an update. 

Does Plusnet get the same level of support as do other users?

I imagine that as with everything it depends on what support wrap around is purchased, I have no idea what other companies have purchased and would imagine Lithium wouldn't disclose this commercial information.  

Lithium are investigating but they're struggling to replicate the issue, just like I am. I access this forum on my phone, on my work laptop, on my home tablet and I have only seen the issues described a couple of times. Lithium have passed it to more senior support staff to investigate, but I've not been around to assist.

[#3]

Unrelated to your questions, @Townman, but the past couple of days, along with the long 'waiting for community.plus.net...' message on first requesting a page (any page) on the forum site there is now a second instance of that message with a totally blank white space for about 4 seconds before the page then instantly loads.

[#4]

I guess all we can do now is wait to see if @JonoH gets an update from Lithium it would be interesting to hear what their take on it is.

[#5]

Hi @JonoH,

Thank you for the prompt reply.

I am surprised by the report that Lithium cannot reproduce the user experience. Anyone should be able to run pingdom.com page load diagnostics, which micro analyses the detail of every component call and see the timings for each stage of those calls. The analysis clearly shows 6+ second wait times on multiple calls.

If it helps them, I’m willing to offer a TeamViewer session so that they can see what I see (as per the video I sent last year - do they have that?).

It should also be easy to answer / redress the questions over cache optimisation - has it been considered / examined? Have the static components been optimised (eg graphic resolution)?

All of this might have been done but one suspects not ... whilst we still see sedentary page loading ... and no news of progress.

It would help to know what has been examined and eliminated from being a contributing factor please. There have been a number of comments that these delays are not seen on other Lithium sites ... and the ones I identified all related to calls to community.plus.net as opposed to other common (shared?) Lithium platforms.

[#6]

@JonoH

“Even I don't know what diagnostics they're running, the only thing they've asked for right now are the wiresharks you've kindly provided.”

Did I miss a request? I recall being asked for tracert reports but not wiresharks.

Do they want full network traces now?

[#7]

@Townman wrote:
Did I miss a request? I recall being asked for tracert reports but not wiresharks.

No, it was a typo from me  

[#8]

Wiresharks would be a logical diagnostic resource!!

[#9]

---

@Townman wrote:

In the deep diggings done by commentators here, has it been determined if the long delays are associated with specific requests or are they random requests?

Yes it has been determined. I'm not going to keep repeating myself. If anyone wants any more of my help to fix their problems or do their job for them, they'll have to start paying me.

[#10]

Subsequent to asking the question I've seen varying resources experience delays.

[#11]

@Townman, looking at the URLs cited in Msg 106 I see that 3 of them appear to be CGI calls. This implies that either the CGI doesn’t have enough resources to complete in a timely manner. But if you take the image URL in to consideration it may be a simple matter that there are not enough handles available to server these requests so the system has to wait until one becomes available.

Given the fact we know that the site can perform very well with no noticeable lag this leaves me to consider a resource limitation with my money going to handle availability, as a lack of handles would affect all requests made to the server.

[#12]

The problem I have with the "resource limitation" or "number of handles" theory is that I reported the dire performance of this forum within the first few hours of it going live on the 7th April 2016, when virtually nobody had transferred their old Plusnet SMF logins and there were perhaps a dozen users on the site.

From that day I have ALWAYS experienced extremely slow page loading on this site.

So either the new forum was massively under-resourced from the start (which would be odd seeing as other Lithium sites don't exhibit the same problem), or more likely @jaread83 wrote a lot of inefficient code in a rush just to get the forum delivered on time and then never went back to optimise or performance test it.

Why is the new forum so slow to load ?

I'm finding that each page of the new forum is taking an average of 12 seconds to load.

Seeing as this is only the first few hours since going live, and not many people are logged in, the load on the site shouldn't be much, so is this only going to get worse as more users come on-board ?

Are there any plans to speed this up ?, as it is truly tedious waiting for each part of the page to load before it is rendered completely.

[#13]

@Anonymous who is to say that the server hasn’t been under resourced since day one! If no one took the time to modify the web server’s config then the default settings would apply and without knowing its vendor we don't know how generous or restrictive these are.

As I’ve said above I don’t think the code is an issue here as we know that the site can and does perform very well. If as you say @jaread83 did write a lot of inefficient code that remains in the site then that inefficiency is still there, and that would show as a constant and that evidently is not the case here.

[#14]

I disagree that inefficient code would manifest as a 'constant'.

The problem with inefficient code is that it is likely to use unexpectedly high demands on available resources (such as CPU, memory, system calls, handles, DNS lookups, etc).  When the excessive load is then scaled up with a varying number of users, then the effect of overloaded resources becomes exponential, and the system grinds to a halt until the number of users or processes recedes.

Regarding the server configs, if we assume that they were never changed from default, or optimised,

WHO should be responsible for doing that ? is it Lithium or Plusnet web devs ?

and can @JonoH task somebody to review the settings and optimisations as soon as possible ?

[#15]

I understand what you are saying and I don’t really disagree, but hypothetically, if function fn() takes N seconds to execute then every user would experience this N seconds of time and this is clearly not the case, nor are we seeing a true exponential growth in time when the server is under load. If we were then this issue would be so screamingly obvious to have been flagged up and fixed by now as the system would be tantamount to unusable.