We just installed the php version on our site and have discoverd its totaly killing our server. We upped themax number of SQL conections to stop the SQL erorrs but nothe server is unsurfable. Its a beefy server (GiG RAM dual P3 gigahertz processor) Its a very busy forum and we are not sure what we can do to get the script to actually function with around 500 users using it at any one time. Any suggestions?

I have been struggling with similar problems and I haven't found any solution yet.

And I haven't got 500 users yet.

I have tried speeding up the script by changing from perl to php, I have also removed some things from it to get i faster.

After that a splitted the database, that made it faster until it gets too many users (150-200).

Then realised that the company running my server probably could have configured my mysql server better. We are still working on that.

Any input on how to configure things would be appreciated.

I get a feeling that the script in some way opens to many connections? I am not a programmer so I am not sure but could it be something not optimized in the way the script talks with the database?

Should one run with persistant connections or not, I have heard persistant connections could kill a server.

Sounds like the WWWThreads can really make aserver crumble. Unfortunatly I am not sure what to do . Scream have you any comments or fixes for this. Every day its crashing is costing us $$$

Most everyone that uses w3t under that type of load has had to split out the database and scripts to 2 different servers. Stratics.com has anywhere from 400-500+ users online at various time but they are running under this split configuration.

You can normally tell where the bottleneck is coming from by running top and looking to see what is using the most processing time and memory. Usually this ends up being mysql because of the number of connections that need to be made to keep up with that many users.

As for config options. If you are using the latest versions you can help ease some of the load if you set the default aged threads to be displayed to a relatively low number. If you have it set to view alot of old threads then the scripts will need to read from a larger portion of the database which can contribute to slowdown under heavy useage.

Persiistant connections can slow down a server if it does not have enough memory since each connection takes a chunk of memory and if you have a few hundred open connections this can add up real quick.

You might want to take a look at my previous reply for some things to check on where the bottleneck might be and how to configure one of the options for best performance.

The scripts have been heavily optimized with indexing in place on the database. Normally slowdown comes from the sql server as with several hundred open connections the mysql server can be doing several hundred queries in a matter of seconds.

Thanks for responding. I have set persistant connections to off and kept the view down to 2 days but stil no luck. The script runs ok for about 20 mins then the server just starts to go real slow.

Getting another server is not an option at the moment and its a bit drastic just to run a forum. How do you go about splitting the DB. I am no SQL expert but this whole problem has come as a bit of a shock and I dont want to feel like buying the script was a waste of money as its a great looking forum.

Splitting the database would require the separate server which means running the scripts on one and the database on the other. I'm not sure of anything else that can be done on that level to improve performance.

How many posts and registered users do you have? When you run top when things start to slow down what are you seeing. Memory swapping or an overutilized cpu? I'm just assuming you are running linux so this should give your current cpu load as well. You will also be able to see what is causing the slowdown, either the mysql server or individual scripts.

A couple of other configuration options that do help improve speed is have the default to show collapsed threads on the postlist screen, about 20-25 per page and flat mode.

I am new to php but I have just noticed this in mysql.inc.php

if (!$config[persistent]) {
$this->dbh = mysql_connect($config['dbserver'],$config['dbuser'],$config['dbpass']);
}
else {
$this->dbh = mysql_pconnect($config['dbserver'],$config['dbuser'],$config['dbpass']);
}

Isn't this a major fault, I am thinking about the mysql_pconnect and mysql_connect, shouldn't it be the other way around?

I have just set them both to just mysql_connect. I haven't got that many users on the forum yet but seames to be working better so far.

This is the proper format.

if (!$config[persistent]) { ...

This means if $config[persistent] is not set then use the standard connect function otherwise use pconnect.

Ok, thank you for the clarification.

Now my server has crashed again.

At some point Threads_connected or/and Threads_running goes from 1-4 that seemes to be normal upp to a much higher value and then I cant reach the server, it happens very quickly says the person responsible for my server.

It usually happens after some time when the forum get say 75-150 users. But i can´t understand why i happens so quickly.

We have changed some of the values for the mysql-server, do you have any good idea of how they should be set up depending on if you are useing persistent or not.
Or some clue on how to solve the problem?

I am going to have to stop using this forum unfortunately It crashes our whole server, great considering just spent he $100 on registering the script :(

I agree with you about the SQL, if anyone knows any way to improve the SQL performance then please speak up. I reallly want to use this board but until I can get this resolved we are boardless.

I'd look at upping the amount of RAM in the box. 1GB isn't that much with the number of users you're sporting, also look at your hard disk array.. i.e. is it beefy enough to handle that many random I/O reads/writes. With that many concurrent users, I would think of nothing less than a 4 or 5 drive Ultra160 Raid5 array. And as for hardware cache on the controller, the more the better... but 64-128MB should be good. Also the normal things like keeping your OS and data on separate arrays, etc...

From upping the RAM to getting another sarver is really drastic for a forum. I must admit I am a bit annoyed that there was no mention of the fact that this script could not handle a decent ammount of users before purchasing. The script cant actually do what it says it can do if you have morthan a 100 users it seems which is pretty poor. Now I'm $100 down and there's no solution. I would like to try and get a refund this has caused us a lot of problems. Scream?

Do you have access to the server via telnet? In order to really know what's going on we need to find out what is causing the server to crash. If you can run top you should be able to get some info on if it is swapping memory, number of processes running, cpu utilization and what process are using the most memory/cpu.

The server definitely shouldn't crash. It might have a very high load but as users timeout the load should start to drop enough to get a response from it.

If it has crashed then one of the first things you need to do is go in and OPTIMIZE your tables before starting up the webserver again. You can do this from the mysql prompt with the following:

OPTIMIZE w3t_Posts;
OPTIMIZE w3t_Users;
OPTIMIZE w3t_Messages;

The scripts are very capable of handling several hundred users. It may seem like they are not but they do run quite well for alot of sites and many of them are on single box configurations. I know adding more RAM or another server seems a drastic step for a forum but it's a problem many would like to have as 500+ users online at the same time is considered a very succesful forum. Not trying to sound defensive or make light of the situation, it's just a matter of with that number of users server upgrades are necessary especially on dynamic forums because of all ot the read/write access.

Some info on the questions I asked would have been helpful to pinpoint the problem to being memory related or cpu related because I'm always trying to improve things where I can. So if you can get any of this info to me I'd be most appreciative.

Scream, here's the top info you asked for. This is when the whole machbine starts to hang. There are around 200 users on the forum at this point.

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND
42542 root 2 0 24660K 4328K poll 1 75:27 18.70% 18.70% mysqld