Not worth the aggravation

[Scorpion Illuminati]

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'm sorry but everytime i see:

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

I start to fear the worst.

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.]

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.

Sincerely,

Aleeious

[admin]

...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.