Version: 1.00, by Jujubee
Developer Last Online: May 2009
Version: 2.2.x
Rating:
Released: 06-21-2002
Last Update: Never
Installs: 34
No support by the author.
Hack name: Deferred Threadviews Version: 1.00 Purpose:
To reduce server load by not updating the view count on every page view but instead keeping the it in memory and writing to the db only occasionally. Functions:
? Logs threadviews to a temporary table, and periodically commits data to the thread table.
? Frequency of writes controlled by server load and a random number.
? Includes optional email notification. vB version tested on: 2.2.6 PHP version tested on: 4.2.0 Acknowledgements: Thanks to MattR for the "store threadviews as list of non-unique ids and use count(*)" suggestion that removed 1 query per pageview.
The updating of threadviews has been identified as a main cause of high server loads. This hack basically writes threadviews to a HEAP table (i.e. temporary table residing in memory) and will only update the thread count when the load is below a specified value and a random # value is hit.
(The impetus for this hack was an email from my host: They threatened to boot me off my server due to CPU usage "abuse", so as part of a larger effort, I decided to write this hack. *crossing fingers*)
SUMMARY of changes:
1) Set 1 Admin CP option
2) Create MySQL table
3) Insert code into SHOWTHREAD.PHP
The code will optionally send you an email every time the threadviews are committed to the thread table.
More details are in the text file.
This is what the email you'll get looks like:
Quote:
2395 Total Views (original number of write queries)
170 Threads (new number of write queries)
93% of Writes Avoided [2225 avoided]
14:1 Original Writes vs. Consolidated Writes
Version History:
0.9 - Initial Release
0.91 - removed need for reading of temp table before writing to it (thanks to MattR). Note that if you've been using 0.9, you must re-create the my_threadviews table as it's structure has changed.
0.92 - added reporting of the ratio of Original Writes vs. Consolidated Writes. Use this to help in tweaking the frequency of updates. If the ratio is low, (e.g. 2:1, 5:1, etc) it probably means updates are occuring too often. (The ratio will also be low if you have many separate threads that are viewed a small number of times.)
1.00 - No code changes. Changed version to 1.00 since it's been stable for the past 2 months.
Show Your Support
This modification may not be copied, reproduced or published elsewhere without author's permission.
Originally posted by Smoothie What would be the limit of simultaneous users before you would notice any difference?
It's hard to say -- depends on what their doing, and if you're on a shared server, it depends on how busy the server is. If you're load is below 2 all the time, you shouldn't worry about this hack too much.
Originally posted by Jujubee
So this hack helps for boards with many simultaneous users. If you've got 20 people browsing, you're not going to see any difference.
How about 130+ ? I'm trying to decide if the issue of a server crash is worth the speed increase. (e.g. if the server dies prior to this hack actually writing to a 'real' table, the counts will be lost?).
Originally posted by 1stTrade does this hack reduce also the server-traffic ?
I don?t care about the serverload, but traffic is a important thing to me.
No, the traffic isn't affected in any way.
Quote:
How about 130+ ? I'm trying to decide if the issue of a server crash is worth the speed increase. (e.g. if the server dies prior to this hack actually writing to a 'real' table, the counts will be lost?).
I'm pretty sure it'll make a big difference at 130+. But, yes, if the server dies, you'll lose the threadviews since the last update. The way I see it, if the server is crashing, you've got bigger problems to worry about than thread views.
We are loping along at 400 users on line and it seems to be working great, the updates are happening every 1-2 minutes with a savings of from 7-40%...I am not sure what ideal is
Originally posted by alexi We are loping along at 400 users on line and it seems to be working great, the updates are happening every 1-2 minutes with a savings of from 7-40%...I am not sure what ideal is
Since you're on a dedicated server you can afford to have more bulk updates. I'd suggest cranking up the second number (default is 600) in the mt_rand function so that updates take place less often. 40% is ok, but 80% would be better.
Deferred Threadviews v1.00 (to reduce server load) Details »»
About Developer
Visit Web Site
No support by the author.
06-23-2002, 01:51 AM
