Version 1.8 causing significant Server Load

[Acehigh11]

Hey,

We just upgraded the PHP Live Helper chat software to the 1.8 version and I'm noticing a HUGE increase in load on the server since.

Normally, with about 30 - 60 concurrent users on the website at a time, the load on the Linux server, via a top command, was < 1.00 for the most part. Since installation we are experiencing loads averaging around 3.00. I've seen it spike up over 27.00 before which is pretty insane. :eek: Is there a configuration setting we are missing, or are other people experiencing the same thing?

Is 30 - 60 users beyond the capabilities of Live Helper?

EDIT: Sorry, forgot to mention, this is the PHP version running on Linux Red Hat Fedora Core, Apache and PHP 4.3.6

Thanks for any feedback.

[minghoo]

From my experience, the final version 1.8's loading speed slower than 1.7 version.

i don't know what is that reason, maybe someone don't agree with me, but that is true.

[Acehigh11]

Do you mean in terms of client side loading? I haven't noticed any decrease in the load speed for the client, I'm talking about raw Server Load running the chat application.


Could the Zend Optimizer for the de-crypting be causing the load?

[TurnkeyAdmin]

Zend optimizor actually speeds up load times and causes the scripts to run more efficiently. Server load issues themselves can be do to other reasons though. If you site is really high traffic try disabling the reports for a while and clearing them out to see if that helps. Also while doing "top" try to see whats eating the resources, is it httpd or mysqld?

[Acehigh11]

I've got reports off, and tried to back off the refresh rates of the scripts.
That's what I thought about the Optimizer, it doesn't make sense that it would add that much overhead as it's supposed to be an "Optimizer", just a thought I would throw out though..

The process that is taking all CPU is the httpd process. We actually have the db on another remote server.

Take right now for instance, 15 people online according to the chat software, and the webserver's load according to top is 1.49 load with httpd using 55.6% of the CPU, it's a split load though, as we have a dual CPU box. But that is a lot higher than what it used to be before installing the software.

The Optimizer is required for the 1.8 correct? I'm trying to nail down exactly what changed on our system for this, and if we could try to roll that back if possible. Maybe we installed it incorrectly or something.

[Acehigh11]

So we finally pin-pointed the problem. The load comes from the /javascript.php page that manages the users. With the database located on another machine, it's the mysql network connections that cause the load. If you comment out the ServerName variable in the db_include file the load on the web server drops back down to normal levels.


We noticed the large amount of mysql connections via the netstat command, but didn't think they would invoke that much server load to manage, but again, it was night and day in terms of load when you comment out the db connection for the chat software.

We are reverting back to the previous version we had installed, 1.7 which doesn't seem to invoke the additional overhead.


What is your recommended high end concurrent user base for this software?

[TurnkeyAdmin]

Hmmm, you might also want to try optimizing the database in the admin control panel to see if that helps any. So you are saying the ServerName in the javascript.php cause your load issues?

[Acehigh11]

No, with a high amount of web traffic, and a dedicated remote database server box that is not the web server, there is a significant amount of added load that is incurred on the web server to manage the MySQL network traffic between the two machines. When you comment out the ServerName variable in the include, therefore causing the database connection to fail, the overall load on the web server drops massively.

Have you guys attempted a test instance where you have a seperate database server and web server along with a constant 30 - 60 people on the website? It may have been the database server, but I checked the load on that box during the large web server load times and it had a overall load of less than .5, so I don't think it was a lag time caused by the database retrieving information. Our instance may be an odd configuration, but we don't want to stack the web server with an added mysql process either.