My server configuration OK?

[Tiribulus]

If some of the many fine folks with much more experience and knowledge about these things than I could take a gander and let me know if you see any glaring problems I sure would appreciate it. I have been working on this self hosted forum for about a month now with absolutely no previous experience with PHP or MYSQL for mostly educational purposes. I had to do a pretty fair amount of manual configuration stuff to get it to where it is now. I'm wondering if there's something staring me in the face I just don't know enough to notice. I think there's a couple more sql variables that could use some adjustment. It's running on a LAMP box, P4 1.6 and a gig of memory.
Thanks.

http://gregnmary.gotdns.com:8080/test.php

http://gregnmary.gotdns.com:8080/status.php

EDIT: One question I have is, is SQLite an extra engine I have running that I would do better to disable? I read that innodb and SQLite (or mysqli, can't recall at the moment) are both SQL engines and running more than one at a time is a performance drag.

[Something like that]

1. Running Firefox and X on your server? What??
2. Your server seems to be coping fine.
3. Look into installing APC. OpenSUSE likely has a package for it. You'll need to do some minor configuration. 64 MB of cache should be adequate.
4. InnoDB is a good thing. Look at this thread: http://www.simplemachines.org/community/index.php?topic=50217.0 . Be sure to increase the variable innodb_buffer_pool in your MySQL configuration to 128M for your machine if you decide to convert tables. Make the change in your MySQL configuration first, restart MySQL, and then convert.
5. You almost certainly don't need SQLite. Disable it.
6. MySQL's key_buffer_size is set to 16M. I'd increase this to 128M, especially if you don't convert the suggested tables to InnoDB.

Don't worry about the struck out stuff until your forum gets busy.

[Tiribulus]

1. Running Firefox and X on your server? What??
2. Your server seems to be coping fine.
3. Look into installing APC. OpenSUSE likely has a package for it. You'll need to do some minor configuration. 64 MB of cache should be adequate.
4. InnoDB is a good thing. Look at this thread: http://www.simplemachines.org/community/index.php?topic=50217.0 . Be sure to increase the variable innodb_buffer_pool in your MySQL configuration to 128M for your machine if you decide to convert tables. Make the change in your MySQL configuration first, restart MySQL, and then convert.
5. You almost certainly need SQLite. Disable it.
6. MySQL's key_buffer_size is set to 16M. I'd increase this to 128M, especially if you don't convert the suggested tables to InnoDB.

Don't worry about the struck out stuff until your forum gets busy.

Yeah, I'm a gui dood, be gentle 

Right now it's more or less my school and a place where my wife and a couple of her friends play around. Sooner or later it may have a few dozen members. Am I correct in assuming that for #5 you mean I almost certainly DON'T need SQLite? It looks like you just forgot to type don't, actually before need or disable.

[Something like that]

You don't need SQLite

You might like the Opera browser on Linux. It's much faster than Firefox.

[Tiribulus]

You don't need SQLite

You might like the Opera browser on Linux. It's much faster than Firefox.

Thanks, BTW. I have Opera on one of my Windows boxes and I really loved some things and couldn't stand a couple others. In the end I can't live without my extensions, but I'll throw it on and have another look.
Thanks again

[Tiribulus]

Can I just uninstall sqlite with mussin everything up?

[Something like that]

Just edit your my.cnf file so MySQL doesn't load it. I believe the entry to add is "skip-sqlite", though I could be wrong.

Really though, it's a very minor thing. It might save you a few KB of RAM as it will only be loaded if called upon.

[Vekseid]

128M for key_buffer would be a bit of overkill, 64M should be fine for a long time. Your thread_cache size is -way- too huge though, set it back to 8.

I would invest the time in learning how to get FastCGI going. You don't need it, per se, but it is very valuable knowledge to have.

[Tiribulus]

Alrighty then: now that my head hurts, innodb is faster for tables that have high transaction rates meaning they are altered a lot, like threads for instance, but not on forums below a certain amount of this type of action or on forums with lower usage overall.

However myisam is generally better in all cases on smaller forum sites and also still on large ones only for tables with high view rates, but aren't written to very often. Optimal specific configurations (as far as that's possible) where converting high transaction tables to innodb would be called for at all, are achieved by observing not only how much traffic the site gets overall, but what tables get what type of requests most often. Even then configuration is based on trends and every request cannot under the best of circumstances be as fast as every other one.

Also, innodb does not support fulltext search indexing (with some tables) thus necessitating a custom index and it's almost never a good idea to convert all tables to innodb because weird issues like disordered page displays can result.

In short my wife's forum is way to small to have to worry about any of this right now which is a beautiful thing because I have no idea what the hell I'm doing.

[Tiribulus]

I'm gonna see about APC and fast CGI. For some reason I thought SMF didn't use CGI, or SSL supplanted it or something. Been a couple weeks since I read that.

[Tiribulus]

Anybody ever play around with http://dev.mysql.com/doc/administrator/en/index.html?

[Something like that]

Alrighty then: now that my head hurts, innodb is faster for tables that have high transaction rates meaning they are altered a lot, like threads for instance, but not on forums below a certain amount of this type of action or on forums with lower usage overall.

However myisam is generally better in all cases on smaller forum sites and also still on large ones only for tables with high view rates, but aren't written to very often. Optimal specific configurations (as far as that's possible) where converting high transaction tables to innodb would be called for at all, are achieved by observing not only how much traffic the site gets overall, but what tables get what type of requests most often. Even then configuration is based on trends and every request cannot under the best of circumstances be as fast as every other one.

Also, innodb does not support fulltext search indexing (with some tables) thus necessitating a custom index and it's almost never a good idea to convert all tables to innodb because weird issues like disordered page displays can result.

In short my wife's forum is way to small to have to worry about any of this right now which is a beautiful thing because I have no idea what the hell I'm doing.

Personally, I run all InnoDB. Yes, you have to change one table slightly to fix the board display order. Once you get busy or have over 100K posts or so, it's best to switch to Sphinx for searching. It's much faster than fulltext search or using a custom search index.

The two major advantages InnoDB has are:
1. It keeps data clustered together by the primary key. This avoids fragmentation, and it's especially noticeable in frequently changed tables. It can also make caching more effective for technical reasons I won't get into here.
2. It uses a journal to update the actually database. It writes down everything it will do, and then follows behind and does it. That way, if MySQL should ever crash, it can go back through the journal, make all the changes, and know the database is good to go. MyISAM has to scan through the entire table because the tables could be corrupt.

It's not just about speed

But for now, MyISAM will do you fine. Until you get thousands of users and 100K posts, you really don't need to worry about the database that much.

[Tiribulus]

Yeah, I've been doing some more reading on that actually.

On your other note, do you know where to find some decent documentation on how to get APC going or maybe you could tell me. Can it be installed after everything is already running? Does PHP have to recompiled. Actually Suse doesn't have the package.

[Something like that]

PHP doesn't need to be recompiled.

You have to download APC, and part of the instructions involves runing "phpize" which adapt the APC code for the version of PHP installed.

Afterwards, it's simple edit to php.ini to enable it.

[Tiribulus]

This may be beyond the scope of what can be addressed here, but my machine does not bare even a vague resemblance to what is being spelled out in the install file included with APC. I have no sign of phpize which the file says is part of pear. The Suse PM (yast) has about 3 dozen packages with the name pear in them. I picked the one just named "pear" which installed into /usr/share/php5/PEAR/, still with no sign of phpize. And the php.ini file being used on this box is in /etc/php5/apache2 . I installed PHP myself. This may be a Suse thing.

EDIT: It seems that the php-devel package is what's needed for phpize which I have now installed. I now have 2 instances of phpize, one each in /etc/alternatives and /usr/bin, but neither of which make sense with the install file included with APC. I'm gonna get this figured out if it kills me. It's the principle of the thing.

EDIT2: Should APC be unzipped into the install dir for php and do you run phpize from there. I keep getting a message telling me

Make sure that you run '/etc/php5/phpize' in the top level source directory of the module

EDIT:3 I dunno folks. Of the pretty sparse info I can find on how to enable APC on a lamp box it is conflicting all over the place and none of it appears at least to resemble Suse 11. I need a break for a little while

[Vekseid]

I'm a Debian guy, myself, sorry. You might try checking CentOS docs as Suse seems to have followed Red Hat's lead.

[Tiribulus]

I WIN!!!!!!

http://gregnmary.gotdns.com:8080/test.php

http://gregnmary.gotdns.com:8080/apc.php

Now I have to get it configured.

I set up this machine from scratch never dreaming of all the stuff I would need for things like this. Had to install GCC, php-devel, make, pecl and pear (I think that's it, maybe not) all in pieces and then ran the pecl install apc  version of the install routine. Actually did it like 4 times each time it telling me something else that wasn't working. Then I added this:

Code Select Expand

; APC

extension=apc.so to the php.ini file in /etc/php5/apache2, restarted apache and there it is I am entirely aware that it will get me absolutely nothing on this site, but I refuse to be deated and it became an arm wrestling match on pure principle. Config next.

EDIT: It's an old version   and I cannot find on word on how to update it

EDIT1: OK, I got it updated

[Something like that]

I'm a Debian guy, myself, sorry.

The One, True OS.

And with a bit of polish, you can turn it into Ubuntu

[Tiribulus]

I'm a Debian guy, myself, sorry.

The One, True OS.

And with a bit of polish, you can turn it into Ubuntu

Suse has always been good to me, but this is the meatiest setup I've ever attempted with it. It does seem that Debian and slackware are much more widely used for this stuff. Suse 11.1 does now have a LAMP option in it's install routine which I haven't tried. I have a bunch of ho hum computers like this one laying around. Maybe I'll give Debian a shot. I have Ubuntu on a laptop which it's fine for, but it seems a bit slim for server stuff. Then again it isn't the server version which probably explains that. Oh well, not to get too far off track.

In the meantime, I'll poke around here for some tips on configuring APC for SMF.

[Something like that]

Suse has always been good to me, but this is the meatiest setup I've ever attempted with it. It does seem that Debian and slackware are much more widely used for this stuff. Suse 11.1 does now have a LAMP option in it's install routine which I haven't tried. I have a bunch of ho hum computers like this one laying around. Maybe I'll give Debian a shot. I have Ubuntu on a laptop which it's fine for, but it seems a bit slim for server stuff. Then again it isn't the server version which probably explains that. Oh well, not to get too far off track.

There's nothing wrong with SuSE. The rule of thumb for servers is to use what you know.

In the meantime, I'll poke around here for some tips on configuring APC for SMF.

You can increase the cache size, but there's no point until you have more activity.