m (Bot: Automated text replacement (-> +>)) |
No edit summary |
||
| (19 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
The following are seventeen improvements that you should be able to make to SMF regardless of your host, though only the first set will be possible anywhere. If the second set is not possible (outside of say, using Postgres over MySQL, in which case you probably do not need the second set), then I seriously suggest finding a new host. Hosts should provide you with shell access, access to crontab, php5 and InnoDB. An inability to do these things securely does not speak well of confidence in them. | |||
The following are | |||
---- | ---- | ||
| Line 14: | Line 6: | ||
====Move your uploaded avatars directory==== | ====Move your uploaded avatars directory==== | ||
In the administration panel, go to [[Attachments and Avatars]], and then go to [[Avatar Settings]]. | In the administration panel, go to [[Attachments and Avatars]], and then go to [[Attachments and Avatars#Avatar Settings|Avatar settings]]. | ||
For Upload avatars to... select: '''Specific directory...''' | For Upload avatars to... select: '''Specific directory...''' | ||
For Upload directory: put in the raw, publicly accessible server directory you want them added to ie /var/www/yoursite/docs/forums/avs | For Upload directory: put in the raw, publicly accessible server directory you want them added to ie /var/www/yoursite/docs/forums/avs | ||
So assuming /docs was your webroot, you would put /forums/avs for your upload URL. | So assuming /docs was your webroot, you would put /forums/avs for your upload URL. Do not do what I did and make it a subdirectory of your main avatars directory, SMF still handles it like an attachment directory for some reason so if someone uploads a .png avatar, someone else decides to use it and the first person replaces it with a .jpg avatar, the first will be deleted. | ||
The benefit of this borders on the ridiculous. Every single avatar load is | The benefit of this borders on the ridiculous. Every single avatar load is another php call, which loads a session, the user's settings and permissions, the board and its theme. In addition, two additional calls to the database are made to load the avatar itself, and to increment the view counter. So not only are you reducing the processor load on your server, but you are also reducing your database load. If five different avatars are displayed on a page, that's five additional php calls and dozens of database queries getting made. | ||
After you do this access index.php?action=manageattachments;sa=moveAvatars to use the hidden feature to move your avatars over. | After you do this access index.php?action=manageattachments;sa=moveAvatars to use the hidden feature to move your avatars over. | ||
| Line 42: | Line 34: | ||
SMF's custom index works by taking a hash of every available word, and then building an index of which words point to which messages. 'Small' means this is a 16 bit hash, 'Moderate' is 24 and 'Large' is a 32 bit hash. 'Large' is thus only two bytes larger per record than small is, plus an additional number of records based on the average number of unique words per post you have - which is not going to be a significant increase. The speed improvement you get for the additional ~40% space usage is well worth it. | SMF's custom index works by taking a hash of every available word, and then building an index of which words point to which messages. 'Small' means this is a 16 bit hash, 'Moderate' is 24 and 'Large' is a 32 bit hash. 'Large' is thus only two bytes larger per record than small is, plus an additional number of records based on the average number of unique words per post you have - which is not going to be a significant increase. The speed improvement you get for the additional ~40% space usage is well worth it. | ||
==== | ====Do not use post moderation on an active forum==== | ||
Where active is over a thousand posts a day or so. Apparently the query is rather slow, but it is not difficult to have a self policing forum. | Where active is over a thousand posts a day or so. Apparently the query is rather slow, but it is not difficult to have a self policing forum. | ||
====Disable the recent posts feature on the board index==== | ====Disable the recent posts feature on the board index==== | ||
Let people click a link if they want to see more than the last post they have access to, compiling that list is expensive especially if you have a lot of groups set up. Also I find it rather ugly, myself. This can be found under your Theme's settings, | Let people click a link if they want to see more than the last post they have access to, compiling that list is expensive especially if you have a lot of groups set up. Also I find it rather ugly, myself. This can be found under your Theme's settings, ''Number of recent posts to display on board index:'' - set to zero. | ||
====Run the [http://www.simplemachines.org/community/index.php?topic=212330.msg1667071#msg1667071 mark read for inactive users] script periodically==== | ====Run the [http://www.simplemachines.org/community/index.php?topic=212330.msg1667071#msg1667071 mark read for inactive users] script periodically==== | ||
| Line 58: | Line 50: | ||
====[http://www.simplemachines.org/community/index.php?topic=76249.0 Ben has a post about disabling features according to server load here] in the GUI for SMF 2.0 RC2==== | ====[http://www.simplemachines.org/community/index.php?topic=76249.0 Ben has a post about disabling features according to server load here] in the GUI for SMF 2.0 RC2==== | ||
Do not enable this on a shared server or VPS unless you know what you are doing or at least have some guidance, but this can be pretty dramatic. My members use 'show unread posts' or 'show unread replies' roughly thirty thousand times per ''day''. During high loads, even if they are caused by someone else, those sorts of requests are not helping. | |||
====Consider using database-driven sessions and offloading all attachments to Mediawiki==== | ====Consider using database-driven sessions and offloading all attachments to Mediawiki==== | ||
| Line 64: | Line 56: | ||
====Prune zero-post members==== | ====Prune zero-post members==== | ||
If they really want in, they can post next time. They just take up more and more space in your database, which will be especially notable if you follow tip #8. A simple way to do this is to make one postcount group have zero posts, another at one post, go to members -> search for members, sort by user ID (Ascending), check and start purging until you get to the last month or whatever is comfortable. You can go to Features & | If they really want in, they can post next time. They just take up more and more space in your database, which will be especially notable if you follow tip #8. A simple way to do this is to make one postcount group have zero posts, another at one post, go to members -> search for members, sort by user ID (Ascending), check and start purging until you get to the last month or whatever is comfortable. You can go to Features & Options -> Layout and Options, set members per page to 100 to make it faster (just do not go overboard and start deleting recent or genuinely active members). | ||
====Perform only necessary tasks, and spread them out (SMF 2.0 only)==== | ====Perform only necessary tasks, and spread them out (SMF 2.0 only)==== | ||
I just had this murder my forum, twice. While these do not necessarily slow down php, they can have a pretty dramatic effect on your forum if there are DNS issues, or simply the volume becomes so great that your server stops to send out thousands of emails. | I just had this murder my forum, twice. While these do not necessarily slow down php, they can have a pretty dramatic effect on your forum if there are DNS issues, or simply the volume becomes so great that your server stops to send out thousands of emails. | ||
The tasks can be found directly under Scheduled Tasks, in 'maintenance'. Be sure that approval notifications are disabled unless you really want them, and that optimize database is disabled if you are doing it with your own script (see mine below). The default execution time is 6 PM which, for a large forum, is really not the best. | The tasks can be found directly under Scheduled Tasks, in 'maintenance'. Be sure that approval notifications are disabled unless you really want them, and that optimize database is disabled if you are doing it with your own script (see mine below). The default execution time is 6 PM which, for a large forum, is really not the best. If you have a smaller (but still reasonably active) forum, you may want to spread them out by an hour or so - remember it's not enough for php to fire off emails to your mailserver, your mailserver also handles the emails, so do not have them running in immediate succession. | ||
====Cap the length of your threads==== | ====Cap the length of your threads==== | ||
| Line 78: | Line 70: | ||
This also has the effect of making individual threads less overwhelming. | This also has the effect of making individual threads less overwhelming. | ||
==== | ====Do not go crazy on on-line time==== | ||
In Features and Options -> General, the online time threshold defaults to 15 minutes, as in vBulletin. Some people like to set this rather high to give the illusion of an extremely active forum, but people are already wising to this. In addition, you get diminishing returns, and the larger it is, the more time your forum will spend processing this extremely active table. It is also quite annoying - I had to modify the Users Online Today mod, simply because looking through hundreds of names is annoying. | In Features and Options -> General, the online time threshold defaults to 15 minutes, as in vBulletin. Some people like to set this rather high to give the illusion of an extremely active forum, but people are already wising to this. In addition, you get diminishing returns, and the larger it is, the more time your forum will spend processing this extremely active table. It is also quite annoying - I had to modify the Users Online Today mod, simply because looking through hundreds of names is annoying. | ||
====If you really want, disable tracking daily page views==== | ====If you really want, disable tracking daily page views==== | ||
in the same section as #4 there. My tepid enthusiasm is shared by others with highly tuned, CPU intensive forums - you do | in the same section as #4 there. My tepid enthusiasm is shared by others with highly tuned, CPU intensive forums - you do ''not'' need to do this to have a solid-performing forum. | ||
It is an additional query on each page load, however, and if it becomes an issue and like most of us, you want to keep it, be sure to convert the underlying table (log_actions) to InnoDB as described in the next part of this guide. | |||
Follow [http://wiki.simplemachines.org/smf/Performance_enhancements_part_2 this link] for intermediate, and advanced, help with speeding up SMF. | |||
[[Category:Performance_enhancements]][[Category:As_an_administrator]] | |||
[[Category: | |||
Latest revision as of 12:26, 11 February 2015
The following are seventeen improvements that you should be able to make to SMF regardless of your host, though only the first set will be possible anywhere. If the second set is not possible (outside of say, using Postgres over MySQL, in which case you probably do not need the second set), then I seriously suggest finding a new host. Hosts should provide you with shell access, access to crontab, php5 and InnoDB. An inability to do these things securely does not speak well of confidence in them.
Basic Improvements
Just about anyone can make use of these optimizations, regardless of how much control you have over your server. The first few options here can have an extremely dramatic effect on your server's performance, I've sorted them roughly in order of potential impact.
Move your uploaded avatars directory
In the administration panel, go to Attachments and Avatars, and then go to Avatar settings.
For Upload avatars to... select: Specific directory... For Upload directory: put in the raw, publicly accessible server directory you want them added to ie /var/www/yoursite/docs/forums/avs
So assuming /docs was your webroot, you would put /forums/avs for your upload URL. Do not do what I did and make it a subdirectory of your main avatars directory, SMF still handles it like an attachment directory for some reason so if someone uploads a .png avatar, someone else decides to use it and the first person replaces it with a .jpg avatar, the first will be deleted.
The benefit of this borders on the ridiculous. Every single avatar load is another php call, which loads a session, the user's settings and permissions, the board and its theme. In addition, two additional calls to the database are made to load the avatar itself, and to increment the view counter. So not only are you reducing the processor load on your server, but you are also reducing your database load. If five different avatars are displayed on a page, that's five additional php calls and dozens of database queries getting made.
After you do this access index.php?action=manageattachments;sa=moveAvatars to use the hidden feature to move your avatars over.
SMF 2.0 RC3 Update (June 16th)
the url is apparently now index.php?action=admin;area=manageattachments;sa=moveAvatars - thank you Spuds : )
Disable hostname lookups
This is located in Features and Options -> Layout and Options or Server Settings -> General in RC1 and on. If you leave hostname lookups on, every single page access carries with it a reverse DNS query. If your host's RDNS is having issues or goes down, you are going to hear about the lag from your members.
Enable (or disable) gzip compression
This is located in Server Settings -> Feature Configuration. This has the greatest benefit when combined with #1, particularly for dialup users.
Note: Your webserver configuration may render this irrelevant. If your webserver compresses the type of data you use to serve your webpages, you should specifically disable this, as the webserver can better handle it.
Tune topics, members, and posts per page
In Posts and Topics -> Topic Settings. Setting this low can have a detrimental affect on your forum's raw activity, however, at least it did on mine. If people click more, they make more requests, after all, and get more frustrated. I use fifty topics per page and twenty-five posts per page, which seems to be close to ideal. Disabling participation icons will also reduce load a slight bit, but some may find this annoying.
If you are going to enable search, and are not or cannot use Sphinx, use a Large Custom Index
SMF's custom index works by taking a hash of every available word, and then building an index of which words point to which messages. 'Small' means this is a 16 bit hash, 'Moderate' is 24 and 'Large' is a 32 bit hash. 'Large' is thus only two bytes larger per record than small is, plus an additional number of records based on the average number of unique words per post you have - which is not going to be a significant increase. The speed improvement you get for the additional ~40% space usage is well worth it.
Do not use post moderation on an active forum
Where active is over a thousand posts a day or so. Apparently the query is rather slow, but it is not difficult to have a self policing forum.
Disable the recent posts feature on the board index
Let people click a link if they want to see more than the last post they have access to, compiling that list is expensive especially if you have a lot of groups set up. Also I find it rather ugly, myself. This can be found under your Theme's settings, Number of recent posts to display on board index: - set to zero.
Run the mark read for inactive users script periodically
The log_topics, log_boards, and log_mark_read tables are not the best designs, and for some unlucky folks end up dominating their database. Pruning them can help.
Do you really need that many boards?
I tend to see this rather often and the answer is almost always no. Too many boards actually reduces your forum's activity, for one, but in the case of optimization here, each and every board takes up resources on the relatively common index load, as well as space for the log_boards and log_mark_read tables, with an amount that grows for each new member you gain.
Do you really need the calendar?
When enabled, SMF looks for an event on each and every thread load - there are ways to make it more efficient but in general it's not an often-used feature.
Ben has a post about disabling features according to server load here in the GUI for SMF 2.0 RC2
Do not enable this on a shared server or VPS unless you know what you are doing or at least have some guidance, but this can be pretty dramatic. My members use 'show unread posts' or 'show unread replies' roughly thirty thousand times per day. During high loads, even if they are caused by someone else, those sorts of requests are not helping.
Consider using database-driven sessions and offloading all attachments to Mediawiki
There is an awesome MediaWiki extension , though some minor tweaks are needed for 1.13 - see the talk page. Combine with hotlinking protection and you can have a slightly more efficient file handling system. It is likely more difficult for your members to use, however.
Prune zero-post members
If they really want in, they can post next time. They just take up more and more space in your database, which will be especially notable if you follow tip #8. A simple way to do this is to make one postcount group have zero posts, another at one post, go to members -> search for members, sort by user ID (Ascending), check and start purging until you get to the last month or whatever is comfortable. You can go to Features & Options -> Layout and Options, set members per page to 100 to make it faster (just do not go overboard and start deleting recent or genuinely active members).
Perform only necessary tasks, and spread them out (SMF 2.0 only)
I just had this murder my forum, twice. While these do not necessarily slow down php, they can have a pretty dramatic effect on your forum if there are DNS issues, or simply the volume becomes so great that your server stops to send out thousands of emails.
The tasks can be found directly under Scheduled Tasks, in 'maintenance'. Be sure that approval notifications are disabled unless you really want them, and that optimize database is disabled if you are doing it with your own script (see mine below). The default execution time is 6 PM which, for a large forum, is really not the best. If you have a smaller (but still reasonably active) forum, you may want to spread them out by an hour or so - remember it's not enough for php to fire off emails to your mailserver, your mailserver also handles the emails, so do not have them running in immediate succession.
Cap the length of your threads
This is one of those things that ought to be a setting - even vBulletin is known for choking on large threads, look up rpg.net's motivational poster history. Large threads mean there is a large result set for further instructions in the query to prune from, and if a thread is too disproportionally large, even browsing the thread will result in using table scans instead of the index - a very bad situation indeed.
30k is what I use for Elliquiy, and Ben uses 25k for Red and White Kop. Keep in mind, though, that we are both running finely tuned dedicated servers with two hard disks, two cores, and 4gb of RAM. You may want to cap thread length closer to 1k posts.
This also has the effect of making individual threads less overwhelming.
Do not go crazy on on-line time
In Features and Options -> General, the online time threshold defaults to 15 minutes, as in vBulletin. Some people like to set this rather high to give the illusion of an extremely active forum, but people are already wising to this. In addition, you get diminishing returns, and the larger it is, the more time your forum will spend processing this extremely active table. It is also quite annoying - I had to modify the Users Online Today mod, simply because looking through hundreds of names is annoying.
If you really want, disable tracking daily page views
in the same section as #4 there. My tepid enthusiasm is shared by others with highly tuned, CPU intensive forums - you do not need to do this to have a solid-performing forum.
It is an additional query on each page load, however, and if it becomes an issue and like most of us, you want to keep it, be sure to convert the underlying table (log_actions) to InnoDB as described in the next part of this guide.
Follow this link for intermediate, and advanced, help with speeding up SMF.
