Good old Open Source

[minestrone]

Would the connection not be created and killed in the request anyway? The query to get the posts for TPD will be done in a range so I cannot see how a TPD page view/post would be any worse than any other topic.

Also the number of views compared to posts is quite low.

God knows why I care though.

[realityhack]

"As I've mentioned in the beginning of my blog post – what's really cool in vBulletin 4.0 is not necessarily apparent to the untrained eye. Previously, vBulletin utilized the fulltext index on both “thread” and “post” tables making optimization and server problem resolution very expensive and complicated. vBulletin 4.0 no longer needs the fulltext index to be present in either of the “thread” or “post” tables. This means that vBulletin 4.0 database can utilize the InnoDB table engine and prevent a lot of common database issues associated with locked database queries. This is great news for small to medium board owners who will be able to resolve some performance overhead problems without having unnecessary expenditures for expensive hosting or complicated third-party search engines."

- From vBulletin.com, their emphasis.

Any plans to upgrade? IIRC they pulled some stunt like forcing you to upgrade if you want to receive updates anyway... lots of people were pretty annoyed about that.

Anyway I'll see if I can come up with anything that could help, although I don't have the vBulletin code to work with: I may have to buy a copy to see where it's failing

Admin - can't you let NF take a look under the hood?

Weren't you thinking of upgrading vBulletin a while ago anyway?

[Andy2]

Get the names of top ten posters and drop them

[TheFaQQer]

So why should TPD be singled out?

Because it always is, because of the TPD clique.

As a warning to those contemplating the TPD deletion - such action could cause tay to return.

[DimPrawn]

You could upgrade to a proper database and a proper operating system.

I'm sure you can afford a copy of Windows if you save up.

[NickFitz]

Because it always is, because of the TPD clique.

As a warning to those contemplating the TPD deletion - such action could cause tay to return.

[realityhack]

Tips optimising servers for large forums (>1m posts)

[Andy2]

Why not charge users to post on TPD
say 50p a post.
it will be a self supporting thread

[EternalOptimist]

Will cooperate and free up a connection in 20 mins when I go to the pub


DROP CONNECTION ID ='EO' GOTO PUB


hic

[administrator]

That should free up a fair bit of room.

There are far bigger threads than TPD out there running vBulletin with no problems.

Examples please. I have struggled to find any.

There have been 70-odd posts on TPD since 8:30 this morning. There have been a lot more than that over that time period in General. I assume there have also been posts in B/C, A/L and Technical, and probably to other LR threads.

So why should TPD be singled out?

Because TPD is a single thread containing over 200,000 posts. A lot computation to work out last post in thread, last unread post etc. I am sure you can understand this. It is about the amount of posts in the thread not the amount of threads in the forum.

If it's because of the length of the thread, that would imply that the database itself needs to be optimised. It really shouldn't be breaking over something like that. Certainly that shouldn't be causing too many database connections: at present the number of people viewing each forum are:

General 185
B/C 60
A/L 108
Technical 15
Light Relief 24

and as each of those viewers requires at least one DB connection per page view, it's quite obvious that it can't be TPD consuming too many connections: it must be General that is using the greatest number of connections.

Yes but when the DB is taking a long time to sort the TPD thread to display the info the end user has requested it holds up other users' requests and these time out. This has been a minor problem for the last few weeks but is becoming a daily occurence now when the forum is busy.

Yes, the DB could be optimized but there is no way of guaranteeing that a non-standard DB will upgrade correctly for future versions of VB that we may want to implement. With resource specific problems like this I have often found that upgrading hardware is quicker and easier than trying to weed out small gains through code optimisation.