Special PHP and/or MySQL Settings

  • You must be getting sick of me at this point. :)

    In any case, with our present software, vBulletin, we have configured MySQL and PHP with their special optimizations.

    Do we need any of that with Burning Board or just revert to default -- or does it matter?

    Inquiring minds want to know.

    Peace,
    Gene

  • OK, here's the text:


    1. Upgrade MySQL 5.1.39. Backup your databases prior to mysql upgrades where possible using mysqldump via ssh telnet and not via admincp backup options or phpmyadmin which in some cases of large databases can result in incomplete backups!

    2. Edit mysql server's /etc/my.cnf and place the following mysql server settings in /etc/my.cnf and restart mysql server afterwards. Make sure to restart mysql server everytime you make changes to your my.cnf for the changes to take effect.


    Quote:[mysqld]
    skip-name-resolve
    back_log = 50
    skip-innodb
    max_connections = 800
    key_buffer_size = 800M
    myisam_sort_buffer_size = 128M
    join_buffer_size = 2M
    read_buffer_size = 2M
    sort_buffer_size = 4M
    table_definition_cache = 4096
    table_open_cache = 10000
    thread_cache_size = 768
    wait_timeout = 60
    connect_timeout = 10
    tmp_table_size = 128M
    max_heap_table_size = 128M
    max_allowed_packet = 128M
    net_buffer_length = 16384
    max_connect_errors = 100000
    thread_concurrency = 16
    concurrent_insert = 2
    table_lock_wait_timeout = 30
    read_rnd_buffer_size = 2M
    bulk_insert_buffer_size = 16M
    query_cache_limit = 6M
    query_cache_size = 192M
    query_cache_type = 1
    query_prealloc_size = 262144
    query_alloc_block_size = 65536
    range_alloc_block_size = 4096
    transaction_alloc_block_size = 8192
    transaction_prealloc_size = 4096
    default-storage-engine = MyISAM
    max_write_lock_count = 8

    [mysqld_safe]
    nice = -10
    open_files_limit = 8192

    [mysqldump]
    quick
    max_allowed_packet = 64M

    [myisamchk]
    key_buffer_size = 800M
    sort_buffer_size = 32M
    read_buffer_size = 16M
    write_buffer_size = 16M
    If you get mysql server gone away error messages, then keep increasing wait_timeout value in my.cnf by 60 second increments, then restart mysql after my.cnf changes for it to take effect. Test for a few days and see if you get less or eliminate that error message. If it still occurs, then keep repeating the 60 second increment until the message goes away. Each vB forum and server will have different optimal wait_timeout values depending on your vB forum traffic patterns and server hardware specifications.

    3. Xcache and eaccelerator do the same task, so having both enabled might cause problems, please remove Eaccelerator from both servers if they're installed (check phpinfo.php url of yours to see) and instead install Xcache v1.2.2 http://xcache.lighttpd.net/wiki/Release-1.2.2 which seems to be a bit faster than APC Cache -http://www.vbulletin.com/forum/showthread.php?t=213267. Xcache site http://xcache.lighttpd.net/, documentation http://trac.lighttpd.net/trac/wiki/Docs and forumshttp://forum.lighttpd.net/forum/4

    Remember to set in php.ini the values for xcache.size to 256M and for xcache.count to 8.

    Install the xcache admin end and monitor how much memory is used and available and adjust accordingly.

    Now install memcached on http://www.vbulletin.com/forum/showthread.php?t=225335 and enable memcached datastore caching for each vB forum (vB 3.7.x and higher only supported). In vB config.php file these entries


    Code: // ****** DATASTORE CACHE CONFIGURATION *****
    // Here you can configure different methods for caching datastore items.
    // vB_Datastore_Filecache - to use includes/datastore/datastore_cache.php
    // vB_Datastore_APC - to use APC
    // vB_Datastore_XCache - to use XCache
    // vB_Datastore_Memcached - to use a Memcache server, more configuration below
    // $config['Datastore']['class'] = 'vB_Datastore_Filecache';

    // ******** DATASTORE PREFIX ******
    // If you are using a PHP Caching system (APC, XCache, eAccelerator) with more
    // than one set of forums installed on your host, you *may* need to use a prefix
    // so that they do not try to use the same variable within the cache.
    // This works in a similar manner to the database table prefix.
    // $config['Datastore']['prefix'] = '';
    the 2 lines you need to modify by uncommenting (removing // from beginning of line) and changing their values

    from


    Code:// $config['Datastore']['class'] = 'vB_Datastore_Filecache';
    // $config['Datastore']['prefix'] = '';
    to


    Code:$config['Datastore']['class'] = 'vB_Datastore_Memcached';
    $config['Datastore']['prefix'] = 'forum1';
    change forum1 to whatever you want but it must be unqiue to each of your vB forums installed on same server so forum1, forum2, forum3, forum4, forum5 for 5 different vB forums' config files.

    4. Upgrade to vB 3.0.17 http://www.vbulletin.com/forum/showthread.php?t=209720 if you're on vB 3.0.xx or upgrade to vB 3.5.8http://www.vbulletin.com/forum/showthread.php?t=221903 if you're on vB 3.5.x. Or if on vB 3.6.x, upgrade to vB 3.6.12 PL2http://www.vbulletin.com/forum/showthread.php?t=319572.

    But ultimately, it's best to upgrade to the latest stable vB 3.8.4 PL1 http://www.vbulletin.com/forum/showthread.php?t=319572 or at least 3.7.6 PL1http://www.vbulletin.com/forum/showthread.php?t=319572. You can use my method of upgrading outlined at http://www.vbulletin.com/forum/showthread.php?t=187770 which is essentially same in that you make a copy of your live database and import it into a new empty database and point vB 3.7.0 config.php to that new imported database name, so you essentially do an upgrade on a copy of your database, leaving original database intact in case of any problems. This method also allows you to run the original database on a different directory so to run both original forum/database along side the upgraded forum/database so you can easily revert all changed templates on upgraded forum and then using old forum/database transfer or port your custom style/images etc to the new upgrade database.

    Read each versions listed thread to understand the changes that have occured etc.

    5. If you just upgraded to vB 3.5.x/3.6.x try to disable these 4 options:

    Admin CP -> vBulletin Options -> Forums Home Page Options -> Display Logged in Users?

    Admin CP -> vBulletin Options -> Forum Display Options (forumdisplay) -> Show Users Browsing Forums

    Admin CP -> vBulletin Options -> Thread Display Options -> Show Users Browsing Thread

    Admin CP -> vBulletin Options -> Message Searching Options -> Automatic Similar Thread search

    Or relevant sections in vB 3.7.x or 3.8.x

    6. If you have split web + db servers, ensure web server has dual gigabit 1000Mbps speed network cards as outlined athttp://www.vbulletin.org/forum/showthread.php?t=111191. Read the importance of faster 1000Mbps/Gigabit network here http://www.bigdbahead.com/?p=119

    7. Tune your hard drive/partitions with native.

    Einmal editiert, zuletzt von Gene Steinberg (21. Oktober 2009 um 23:59)

    • Offizieller Beitrag

    Phew! That's a lot to read. Our chief developer will look over that tomorrow. ^^

    But WBB 3 was designed to be installable by everybody, not only by programmers, so i don't think that much of that will be relevant for installing WBB.

    What i can say now is that you'll need Apache 2 with PHP 5.2 (possibly the latest version), no eAccelerator, Suhosin settings high, Safe Mode off, but read all that in the installation guide i already mentioned in the other thread.

    Direct jump to the matching chapter:
    http://www.woltlab.org/dl/wbb3/readme.html#chapter2

    You know, we try to make simple to use software, not to overwhelm our users with loads of functions and settings …

  • Well, you can easily install vBulletin as well, well it's all copying files and going through a setup assistant. But all those settings are supposedly designed to keep the software from bogging down on a busy server. Then again, if the thing was designed properly, you shouldn't have to tweak things to a fare-thee-well to make it work properly.

    After enduring annoyances with WordPress when having eAccelerator or XCache around, I'm without that and back to SuPHP, and our server has all the latest stuff that cPanel installs, which is now Apache 2.2.14, PHP 5.2.11 and MySQL 5.0.85 community. They've not moved to the 5.1 MySQL branch yet, and they're holding off on PHP 5.3 since too many things are broken. So it's curious why vBulletin is hoping for later versions than one might normally expect. Consider that cPanel is by far the most popular control panel anyway.

    I guess the other question, once your programmer looks at it, is whether all those customizations can hurt other PHP software. Anyone? In other words, if we convert to Burning Board, do we kick back all those changes?

    Peace,
    Gene

    • Offizieller Beitrag

    Hi again!

    I've talked to the developer and that's what he told me:

    All these extensions for MySQL, PHP and vBulletin are only necessary when you want to do special things for extremly big boards, which yours is definately not. Our board software runs best at standard server configurations, but without any so called "optimizations", which in most cases do more harm than help applications run better. As i wrote above, turm of SuPHP, Suhosin, Safe Mode, eAccelerator, xCache, and so on. Most servers have those extensions installed only to be there without really being of use.

    Just take Safe Mode: It's already deprecated (the developers of PHP recommend not to use it!) and will be gone in future PHP releases. Nonetheless you will have to search for a server admin who will not tell you, that Safe Mode ist absolute necessary for server safety, which is humbug!

    Maybe you just have to get familiar with our modern system, which works completely different. When used to the complex installation process of most web applications, it's sometimes hard to believe, that it can be so much easier … ^^

  • We have Suhosin and SuPHP enabled. The latter seems to rate well with our firewall software (CSF). We went to SuPHP because it doesn't present the crazy permissions issues of DSO, so we leave it in. My experience with PHP accelerators seems to indicate they cause more trouble than they're worth. But Suhosin? Why is it there and why would we disable it? I mean I can easily do that simply by recompiling Apache with cPanel's EasyApache without it, and in 10 minutes it's history.

    As to the rest, with your test board, I like the fact that most of the installation process is automatic rather than having to put up with the manual crap of other forum systems. So I'm hopeful, and I hope you don't mind if I keep the discussions going. Hopefully one or two others will find it interesting.

    Peace,
    GEne

    • Offizieller Beitrag

    No problem. The board is here for discussing. :D

    The only problem is that our developers are very busy at this time (we have just released WBB 3.1), so i can't answere as fast as i would like to and they have no time also. That's why we are talking here since days, not hours. :D

    And sometimes it's also a little bit difficult, because not all of us are good in using English.

    Suhosin: It just restricts the number of variables sent by forms. When you take the style editor, that's all one big form (the whole thing), all those settings are sent at once, which will be impossible, if the Suhosin setting is low. We do not see any advantages in using Suhosin.

  • Aha, that is why vBulletin's people have you boost some of the Suhosin settings. If you're certain there is no downside in terms of security, I'll send it away. Can I be assured of that?

    Peace,
    Gene

    • Offizieller Beitrag

    You don't have to turn it off, just set the settings high. But it seems that this is not necessary, since you seem to have used the style editor alreday and it worked. If you find that some setting wont save, that is a sign for Suhosin working …

    There are several posts here on the forum where i can read that it should be best to set suhosin.request.max_vars und suhosin.post.max_vars to a mionimum of 2048

  • You don't have to turn it off, just set the settings high. But it seems that this is not necessary, since you seem to have used the style editor alreday and it worked. If you find that some setting wont save, that is a sign for Suhosin working …

    There are several posts here on the forum where i can read that it should be best to set suhosin.request.max_vars und suhosin.post.max_vars to a mionimum of 2048


    Yes, I think we've made those changes already.

    See:

    http://www.technightowl.com/phpinfo.php


    Peace,
    Gene

  • You seem to be using PHP via CGI (suPHP). This is very slow compared to FastCGI or Apache mod_php since every request will result in a process being started on the server! This might not be a big issue with few active users, but it might cause problems if your board grows larger. However, assuming you used it before with vB too, you won't notice a difference in speed since it's a delay not affected by the code which is executed.

  • I've gone through frustration using other setups in cPanel (such as DSO). It wreaks havoc on WordPress permissions and I'm always running into issues when trying to install updates, etc. The CSF firewall software config suggests turn on suPHP.

    I tried the cPanel setting for FastCGI, and it broke the vBulletin plugin we use for SEO-friendly URL rewrites.

    So it seems there is no winning choice here, unless you can suggest a better way.

    There are five options in cPanel for the PHP 5 handler:

    DSO
    FCGI
    CGI
    SuPHP
    None

    Advantages/disadvantages? We don't want to hurt our WordPress installations in the bargain.

    Peace,
    Gene

  • DSO is probably Apache mod_php which is usually pretty fast.
    But you don't have to change anything to run WBB - it might just speed things up.

    So the best thing might be not changing it right now but trying the various options when everything else is running and you have some spare time.

  • We have a server with 16GB RAM, huge hard drives, RAID 5 and double quad-core Intel Nehalem Xeons, so I don't think we lack processor power. In fact, when we went from DSO to SuPHP and killed the PHP accelerator, it added just .1 second to the processing time in WordPress, so I guess we can handle an awful lot.

    But I'm working out the potential migration issues with a volunteer so we know what it will take to get the look and feel we want.

    Meantime, vBulletin has upgraded their forums with an early beta of their 4.0 version, and performance sucks rocks so far.

    Peace,
    Gene

    • Offizieller Beitrag

    That server would be sufficient for a one million people community! You don't even have to think about optimizations with that machine … 8)

    We are trying to follow what they do, but it's hard when you are working and have not so much spare time. The vB forum has the speed of a typical nineties website at this time … ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!