Messages

We are testing a new cPanel server at the NYC data center.

If anyone would like to be moved to this server, please let us know by sending a message via the Helpdesk.

This server is running CloudLinux so it allows various PHP versions to be selected, modules to be included/excluded, PHP settings changed, etc.

If you are on EAST, this server should provide more performance as it is SSD based.

Reminder: PHP 5.2 and 5.3 are slated to be removed from this system once 5.6 goes to release.

PHP 5.3 is now officially EOL'd, so no more security updates are coming to it.

...My app uses where clauses for user.username, username.password, matchindex.id, matchindex.challenger and matchindex.defender. You can see how everything works on my github page. Any assistance would be greatly appreciated....

As long as the fields you have listed are indexed along with any fields used in your JOIN statements, you will be fine.

As long as your site isn't taking multiple seconds per page load, you are generally fine.  (We are not talking about time waiting on downloading files to the client computer, Nginx offloads that part from Apache very well, but time waiting on your pages to generate due to waiting for MySQL, waiting for a remote API, etc.)

For the most part, we try to keep the load low on the servers.  We let users exceed CPU-I/O time limits for a period of time in case they are working with their site or are getting a traffic spike.  When we get complaints on the performance of a specific server, if we find these high resource users and the reason they are using resources is Google is crawling their site (because their site takes 10 seconds to load on each pageview), we generally disable the user and attempt to help them index their tables or explain what processes are using too many resources.

If your site loads fast, you will likely never fall into this group.

By replying to this topic, we didn't want to send the message that we were thinking of discontinuing the service, because we are not.  We may need to consolidate it further in an effort to lose less money, but there is no reason the service will need to be discontinued in the near future.

I feel bad for the users that don't cause problems, but unfortunately, there are numerous problems being caused, most are not intentional (while some are).

-Dormant sites/scripts that then get exploited (because they are not kept up to date)
-Users using too many resources (page loads taking 10+ seconds, easily DoS'd)
-Improperly indexed tables (likely no indexes at all on some)
-Inefficient database queries
-Selection of lower PHP versions that is necessary to run their script.

So do i, a few bad apples ruining it for everyone is very unfair.

For tables: If a field is in the ORDER BY or WHERE clauses, be sure those fields are indexed.  (i.e. If you are filtering for something and/or sorting by something, those fields you are sorting and filtering by should be indexed at the very minimum.)

Could you please explain this a bit more? Does that mean I should create indexes for all my columns? Any assistance would be greatly appreciated.

Sincerely,

Aleeious

You should create indexes for any column your are sorting or filtering by.  If you are not sorting by that column (i.e. using it in an ORDER BY clause) or filtering by that field (using it in a WHERE clause), this will not be necessary.  [This should also be done if joining tables using these fields.]

We are starting to force the few new users into plans where number of connections can be limited.  Hopefully this will help reduce the problem (to some extent), especially if this is extended to the rest of the users.  Existing users of the system are excluded from some of the rules, so we will need to design a custom plan for these users.

For tables: If a field is in the ORDER BY or WHERE clauses, be sure those fields are indexed.  (i.e. If you are filtering for something and/or sorting by something, those fields you are sorting and filtering by should be indexed at the very minimum.)

I feel bad for the users that don't cause problems, but unfortunately, there are numerous problems being caused, most are not intentional (while some are).

-Dormant sites/scripts that then get exploited (because they are not kept up to date)
-Users using too many resources (page loads taking 10+ seconds, easily DoS'd)
-Improperly indexed tables (likely no indexes at all on some)
-Inefficient database queries
-Selection of lower PHP versions that is necessary to run their script.

no way to throttle cpu?

Not easily with the way things are setup.  It is not just CPU but overall I/O wait that causes problems.

The West server was recently using much CPU, but it was used by Qmail due to a spammer injecting some scripts in an outdated site.  Restricting the user wouldn't have stopped this since it was the Qmail process using a good portion of the resources.  (The rest of the systems are not running Qmail and have less of these issues.)

This service is starting to get out of hand again.  Users using well beyond their CPU resources, a large number of mysql tables and queries not optimized, outdated scripts, insecure permissions, etc.

I guess our only choice will be to shut this down.

A few additional tweaks have been performed for InnoDB tables.  If you are using this type of table, you might notice faster response.

Beyond that we will need to check sites that are waiting for remote sites (API's) extensively, as that can cause high I/O wait times.

These changes were done on East only.

We will have to look at problem sites.  Which server are you on?  East?

Please submit a proper support ticket for a faster response.

This wouldn't be a problem if tables were properly indexed by everyone and queries were designed correctly, but since that will never happen, I will see if we can tweak it further.

We are glad the changes have helped your site.  Please let us know if it starts to happen again.

We have further optimized the mysql configuration on EAST to help prevent this.  This happens because some databases are not indexed properly causing table scans to find rows.

Please open a ticket and provide specific details such as your location, your sites, etc.

We will be removing PHP 5.2.17 from all servers in the near future.

If you have scripts that require these older versions, those scripts will no longer function on our service.

Users that have PHP 5.2.17 selected will be updated to 5.3.28.

When 5.3 is removed, those users will be updated to 5.4.

Please be sure you have selected the highest PHP version that your script will run with.  It is recommended to use PHP 5.4 or 5.5 for all sites.  PHP 5.3 should bed avoided as it is nearing the end of its life.  PHP 5.2 reached end of life more than 2 years ago.