PHP performance

[deltanet]

Well, I've been a customer on the 'Baby Croc' package for 20 hours and I have to say the performance of PHP is absolutely abysmal. 108 seconds to even start a PHP script at some points with 20-30 seconds not being unusual (and that's when it doesn't time out completely)

To make matters worse I wait 3 hours for a reply to my ticket only to have an engineer tell me this is normal

I wonder what hoops I have to jump through to get a refund

[GatorBrent]

Hello,

What is your ticket number with us? I would like to take a look. thanks!

[deltanet]

Ticket number is #DBO-344425, assuming it wasn't deleted from your system when I cancelled. The 12 hours+ of poor PHP performance was apparently caused by another customer on the same box using excessive resources. The fact that they could do that for 12+ hours without anyone (other than a customer) noticing was the reason for my cancellation.

[GatorBrent]

No one in your ticket said that was normal. On top of that no one in your ticket said it was an abusive client.


The server you are on had a load average of .33 has never been down since the day of it's birth, and looking through the logs I have never seen an abusive customer on it.


There's numerous different things that could have been the cause, but since you had a script checking for you instead of seeing it yourself and when you submitted the ticket it wasn't a problem we can only assume what it could have been.


1. assuming you changed dns it could have been propagation.
2. The server you had testing it actually could have been the slow down.
3. The network you were testing it from could have been the slow down.
4. We could have put some type of limit on it from the resource usage caused by all the testing.
5. it could have been 100 different things, but I don't see any evidence it was actually a slow down by the server.



I really would like to see you give us another chance as I'm sure you would be happy with us. If there is ever a problem on a server we can fix it, but it has to be a problem that can be seen by more then just a script that may or may not work.


What can we do to see you give us a fair chance?

[deltanet]

Originally Posted by GatorBrent

No one in your ticket said that was normal. On top of that no one in your ticket said it was an abusive client.

My ticket is quoted below, as I can only assume you must have been reading somebody else's

I've recently signed up for your 'Baby Croc' hosting package to evaluate your servers in advance of moving our hosting to you. As part of this evaluation I've set up a system that monitors the response times for a PHP script that I've uploaded onto the server.

At first everything looked good with respose times of 0.2s - 0.3s, however as of approx. 01:15:00 GMT+0100 the response times have shot up to as much as 108s (at 11:15:03 GMT+0100) with the average being around 14s.

Is this a glitch with the server or just an expected result of the server becoming busy?

Many Thanks,

Tony

The response from support:

Hello,
It was probably due to server load at that time since it would have been the peak use times for most of our clients on the server.

Caused by peak use time server load. Tell me how I'm supposed to interpret that as anything other than "This is normal"

Honestly, I couldn't believe it myself (I guessed I was being fobbed off with a boilerplate response) so I wrote back.

So your saying 108 seconds to start a PHP script is normal for your servers at peak usage times?

and got the reply:

Not at all. 109 seconds is definitely not something we would normally see on this server. I have alerted the abuse department of this load time and they are currently auditing the server for PHP process abusers so that they may be completely removed from the server. As long as everyone on the server is operating within our TOS this is never an issue. It seems as though someone was running php process bursts from what I can see but it has leveled out now. We will be keeping an eye on this in the support department and rest assured if Abuse finds anything, the user/account will be removed.

So, the explaination for the performance issues is "It seems as though someone was running php process bursts from what I can see"

This seems to contradict your 'no one in your ticket said it was an abusive client'. Unless the 'someone' was one of your staff.

Thus ends the ticket, back to the post

The server you are on had a load average of .33 has never been down since the day of it's birth and looking through the logs I have never seen an abusive customer on it.

I can't comment on the accuracy of your internal monitoring systems, I can only report on what I'm seeing from the customer side. Also, just for the record, at no time have I ever claimed the server was down.

There's numerous different things that could have been the cause, but since you had a script checking for you instead of seeing it yourself and when you submitted the ticket it wasn't a problem we can only assume what it could have been.

The only alternative to script based monitoring is to have someone sat at a computer 24/7 clicking refresh every 5 minutes with stopwatch in hand. Not practical, really. I don't know where you get the idea that the problem wasn't ongoing when I contacted support. PHP performance was poor long before and long after I raised the ticket.

1. assuming you changed dns it could have been propagation.

Leaving aside the obvious error there The A record was new, so wouldn't have been subject to any caching issues.

2. The server you had testing it actually could have been the slow down.
3. The network you were testing it from could have been the slow down.

The metric in question (the time taken between your server accepting a request for a PHP page and that page starting to execute) is unaffected by either of those things. Regardless, if those issues had affected the results the other server being monitored by the same script from the same box would have displayed an equally large drop in PHP performance. It didn't.

4. We could have put some type of limit on it from the resource usage caused by all the testing.

That's true you could have. Frankly, I would have expected you to know one way or the other, but it's a possibility. However if, to protect your servers, you are having to cap a script that makes 1 simple SQL query, returns approx. 38 bytes and is called once every five minutes then you have bigger problems than even I imagined

5. it could have been 100 different things, but I don't see any evidence it was actually a slow down by the server.

It could have been 1,000 different things, but they would all have had to occur after your server accepted the request for the PHP script and before that script executed it's first instruction. I don't see how that could be anything other than a slow down on the server.

I really would like to see you give us another chance as I'm sure you would be happy with us. If there is ever a problem on a server we can fix it, but it has to be a problem that can be seen by more then just a script that may or may not work.

I can assure you that the script does work, but then again I would say that wouldn't I? Evil lying ex-customer that I apparently am.

What can we do to see you give us a fair chance?

I gave you a fair chance. You failed to impress. I cancelled. Don't feel bad, I'm not the easiest person in the world to please.

When I cancelled, you had every opportunity to try and convice me I had you all wrong. After filling in the cancallation form I received a reply asking me why I was cancelling. I replied with:

See ticket #DBO-344425 for details of the PHP performance issues.

To be fair PHP is running well today, however the issue isn't so much whether yesterday's problem has been resolved as much as your lack of server monitoring means there's nothing to stop it happening again tomorrow or next week.

Any PHP based website that I were to put on your hosting would be vulnerable to being rendered practically useless for half a day by the actions of one of your other customers.

and 24 hours later I had had no reply. No apologies, explainations, not even a "don't let the door hit your monitoring script on the way out"

I sent a polite nudge

Hello....

Is there a problem?

after which the cancellation was processed promptly, I enquired about the refund and was told it had been processed OK, infact this was the best experience with support throughout the entire period. It appears the best staff congregate around the exit

At this time I think its best for you just to continue denying that any of this ever happened and for me to move on to the second choice on my shortlist of new hosting companies( Yes, you were my first .... I guess we'll always have that )

Regards,

Tony

[GatorBrent]

Tony can you say you are 100% sure the fault wasn't from the server requesting? This sounds like there were network issues between our server and the server you were testing from. That could have been a network problem with our data center or the one you were testing from.


I completely believe that your script reported a problem. What I don't believe is that the problem was our server. The ticket you have with us doesn't say it's normal it's simply saying it's possible an abusive user could have been the cause. It's highly unlikely but possible....



The facts are ...

You aren't sure what happened.
We aren't sure as we weren't contacted until many hours after your script reported a slow down.

There's a few things we looked at when you contacted us.

1. server load which was low during that time period.
2. other customers contacting us reporting any slow downs which didn't happen.
3. Logs that showed no abusive users in the history of this few week old server.

4. Your script was even reporting normal speeds when you contacted us.


So here's where I'm having a problem...

You gave us a negative review based on a 20 hour period on something we didn't have a chance to fix, and may have not even been a problem on our side.


Can you please tell me what we could have done to make this right?

[deltanet]

I would have hoped that you would have extended me the common courtesy of reading my post before replying to it. Apparently not, as much of what you have just said is covered in my previous reply.

It becomes apparent that your participation in this topic has nothing to do with discovering if there was a problem with your server, but is merely an attempt to whitewash over the issue with ill-conceived pseudo-technical excuses and lies regarding when this issue was reported to you.

I grow weary of banging my head against this particular brick wall. So, unless you have anything intelligent to add, I will leave you to your delusion that low load average == everything OK.