Twenty-four things you can do to make SMF go faster (Updated June 16th, 2010)

Started by Vekseid, February 16, 2009, 06:29:50 AM

Previous topic - Next topic

MartyHunter

I just read the opening post on this thread, with great interest i might add! Then I noticed it's around 14 years old!! Is it still relevant today?
thanks

shawnb61

Although some of the technical stuff is dated (e.g., I wouldn't suggest running PHP5...), most of this is still valid.  Especially the reminders to turn off various functions you don't need, and try not to overload pages.  Mind your page size, # of boards, etc.

Several of these items are baked into SMF 2.1, e.g., #1 Avatars & #8 Mark Boards as Read.  So you don't need to take any special action, it's already done for you.  (Although you do need to enable the Mark Boards as Read option under Admin | Maintenance | Scheduled Tasks, it's not on by default.)

Note there have been some significant performance improvements in every version of PHP, as well as in the latest MySQL, 8.0.  The more current you are, the better off you are performance-wise.  Note also that queries that span across collations or engines take a performance hit.

So, if you can, at the time of this post, I suggest:
- SMF 2.1
- MySQL 8.0
- PHP 8.2
- Making sure all your collations are consistent, utf8_general_ci
- Making sure all your tables are using InnoDB
- For high traffic, I'd suggest researching your caching options

If performance is of utmost concern, consider postgresql. (Careful, though, you may find some mods do not support pg.)

Finally, keep in mind that the original post was intended for very high volume forums.  For most forums, out-of-the-box is designed to be sufficient...
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

MartyHunter

Thanks very much, I don't understand some of it ("collations") but will go learn.

szinski

Quote from: shawnb61 on June 18, 2023, 01:04:15 AMMaking sure all your collations are consistent, utf8_general_ci
Does SMF 2.1.4 support utf8mb4_general_ci since that is the "fixed" 4-byte UTF-8 that MySQL uses?

My tables are currently using utf8mb3_general_ci.


Arantor

There are workarounds to convert 4 byte UTF-8 into entity form to prevent the need for converting the database. (Been there since... 2.0.10 I want to say)

I don't think full blown UTF-8 mb4 support exists yet (and it's surprisingly not as trivial to implement as you might think), not least of which forcing the database to convert.
Holder of controversial views, all of which my own.

Advertisement: