The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
Comments |
#22
|
|||
|
|||
It counts posts in forum X where /forum/forumdisplay.php?f=X and forum X contains threads.
|
#23
|
|||
|
|||
Sounds like a good attempt at reducing the queries. I'll give it a whirl, though I am still very weary of having the entire post table scanned in each thread (this time only once instead of 10 times, but it's still a very big query). I'll let you know how the load changes with the mods you've done. Thanks!
-vissa Quote:
|
#24
|
|||
|
|||
By the way, It might be a good idea to have some type of version number associated with your mod changes so we can be sure what we are downloading (like this could be v1.1, etc).. This last change was a pretty big one.
-vissa |
#25
|
|||
|
|||
OK I tested the new version.
While it does reduce the number of queries, it still appears to at least double (or in some cases triple) the load created per thread page view. Now if the page is cached, the load increase is much smaller. However, if the page is not cached, the load increase is 2-3X. (mine went from about .35 sec per uncached page to about 1.0 sec per uncached page.) This was while almost no one was on the forum. When testing, you have to try loading up old threads that are likely not in the cache. You also have to try a different thread each time, because once you load an old thread, it goes right into the cache. That is why testing load time increases can be difficult/confusing. Thanks for the effort, but I had to remove it due to the load. As I mentioned earlier, I think the only way this could work for large forums is to create a table which would be a lot of work. It's a shame becase I think this is sorely needed (would also be nice to see posts per forum in the member profile, etc). Thanks again. -vissa |
#26
|
|||
|
|||
Okay, thanks for the update. Not sure if you know, but the forum posts count isn't a piece of information that gets cached. If page text is cached, the load can be smaller because the page text wouldn't have to be HTMLized. For uncached page text, the text gets HTMLized and that can increase load, but the forum posts query happens regardless, page text cached or not. Not sure if you are using debug mode, but if not, maybe try sticking the following in the config.php file, load a page, and follow the explain link. It'll show you stats on how the forum posts query performs, but it's subject to response variability. If you're up for it, try comparing several cached and uncached pages with explain, picking pages with about the same number of BB codes and images. It'd be interesting to see how the forum posts query performs on a board of your size.
Code:
// change xxx.xxx.xxx.xxx to your IP address if ($_SERVER['REMOTE_ADDR'] == 'xxx.xxx.xxx.xxx') { $config['Misc']['debug'] = true; } |
#27
|
|||
|
|||
Although VB is not caching the per forum post counts, the MYSQL database engine surely is during my testing (I have 4GB ram and set up mysql to cache quite a bit). It caches recently executed queries and when you reload the page, it will come up much quicker because of that. That is why I try to isolate it by going to old pages that likely haven't been viewed for a while. I did that both with and without the plugin turned on. I just don't think there is any way of getting around a large load placed by a query that scans the entire post table, though small improvements may be possible. It really makes perfect sense. I'm not sure if I'll be able to try out what you wrote above, but I'll let you know if I do. If you ever decide to try the storing of post counts in a separate table, let me know and I will definitely try that.
Thanks Again -vissa |
#28
|
|||
|
|||
Oh, didn't know you were referring to query cache and not vB cache. Not sure what you mean by 'scans the entire post table' though, as the query shouldn't be examining all the rows, but on a board of your size, it seems it's too many rows anyway. I think a separate table could have userid, forumid, and count, perhaps with forumid and count serialized, so at a minimum that'd be one row per user, which then could be a column in the user table instead, but there's still the updating to do. Not clear it's really worth it.
|
#29
|
|||
|
|||
The big difference in a separate table would be you would only be doing a single quick lookup based on user ID and forum (the adding would be done at post time) -- no scans or counting. With the current method, it has to scan each table entry and add them up (in my case, 1,000,000). So 1 vs 1,000,000 is quite a difference. Another way of looking at is with a separate table, in my case, there would be at most 11K entries (one for each user) with one row as a result. Currently there are 1M posts with possibly thousands of results needing to be counted on the fly.
Of course the current method is available now, and a separate table is more like an addon to the software than just a quick mod. Thanks for your help in any case and I'm sure some users will find it useful! -vissa |
#30
|
|||
|
|||
Hiya, this is a great mod and I really love it, only I got a weird problem with it on my board and was forced to disable it.
(Doing nothing other than disabling this mod fixed my problem, so I know it relates back to this particular plugin). If I wanted to use the Moderator options to move a thread from one forum to the other, in the drop-down list for Destination Forum, I was unable to see (and therefore unable to select) the forums beyond the main forum. Every other Mod Option worked correctly, only the 'Move' option was affected. I don't know if it was just my board, but maybe you can see if it does the same thing on yours? Thought I'd make you aware of it. Cheers ^^ Dee. |
#31
|
|||
|
|||
Using inline moderation or thread tools, I see all my forums listed under Destination Forum when going to move a thread. Maybe this mod conflicts with some other mod?
|
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|