MyBB Community Forums

(2011-06-20, 02:26 AM)labrocca Wrote: [ -> ]The cache system was not improved at all. It's the exact same as 1.4x as far as I know.

Of course the cache system is the same, we never planned to change it. Anything but a rewrite of it would probably cause more problems.

Yes, you've told me areas where cache could be used and it isn't. I'm more than happy to make the changes, and 1.6.4 introduces baby-step performance increases too which should help a little bit.

I'm sorry Tomm to be naggy about it. It's something I feel strongly about. Realistically it's something that's costing me money. I know that's not your concern but I do know that improvements to the cache system would benefit all MyBB users.

I think since the 1.6x release we see a lot more performance threads about hosts blaming MyBB usage. And certainly it could be poor plugins or other factors but those with Big Boards and dedicated servers see directly the issues.

When you're doing millions of queries a day it's easy to spot the problems.

Quote: Anything but a rewrite of it would probably cause more problems.

A rewrite isn't necessary. There are a couple weak points in functions that do a query instead of using the cache. Functions which are constant like is_moderator() and it's not correctly using the moderator cache.

If you ever want more access and data to support what I'm saying I'm happy to spend a day with you in an IM chat or Skype.

I know the team is busy but I'm hoping one day you'll go over some things with me.

(2011-06-05, 09:05 AM)Wiz01 Wrote: [ -> ]I bet, there's something with mybb...
There's some popular forums on my board, where very hard to enter, bacause the high number of threads/posts. I think those forums are generate the high load.
Except these forums, my board is super fast everywhere (at high load too).

forumdisplay:
Generated in 3.3726420 seconds (2.04% PHP / 97.96% MySQL)
SQL Queries: 31 / Global Parsing Time: 0.0901380 / Memory Usage: 5 MB
PHP version: 5.2.17 / Server Load: 2.42 / GZip Compression: Enabled

I have found that a high number of posts in a forum does cause performance "problems". On my server i keep the main forum around a million posts. Archiving only around 300K posts already gained a significant overall performance boost.

So you might consider archiving a bit of your popular forums..

And do the innodb tweak from labrocca.

I've done a lot of things. xcache, innodb (users table), server optimizations etc...
Nothing helped.

My forum is slow on localhost too!
Maybe my db is damaged.

I'm waiting for the next mybb update and i hope it will help a little bit. I can't do anything else.

@labrocca - it might not be my concern that it's costing you money, but it is my concern when people start to dislike the product.

I see what you mean - it's not improving the cache system itself but actually using it wherever it can be used. I'll take a look at the is_moderator function over the next few days and update it ready for 1.6.4.

@Wiz01 - InnoDB can be used throughout MyBB's database schema and you'll easily see the difference in performance, especially with MySQL >= 5.5. There are also other enhancements such as changing utf8_general_ci fields to utf8_bin for some non-case sensitive queried fields, Sphinx search, pre-parsing and a collection of other things you can try. If all that fails, maybe it's better to take a look at a different server.

Thank you for the suggestions.

You can save six queries by disabling the URLs section of Google SEO. That alone has saved me at least six queries and has definitely sped up my site.

I've tested it and i didn't see any difference.

(2011-06-22, 10:33 PM)labrocca Wrote: [ -> ]200-300% from 5.0->5.5

damn! thanks..
I will do it tonight.. and see what's impact after upgrading MySQL

---

MySQL Community Server 5.5.13 has been released
Posted by: hery ramilison ()
Date: May 31, 2011 03:44PM

Dear MySQL users,

MySQL 5.5.13 is a new version of the 5.5 production release of the
world's most popular open source database. MySQL 5.5.13 is recommended
for use on production systems.

MySQL 5.5 includes several high-impact enhancements to improve the
performance and scalability of the MySQL Database, taking advantage of
the latest multi-CPU and multi-core hardware and operating systems. In
addition, with release 5.5, InnoDB is now the default storage engine for
the MySQL Database, delivering ACID transactions, referential integrity
and crash recovery by default.

MySQL 5.5 also provides a number of additional enhancements including:

- Significantly improved performance on Windows, with various Windows
specific features and improvements
- Higher availability, with new semi-synchronous replication and
Replication Heart Beat
- Improved usability, with Improved index and table partitioning,
SIGNAL/RESIGNAL support and enhanced diagnostics, including a new
Performance Schema monitoring capability.

For a more complete look at what's new in MySQL 5.5, please see the
following resources:

MySQL 5.5 is GA, Interview with Tomas Ulin:

http://dev.mysql.com/tech-resources/inte...ql-55.html

Documentation:

http://dev.mysql.com/doc/refman/5.5/en/m...shell.html


Whitepaper: What's New in MySQL 5.5:


http://dev.mysql.com/why-mysql/white-pap...sql-55.php

If you are running a MySQL production level system, we would like to
direct your attention to MySQL Enterprise Edition, which includes the
most comprehensive set of MySQL production, backup, monitoring,
modeling, development, and administration tools so businesses can
achieve the highest levels of MySQL performance, security and uptime.

http://mysql.com/products/enterprise/

For information on installing MySQL 5.5.13 on new servers, please see
the MySQL installation documentation at

http://dev.mysql.com/doc/refman/5.5/en/installing.html

For upgrading from previous MySQL releases, please see the important
upgrade considerations at:

http://dev.mysql.com/doc/refman/5.5/en/upgrading.html

MySQL Database 5.5 is available in source and binary form for a number
of platforms from our download pages at:

http://dev.mysql.com/downloads/mysql/

Not all mirror sites may be up to date at this point in time, so if you
can't find this version on some mirror, please try again later or choose
another download site.

We welcome and appreciate your feedback, bug reports, bug fixes,
patches, etc.:

http://forge.mysql.com/wiki/Contributing

The following section lists the changes in the MySQL source code since
the previous released version of MySQL 5.5. It may also be viewed
online at:

http://dev.mysql.com/doc/refman/5.5/en/news-5-5-13.html

Enjoy!

Changes in MySQL 5.5.13 :

Note:

Very old (MySQL 4.0) clients are not working temporarily due to a
problem discovered after the release of MySQL 5.5.12. We are
looking at fixing the problem.

Bugs fixed:

* InnoDB Storage Engine: If the server crashed while an XA
transaction was prepared but not yet committed, the
transaction could remain in the system after restart, and
cause a subsequent shutdown to hang. (Bug #11766513, Bug
#59641)

* InnoDB Storage Engine: Similar problem to the foreign key
error in bug #11831040 / 60196 / 60909, but with a different
root cause and occurring on Mac OS X. With the setting
lower_case_table_names=2, inserts into InnoDB tables covered
by foreign key constraints could fail after a server restart.

* Partitioning: The internal get_partition_set() function did
not take into account the possibility that a key specification
could be NULL in some cases. (Bug #12380149)

* Partitioning: When executing a row-ordered retrieval index
merge, the partitioning handler used memory from that
allocated for the table, rather than that allocated to the
query, causing table object memory not to be freed until the
table was closed. (Bug #11766249, Bug #59316)

* Replication: A spurious error malformed binlog: it does not
contain any Format_description_log_event... was generated when
mysqlbinlog was invoked using --base64-output=decode-row and
--start-position=pos, where pos is a point in the binary log
past the format description log event. However, there is
nothing unsafe about not printing the format description log
event, so the error has been removed for this case. (Bug
#12354268)

* Replication: Typographical errors appeared in the text of
several replication error messages. (The word "position" was
misspelled as "postion".) (Bug #11762616, Bug #55229)

* Assignments to NEW.var_name within triggers, where var_name
had a BLOB or TEXT type, were not properly handled and
produced incorrect results. (Bug #12362125)

* XA COMMIT could fail to clean up the error state if it
discovered that the current XA transaction had to be rolled
back. Consequently, the next XA transaction could raise an
assertion when it checked for proper cleanup of the previous
transaction. (Bug #12352846)

* An internal client macro reference was removed from the
client_plugin.h header file. This reference made the file
unusable. (Bug #60746, Bug #12325444)

* The server consumed memory for repeated invocation of some
stored procedures, which was not released until the connection
terminated. (Bug #60025, Bug #11848763)

* The server did not check for certain invalid out of order
sequences of XA statements, and these sequences raised an
assertion. (Bug #59936, Bug #11766752, Bug #12348348)

* With the conversion from GNU autotools to CMake for
configuring MySQL, the USE_SYMDIR preprocessor symbol was
omitted. This caused failure of symbolic links (described at
Section 7.11.3.1, "Using Symbolic Links"). (Bug #59408, Bug
#11766320)

* The incorrect max_length value for YEAR values could be used
in temporary result tables for UNION, leading to incorrect
results. (Bug #59343, Bug #11766270)

* In Item_func_in::fix_length_and_dec(), a Valgrind warning for
uninitialized values was corrected. (Bug #59270, Bug
#11766212)

* In ROUND() calculations, a Valgrind warning for uninitialized
memory was corrected. (Bug #58937, Bug #11765923)

* Valgrind warnings caused by comparing index values to an
uninitialized field were corrected. (Bug #58705, Bug
#11765713)

* LOAD DATA INFILE errors could leak I/O cache memory. (Bug
#58072, Bug #11765141)

* For LOAD DATA INFILE, multibyte character sequences could be
pushed onto a stack too small to accommodate them. (Bug
#58069, Bug #11765139)

* Internal Performance Schema header files were unnecessarily
installed publicly. (Bug #53281)

* On Linux, the mysql client built using the bundled libedit did
not read ~/.editrc. (Bug #49967, Bug #11757855)

* The optimizer sometimes incorrectly processed HAVING clauses
for queries that did not also have an ORDER BY clause. (Bug
#48916, Bug #11756928)

* PROCEDURE ANALYZE() could leak memory for NULL results, and
could return incorrect results if used with a LIMIT clause.
(Bug #48137, Bug #11756242)

* With DISTINCT CONCAT(col,...) returned incorrect results when
the arguments to CONCAT() were columns with an integer data
type declared with a display width narrower than the values in
the column. (For example, if an INT(1) column contain 1111.)
(Bug #4082)

Hery Ramilison
MySQL/ORACLE Release Engineering Team
http://forums.mysql.com/read.php?3,421981

Sorry for bumping this old thread.
I moved to a dedi, and my forum is still slow... Pfff...

I really really hope the next mybb update will solve the problem...