The number of posts per page isn’t fixed by vB; over at the Pizza Parlor, another vB board, they only do 15 posts per page, as opposed to the SD’s 50 per page.
While I think 15’s going too far the other way, my thought is that if the posts per page were cut to 30 or 40, then each load would only involve 60-80% as much stuff each time. And I can’t see the number of page loads increasing by enough to offset that.
My thought is, surely the mods/admins/techs must’ve already considered this, and rejected it for some reason. If so, what’s the deal? If not, might this have possibilities?
The primary “load” issue is doing a query against the database. Retreiving 50 v. 30 records wouldn’t make much of a difference in query time since the main factor is not number of records selected but rather the size of the table itself.
Displaying fewer post could actually increase server load because more queries would have to be executed. This is more of a usage issue – how often would someone need to go to a new page. If reducing the number of posts per page forces more requests for another page, the load would be higher.
Also, when things fall off the first page, you have a tendancy for folks to either re-ask the same questions that have been already asked (even more so than currently), or to use the “search” function to try to find threads, either of which takes up more resources than we need.
So, Chronos, you’re saying that there is only one setting for number of rows selected for both the forum pages and within a thread. Is that right? I hadn’t thought about that, but in looking at the number of threads on a forum page, it looks like it is set to 50. If it is a single setting, that’s another very good argument for not reducing it.
I honestly hadn’t considered the possibility that the number of threads listed on the forum page, and the number of posts in a thread page, would have to be the same on vB.
(That is what you’re saying, right, Chronos?)
If that’s so, then you’re right - shorter forum pages would lead to more duplicative threads, etc.
I went back to The Pizza Parlor, which (as I mentioned) is a MB using vBulletin version 1.1.3, just as we do.
They have 15 posts per page, but list 40 thread titles on their forum pages. So the two don’t operate in lockstep.
So the question still stands: would cutting each thread page down to 40 or fewer posts ease the load on the server? Given that, each time someone opens a thread, the server has to send the contents of the page out onto the Web, it would seem that smaller pages = reduced load.
In the long run, it’s only a Band-Aid, but if it helps for awhile, buying time to figure out a stable way of funding technical upgrades to this site, then it would still be worth it, IMHO.
Given that the threads/forum and posts/thread are two separate settings, I’ll go back to my original reply that reducing the number of posts per page wouldn’t reduce server load.
From what I’ve read in other “How can speed be increased?” threads, the issues seem to be:
slow/old server - we can’t pitch in $5 each to buy a new one.
searches take time - either actual searches using function, thread searches or sig/smilie searches
more users at one time tend to create larger demand for all three types of searches.
Can the server can be upgraded with larger RAM (not new box)? This may increase swap speed, i.e., search/load time.
If I understand RTFirefly’s thoughts, he’s addressing the part of the problem that lies in the search functions. Perhaps fewer posts per page would require fewer smilie/sig searches, along with fewer post search and replaces.
Is it possible to archive some older, less popular threads (What’s the worst smelling fart you’ve ever had?) that are unlikely to be cited in such a way the search functions won’t look for them? (perhaps a bit different from just locking them)
we know that if I change my sig today and post a reply to some thread ALL of my sigs will be changed. That’s right, on every post that I’ve included a sig. If some threads are “sequestered” (or deleted), they won’t have to be searched.
Spritle, it sounds like you understand how the server works, and what places a load on it, much better than I do. (That wouldn’t be hard. ;))
My primitive thought amounts to: if a thread is 200K in size, it takes longer for me to download it than if it’s smaller. At the other end - the server end - it must take time (i.e. use up some amount of server capacity) to upload the damned thing.
If each piece you upload is only 4/5 as big (OK, so this would only apply to full pages, but still), and you don’t upload 5/4 as many pieces, it seems you’d be coming out ahead. No?
Of course, if the actual uploading is a negligible part of the load on the server, then maybe I’m wrong. But then, *what’s the big deal about short v. long sigs?[i/] If 5-line v. 1-line sigs makes a difference (and clearly the people who run this place think it does), then it would seem that cutting 20% off the total content of a page would make a bigger difference, completely aside from finding sigs and whatnot. It seems to me that these two things are directly comparable.
I think the uploading is a (relatively) negligible part of the load. It the database queries, which includes both searches and building threads/forums for viewing, that is the bottleneck.
The issue with sigs is that the server has to do another query (or sub-query or additional join depending on database structure) to get the sigs. I don’t believe that the length of a sig would have as much of impact as the number of times a sig is used. I think that 50 one-line sigs would be more of a load than 10 five-line sigs.
[Monkeying with formatting mine. Wording unchanged.]
Other than point #3, it’s all about length. Not just points 1,2, and 4, but the header, the commentary, the emphasis, everything, is all about the length of the sig.
I’m not questioning your knowledge, Jeff - I’m ignorant in this area. I’m just noting the inconsistency, which is something I can pick out.
If you’re right, then someone should suggest to TD that she rewrite her request to put the emphasis on restricting sig use to once per page. But if she’s got the emphasis right already, then my idea is essentially the same thing, only a lot more advantageous.
There’s really nothing more to say here, unless the SD admin has something to contribute. I’ve put my idea forward, and connected it with other things that have been said about how to improve server efficiency.
Ed, Tuba, etc., feel free to use this idea if it’s helpful, and ignore it if it’s not.
There’s actually two separate issues with sigs: First, there’s the server load. I’m not sure how sig length affects load, but long sigs can’t be better, in any event. The second consideration, though, is much simpler: Really long sigs are just plain annoying to a lot of folks. Here, I’m certain that length matters. Even if we had the server of our dreams and an Internet backbone running straight into the Reader’s offices, having a sig that’s longer than the post it’s attached to is lousy style.
Both considerations are factors in Tuba’s announcement.
Thanks to everyone for their input on this question.
The number of posts per page was achieved through trial and error pretty much, we wanted to have as many as we could fit and load comfortably. If we drop to less, the number of threads that get lost on back pages increases, and that’s not a good thing, almost as bad as not being able to see pages in the first place.
We’ll look at this factor along with all the other possible solutions that we might find to potentially solve our page loading problems.
Unfortunately, we can’t merge threads, although there’s plenty of times when that would be useful… For instance, when a thread accidentally gets double-posted, and both get replies. The closest we can come to that is to close one, and put a link or a bunch of big quotes in the other. We could encourage folks commenting on a column to see if there’s already a thread on it, but I’m not so sure that’s a good idea, either: Usually, different threads are commenting on different aspects of the column, and the conversation could get a bit muddled were they all in the same thread. For example, one of those threads you mentioned is just on the specific terms “foo” and “bar”, and their usage in the hacker community, which has very little to do with “notary sojak” per se.