"continuation threads"

[markfm]

A toughie, Roly, as the larger supplier threads are actually likely contributing significantly to this, if it is true that vb likes to do things with the whole thread post set when people choose to view or post.

There are various popular supplier chit chat and contest type threads that are massive, have built huge numbers of views. The large threads are undoubtedly good from the perspective of building communities, however if there is any reality to the performance issue then exempting the real heavy hitter threads is an exercise in futility, annoying without actually getting the benefit of the change.

Maybe two-tier, 4K for standard threads, 8 or 10K for supplier (ECF Supplier and standard Supplier) threads, see if that does something good? As long as there is a clean link from the continuation thread to the prior, and as previously mentioned there is a method to allow someone to adjust the first post in a continuation thread, that might work.

 

[wolcen]

Any developer could tell you that a huge thread will not slow down the system. The thread size has nothing to do with anything. A thread is virtual.

Regardless of the post count of a thread, every page query is the same. There's a skip number and a take number. Those two numbers make up the query. The query gets sent to the database, the database returns posts.

The problem lies in either the database or the rendering of the html (ie. too many plugins).

To blame the problem on something that has absolutely no bearing on the rendering of a page is ridiculous.

I read a post by an admin that stated something along the lines of: "More servers/cloud servers will not fix the problem...". And then proceeded to copy paste some words that reeked of "works on my machine". That's a load of you know what.

My guess is that the ECF infrastructure sucks and/or the database is fragmented.

Before you go doing anything else that's pointless, why don't you talk to someone who knows about tuning software? This is a very big and busy forum. I'd put money that it's hitting the limits of the hardware running it.

Thread size certainly could impact performance if, for example, the aggregations related to it are dynamic. I believe the social feature has been implicated as a potential problem - if for each page the "like" count is calculated for a thread on each page view, it takes longer to count more likes. Now, should that be an issue on a solid database with good indexing? No, not really, or else the software could instead be maintaining that count separately. So, I don't disagree with you in general (i.e. yes, a thread is merely an "id" that the set of posts within are selected by, etc.), but it could very well be true that closing large threads is a workable stop gap measure. This may free resources that might otherwise be used to update or calculate aggregations, etc - the system can ignore closed threads once they've had their "last count update", etc.

 

[matador]

I've never had problems with load times. Everything loads quick for me.. just my 2 cents

 

[JerryRM]

Sorry if I'm repeating what already has been said, I wasn't about to read all 11 pages of this thread. I think it was done to speed up the forum.

My question is, why the need for the cloak and dagger stuff?

 

[grantium]

Any developer could tell you that a huge thread will not slow down the system. The thread size has nothing to do with anything. A thread is virtual.

Regardless of the post count of a thread, every page query is the same. There's a skip number and a take number. Those two numbers make up the query. The query gets sent to the database, the database returns posts.

The problem lies in either the database or the rendering of the html (ie. too many plugins).

To blame the problem on something that has absolutely no bearing on the rendering of a page is ridiculous.

I read a post by an admin that stated something along the lines of: "More servers/cloud servers will not fix the problem...". And then proceeded to copy paste some words that reeked of "works on my machine". That's a load of you know what.

My guess is that the ECF infrastructure sucks and/or the database is fragmented.

Before you go doing anything else that's pointless, why don't you talk to someone who knows about tuning software? This is a very big and busy forum. I'd put money that it's hitting the limits of the hardware running it.

Thank God. I thought I was going to have to type this myself.

 

[wolcen]

Thank God. I thought I was going to have to type this myself.

Yes - the page queries are the same. The record set sizes that are queried are however different.

 

[rolygate]

side note/ OT: while we have the leader's undivided attention, please, please code to help permanently disable the "likes"notifications . it won't hold in the user settings.

Yes, we know about this. Apparently it's a simple thing that is hard to fix (it's hard-coded in the core, or the result of a conflict, or buried in vbSEO's obfuscated code or something).

Plus poor old Harry our vBulletin dev is kinda busy right now

 

[rolygate]

Maybe two-tier, 4K for standard threads, 8 or 10K for supplier (ECF Supplier and standard Supplier) threads, see if that does something good?

It doesn't look as if this will be possible, as we'd need to re-code the plugin from scratch. I think before that happens, we'll just ditch the idea. Exempting Supplier forums, and setting the post number high to start with, could be a way to go forward with this. Otherwise, we might have to ditch the idea.

It was worth trying though. I especially like the arguments between all the tech guys as to "No it will never work", vs "Yes it will work because...". Me, I'm extremely sceptical about it, because that's the way I am. Occasionally I'm pleasantly surprised though. Most techies, including me, say it won't have any effect. Some say it will. I wouldn't bet on it either way without seeing the *exact* SQL queries vB makes to build the page, though.

A while back I was looking at the cost of rebuilding the whole thing on an Oracle database, because the pageload speed complaints were beginning to get to me. But there are enough people that have come forward now that say every page everywhere loads in under 3 seconds no matter what, and no matter if they are are guests or logged in. You can draw your own conclusions from that...

I still don't rule out that we have a faulty server somewhere, though; or that some of our static/CDN content is not getting served correctly to all users in all locations. That's what I need to look at next. There is absolutely nothing wrong with our basic set-up otherwise some people could not get lightning fast pageloads all the time. I just need to see what boxes they are on and what network routes.

 

[rolygate]

Sorry if I'm repeating what already has been said, I wasn't about to read all 11 pages of this thread. I think it was done to speed up the forum.

My question is, why the need for the cloak and dagger stuff?

You 'll need to explain that please, Jerry?

 

[lowboy]

I know I'm quoting myself but.
This has not helped me as far as pages loading quicker.
On a side note I commend the higher be's for trying.

Hope this fixes the load problem.
I, like someone before said, wish I could get rid of threads I have no longer interest in and have unsubscribed to.

 

[tiburonfirst]

I still don't rule out that we have a faulty server somewhere, though; or that some of our static/CDN content is not getting served correctly to all users in all locations. That's what I need to look at next. There is absolutely nothing wrong with our basic set-up otherwise some people could not get lightning fast pageloads all the time. I just need to see what boxes they are on and what network routes

this gets my vote - if i, with a lousy, lousy connection, can get 'snails' to load in under 5 sec some days while others complain of lag at the same time it has to be a server problem somewhere........

 

[TunnelVision]

Any developer could tell you that a huge thread will not slow down the system. The thread size has nothing to do with anything. A thread is virtual.

Regardless of the post count of a thread, every page query is the same. There's a skip number and a take number. Those two numbers make up the query. The query gets sent to the database, the database returns posts.

The problem lies in either the database or the rendering of the html (ie. too many plugins).

To blame the problem on something that has absolutely no bearing on the rendering of a page is ridiculous.

I read a post by an admin that stated something along the lines of: "More servers/cloud servers will not fix the problem...". And then proceeded to copy paste some words that reeked of "works on my machine". That's a load of you know what.

My guess is that the ECF infrastructure sucks and/or the database is fragmented.

Before you go doing anything else that's pointless, why don't you talk to someone who knows about tuning software? This is a very big and busy forum. I'd put money that it's hitting the limits of the hardware running it.

I couldn't agree more..

 

[RippleInStillWater]

Its just a heads-up is always nice, roly, changes inflicted without warning freak people out and have since the dawn of time, you know that -- and I'll drop my criticism of the social buttons, I know that's not going anywhere by now!!!

 

[kritter]

Hit's them thar aleens, we'unz are under attak, run fer tha hills!!! oh, wait a minite, I'm in tha hills!

 

[markfm]

Reading vbulletin-specific threads lends credence to possible performance impacts of large threads:
https://www.vbulletin.com/forum/sho...n-a-thread?highlight=large+thread+performance
From a vbulletin support person "I would imagine after 1000-5000 posts, threads if still ontopic would be better off having a pt2 created. "

(I was in the "this sounds odd" group, but decided to check what information was out there.)

 

[BigBopper]

FYI
There are going to be a lot of extra posts like this one:

Just a post so I can find this thread again.

because there seems to be a lot of people that don't know how or prefer not to use the Thread Tools to subscribe to threads.

Sorry lowboy, but yours was the easiest example for me to find.


My opinion:
As a forum user, I do not like the idea of splitting a thread when post counts reach a certain number. None of the other forums that I frequent have found the need to do that, and many of them are using vBulletin. As a DB admin, I see no reason the thread size should impact page loads significantly, yet I haven't worked with vBulletin nor do I know what your backend setup is, so this is merely my take on it.

Al

 

[lowboy]

It's fine.
It's just easier and quicker that way sorry.

 

[tiburonfirst]

FYI
There are going to be a lot of extra posts like this one:


because there seems to be a lot of people that don't know how to use the Thread Tools to subscribe to threads.

Sorry lowboy, but yours was the easiest example for me to find.


Al

wrong! lots of us know but prefer to navigate ecf using ''my posts''

 

[Capt' Brian]

Ahoy! Well, to be honest I was going to restart my thread when it hit 5k posts but never did, then 10k and 15k posts came around and I felt like I would be burning a book about the evolution of our mod so never did.

But, if my ship has been scuttled then so be it, but just as soon as I am given permission to close the new thread I shall and start another with information that is actually pertinent to the current state of our mods.

Other than that, I am good to go with it even if I am forced to do it again just a few months down the road, although It would be nice to do it again 'voluntarily' with a controlled spawning of the next thread, and the next and so on.

Capt' Brian

 

[JerryRM]

You 'll need to explain that please, Jerry?

Well, Chris, the membership is usually informed in advance when changes are going to be made to the forum. Unless I missed something and that is probable, we weren't informed of this. Also the person who closed the threads, used the name of "guest", rather than his forum name. That's what I meant by cloak and dagger.