rct2·com

That's all very comprehensive analysis. Some of is it relevant whatever server spec you are running. But the most critical factor in determining optimal mysql settings is the amount of memory on the server and the amount of free memory available. Some of your recommended settings may be too low or too high, depending on server memory.

I would guess that somebody at the server level has been playing with PHP's openbasedir setting. I suggest you contact your host. Either that, or permissions on files have been changed.

One of the joys of choosing a Linux distribution. They only update after testing has completed. You can probably find a newer PHP version somewhere, indeed you could always download the source code and compile it, but it's not in the official repositories yet.

Why is it important to delete it anyway? If you can drop all the tables in it, you can always add new tables later, and use the same old database name for a different purpose.

Key missing data there is server 'load'. You php process using 98% CPU is absolutely nothing for them to worry about if server load is low. Load is an indication of how many other processes are waiting for CPU. If there are none, or very few, then what's the problem with you using what is there?

I don't use an accelerator either. I think if lighttpd has worked for you, there is absolutely no reason to consider changing it. I think my message is that it really is not possible to give a definitive answer to your question. You have ideas of what works for you and your server load/visitor profile, my config works for me. I manage with 1/8th of your memory, slow disks, and much slower processor, and only a 10mbit uplink. Peak concurrent visitor numbers are about 1/3rd of yours. But getting the optimal performance has involved months of tweaking Apache and MySQL configuration parameters.

Configuring Apache is a black art IMO. I have seen servers killed because of just one directive in the httpd.conf file. There's a balance to be drawn between how many processes should be allowed to exist concurrently, how long each thread should be allowed to keep alive, how many connections each process should serve, the amount of memory per process, etc, etc. A lighter web serving process such as lighttpd kind of 'hides' these issues, but if your server became uber busy it would eventually suffer the same slowness that can be attributed to badly tuned Apache.

You seem to have started by asking some questions, then ignored the answers and told us what you've chosen in any case! PHP does seem to be having security issues, and updates are issued on a regular basis. I guess what you use really depends on what you are able to support yourself, and what your host is prepared to support. Personally I run CentOs 5.3 with yum updating every week or so. I use Apache not lighttpd, amd MySQL 5.0.X. At the end of it all though, performamnce isn't really down to just the software levels, its down to the tuning that you then do to suit the specification and workload of your server.

All this can also be achieved with a backup script outside of IPB.

Can you not manage this through you app's coreVariables.php? At least, that's how I understood it based on the article. http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&article=7508

If the only purpose it serves is to have a backup, then I don't see the point. Will it be in the same database as the main board, so that when I run my daily backup, it will be twice the size it normally is and take twice as long to produce? There already is a 2-phase 'trash can' capability so that topics/posts that are deleted aren't really deleted, they are moved to another forum.

Yes a single character mistyped can cause the whole app to fail silently. Even more reason to implement my suggestion. :)

All this weekend, I have almost literally been tearing my hair out trying to debug a problem with an app I've been developing for IPB3. A debug statement in the top of index.php to var_dump($_GET) said that it was empty, but it turns out that it wasn't. That's an Apache/PHP bug/problem I think. It turns out that the root cause of my problem was that I hadn't got my code and folder structure quite correct, so that IPB couldn't find my application's executable code. Because of this, it was defaulting to the root URL for the board. It would have been nice [and I would have slightly more hair] if IPB3 had given a warning message stating that although the application was registered in AdminCP, it couldn't work out which code to execute. Perhaps this type of warning could be given only if IN_DEV mode is switched on?

No problem for me on Firefox 2.

That change still hasn't made it to here....

Or perhaps "Let he who doesn't like the skin create his own"?

Ok thanks, now I know I'm not going mad.

Where? Still displaying the same here for me.

I know the Watched Content panel is semi-official, an example of a 'hook', but it would be nice if there was some kind of order to the Watched Topics. IMO, it would be best if the first in the list was the one that had most recently had a post added. Currently, the dates on my watched topics at this site in that sidebar are: Feb 26 2009 06:41 PM Jul 03 2005 02:17 PM Mar 14 2009 04:29 PM Jul 31 2005 11:01 PM Feb 27 2009 01:09 PM Jul 01 2005 02:42 PM Oct 26 2004 09:07 AM etc.. I applaud InVision for not automatically deleting subscriptions to old topics, they are great to have as pseudo bookmarks and references to valuable information here, but right now in Watched Content, they are 'polluting' the listings.

Is this before or after we pay the $5? :rolleyes:

Where can I find out about how to get preferential downloads?

Slightly OT, but anybody fancy writing a hook that senses IE6 [and other old browsers] and puts up a message warning them that their "experience" on the board may be affected?

I'm kind of expecting InVision to continue support for IPB2 for a while, and waiting for an announcement on this. A lot of customers seem to like their mods and these are going to need serious review and changes to work with IPB3. For those who think they will still want to mod the actual code, then they still don't have their hands [officially] on unencoded source yet. And there are those who are tied into hosts who are resistant to upgrading their servers to run PHP5, required by IPB3.

Separating the Topics tab from the Post tab with Blog and Gallery tabs. Is that configurable?

That's OK, let them rot. They should be concentrating on governing and planning us out of this economic crisis and not visiting your site. :)