Version: 1.00, by Xenon
Developer Last Online: Oct 2023
Version: 2.2.x
Rating:
Released: 12-19-2002
Last Update: Never
Installs: 94
No support by the author.
Ok, what this Hack does is it reduces the ammount of queries on forumhome by caching the moderatorlist and by optimizing most of the queries used on index.php
I'd really appreciate getting feedback how it reduces serverload on greater boards
On an unhacked vb index.php (pm enabled accesmask disabled) it reduces the ammount of queries from 19 to 15
my experiments have shown, that the queries are faster than the normal ones, too....
Show Your Support
This modification may not be copied, reproduced or published elsewhere without author's permission.
Originally posted by Xenon @Squawell: hmm, couldn't be normally the login/out feature are not touched by my hack.
Also it works perfect for all.
maybe you've changed the index on a piece of code where you shouldn't..
collidation with another hack you've installed propably?
in fact...it not just effect the login function.. when i add or edit the new forum the main page also didnt show up too(the change part).....so strange...it only happen to userid=1 user.....i try another user account its normal and work perfect.....so that make me confuse what cause that??
by the way i dont change anything in index.php i use the original index.php......
maybe your cookie is corrupted.
i know it can't happen because the part of code is not affected by my hack, at least not if you've done everything correct.
the last thing is normal, whenever you add or edit a forum on forumhome or add a moderator or something like that, it will just change after the cache has been updated, so whenever one new post has been made.
I had a problem with this hack, when we were editing some templates for forumhome, they weren't updating on forumhome, so you can't see the changes, and when someone could see the changes, someone else couldn't...all in all I couldn't risk any problems and I just uninstalled the caching part of the hack..
i just read your instructions to see if this hack would work for my forum.
but this query is much slower then the original ones:
PHP Code:
SELECT COUNT(*) AS messages,
SUM(IF(dateline>$bbuserinfo[lastvisit] AND folderid=0,1,0)) AS newpm,
SUM(IF(messageread=0 AND folderid=0,1,0)) AS unreadpm
FROM privatemessage WHERE userid=$bbuserinfo[userid] $ignoreusers
you replaced three fast queries which reads the values from index by one slow query which crawls through the whole datafile. i did a quick test on my privatemessage table (1.2M messages), your query took 2.2 seconds to complete, the original ones took 0.2 seconds all together
I've updated my last post due to an cut'n'paste error...
Quote:
Originally posted by Boofo Is there any way to make the one query faster?
you have to run the original 3 queries to make it faster.
it's a good idea trying to decrease the number of queries, but it won't help anything if you replace some small and fast queries with one big and slow query.
Originally posted by pwr_sneak I've updated my last post due to an cut'n'paste error...
you have to run the original 3 queries to make it faster.
it's a good idea trying to decrease the number of queries, but it won't help anything if you replace some small and fast queries with one big and slow query.
Matt runs Sybase instead of MySQL, you can't compare this.
MySQL optimizes count(*) queries because it keeps an extra counter in its index-files when using MyISAM Tables. The Index should be read from RAM on heavy-used tables. This kind of queries as well as MAX(indexed-column) can be answered without I/O which makes it really fast.
this sum(...,1,0) trick has to read every row from the table or just every entry in its index if its condition matches from index. so this is always slower than reading three single values with three single queries.
Originally posted by pwr_sneak
Matt runs Sybase instead of MySQL, you can't compare this.
MySQL optimizes count(*) queries because it keeps an extra counter in its index-files when using MyISAM Tables. The Index should be read from RAM on heavy-used tables. This kind of queries as well as MAX(indexed-column) can be answered without I/O which makes it really fast.
this sum(...,1,0) trick has to read every row from the table or just every entry in its index if its condition matches from index. so this is always slower than reading three single values with three single queries.
Quote:
Originally posted by FireFly I did that Matt.
PHP Code:
$allpm=$DB_site->query_first("SELECT COUNT(*) AS messages,
SUM(IF(dateline>$bbuserinfo[lastvisit] AND folderid=0,1,0)) AS newpm,
SUM(IF(messageread=0 AND folderid=0,1,0)) AS unreadpm
FROM privatemessage WHERE userid=$bbuserinfo[userid]$ignoreusers");
Well I copied it from somewhere, don't really remember right now. But the problem is the query is slower for users with lots and lots of PM's (like myself), but considering most people don't I thought it would be wiser to just use that one query.
Chen already said one query is slower, however, this only occurs when you have a considerable amount of PM's stored.
So, i think your assumption is not correct.
It is faster for users with few pm's.
Optimizing Forumhome Details »»
About Developer
No support by the author.
01-25-2003, 11:52 AM
