500 Internal Server Error on GoDaddy hosting

ZC 1.3.8a
HTTP Server: Microsoft-IIS/7.0
PHP Version: 5.2.5
Database: MySQL 5.0.91

I keep getting more than the occasional 500 error, several a day in fact. My site will be humming along fine but then I'll notice it beginning to bog down until finally I receive the 500 error.
I ran mysqlcheck and found nothing amiss there, so I'm wondering if a script is causing the hang up.

Could someone with firebug or wedev take a quick peak and tell me if there might be an issue with a script or two?
Tidy isn't showing me anything critical but I'd appreciate some fresh eyes and or opinions.
http://minu.me/2tc5

Thank you,
Stephen

jabbawest:

My site will be humming along fine but then I'll notice it beginning to bog down until finally I receive the 500 error.Have you talked to your hosting company about this problem? Sounds like a server issue.

Plus, about the "scripts" you mention (I assume you mean "javascript" since you talked about checking with firebug), unless they're doing ajax, then the 500 error is almost certainly unrelated, since a "500 Internal Server Error" is being sent to you by the server, when it encounters an error ... and javascript doesn't run on the server (it runs in the browser only).

A good server administrator will be able to find specific error details explaining the cause of "500" errors in the server logs. That's the best place to start when trying to figure out what's causing those problems.

I've talked with the G.D. hosting, and unfortunately, since I'm on Windows hosting, there's no database error logging option.
I ran the same mysqlchecks they did and came up with bupkiss, just like they did.
This didn't start happening until I received my SSL cert and was moved onto another server.
Guess it's time to kick up the support level a notch tomorrow, no wait, Monday would probably be better.

Thanks Dr. Bytes

They have a very consistent reputation of overloading their servers (actually "overselling" to line their pockets, which causes overloading of CPU resources) and denying it, as well as offering very poor support. Sometimes if you're persistent enough you can escalate up several levels to senior tech support staff who might actually know something and thus might be able to do something to help you. Usually before you can get that far you experience numerous attempts to upsell you to a more expensive hosting plan which promises to be much better because they say it can be customizable more to your own needs. But the truth is that what they're upselling you to is only good for a few weeks/months until they oversell that server too. Plus, you can get even better server capability if you go with a real hosting plan with a company who hosts Zen Cart sites specifically, so it's worth going there long before you waste even another dime on sticking with GD.
Or, at least that's my experience anyway. Hundreds of others have reported similarly.
Good luck escalating to the top. Be very persistent and don't take no for an answer until you get someone who is giving you real solutions.

Well, I could not wait so I called GD and they checked their server logs for errors at the time stamps I provided them and came up with nothing on there end.

Doing some research on the issue I found that it could be a problem with a script on my end that is not compatible with the ASP.Net 2.0/3.0/3.5 but was written for a previous version.
GD also claimed that they had not been getting any similar support calls regarding the particular server I'm on.

Here's what my web.config error checking is reporting:
http://minu.me/2tdx

http://minu.me/2te8> I have a same problem with two installs(6.10, 6.9) on my hosting. CGI scripts just ocasionally timeout and the result is error 500

Tried couple things and cannot figure it out. Looks like more and more people see the same thing though.
Problems occure when I try to do different things but most often when accessing modules settings. Sometimes it happens on let's say trying to add content.
Often after refresh everything works well. And usually changes are done (like content is added/modules activated).

Actually, now that I think about it, this does seem to be the scenario when the 500's occur.
I, or my wife, are adding product, fixing descriptions and the like through the admin when it occurs.

So, you're saying that when working in your admin area, editing products, you're getting a message saying:

"HTTP Error 500.0 - Internal Server Error C:\php5\php-cgi.exe - The FastCGI process exceeded configured activity timeout"

I've pm'ed the good Doctor about this with some details that should remain private, but for any one else that may be watching, let's see if this might sound like a plausible scenario for the cgi error that's causing the 500 errors.

I only have one file in my cgi-bin folder and that would be a sitemapxml.php which is related to Andrew Berezin's Sitemap XML Feed module.
With that said, while working on the backend adding product or updating a description, the sitemapxml.php writes that new information to the various file like, sitemapproducts.xml and causes the 500 error until the data has been passed on.

Does that sound possible??

DrByte:

So, you're saying that when working in your admin area, editing products, you're getting a message saying:

"HTTP Error 500.0 - Internal Server Error C:\php5\php-cgi.exe - The FastCGI process exceeded configured activity timeout"
Yes, but the error is site wide.

As for sitemapxml, if you think it's maybe the problem, then turn it off to rule it out. I doubt it's related, but rule it out anyway.

jabbawest:

Yes, but the error is site wide.
And is there a long delay between your last click and when you get that message? Have you timed that delay? How long is it? Is it consistent?

DrByte:

And is there a long delay between your last click and when you get that message? Have you timed that delay? How long is it? Is it consistent?
The wife just made some changes, she went to look at them and the page loaded.
A few seconds later, I went to see if an error would occur, and it did.
It took approximately 30 seconds for the 500 error to return.

We are going to try to replicate it and do a full documentation as to how long between the time an edit is made until the 500, the time it takes for the page to return the 500, and how long it takes for the page to come back.

The normal configuration for PHP timeout is 30 seconds. And, based on the information you shared in PM, your server is also set up for 30 seconds max processing time on any page. Normally that's fine.

What's "wrong" is whatever is happening on your server to cause something that should take 0.5 seconds to take longer than 30. An overloaded server (either the webserver side or the database side, or both) could be the cause. Or a server with pending hardware failures could too. Or a poorly-managed/poorly-configured server could also do that.

I recommend you keep regular frequent (at least daily) backups of your server files and database, just in case there's a hardware problem looming. Well, backups should be done regularly anyway.

If you're using regular default Zen Cart code without customizations/addons that are doing lots of other additional things in the background every time you "click" to do something, then the symptoms you're experiencing are very likely a server problem. If you're using several addons/customizations that add additional calculation or database requirements, then those might be suspect too.

Dr. Bytes, I've forwarded your concerns onto GD, disabled the sitemapxml module for now and will continue posting about what I'm told and what's happening.

Unfortunately, the replications we tried to do based on the sitemapxml mod theory didn't produce the 500 errors, so I could have jumped the gun a bit there, unless we just missed the event of it writing new data because it's probably a timed event.
Then again, I could be all wrong on that theory.

If what GD is telling me about not receiving calls concerning that server is true, then I guess there could be something not right with the database/server/file interaction that could be caused by one of my addons??

Oh bother.

One way to quickly rule out the server would be to copy the store to another server with another hosting company and see if your current problems follow you.
https://www.zen-cart.com/tutorials/index.php?article=100

DrByte:

One way to quickly rule out the server would be to copy the store to another server with another hosting company and see if your current problems follow you.
https://www.zen-cart.com/tutorials/index.php?article=100

Just got off the phone with GD and they are going to migrate me over to a Grid server from the Legacy (What a graceful way to say OLD) server I'm currently on. Why I wasn't on a Grid server begin with is another story.
I'll give that suggestion a shot tomorrow.
Ya' know, I'm glad as all get out I've been on a month to month with GD.

As for your suggestion Dr. Byte, I think I will give that a shot too, just to be sure my site isn't contributing to the slowdowns.

Thanks for all of the help and I'll keep ya' posted.

Don't count on their Grid hosting solving anything. I've heard horror stories of it being much worse.

"GRID" - - "Cloud" - - and others are great for a static site
Just not at all beneficial to a DB intensive dynamic install like ZenCart

Don't forget that scripts also take longer to run under https, and that script is using an https url. Normally this would not be a problem, but it seems that it is with GoDaddy.

Vger

Ok, I'm looking to change and have started a suggestion box thread.

But something odd just occurred while logging into my site admin.
While logging in I received a cPanel Great Success notification written on it, which I haven't seen in years.
It happened again after I changed the password on my wife's admin account.
Just to be sure, I inspected the element and voila, it was what I thought it was, but GD doesn't use cPanel, and even if they did, why would I receive that message on my site admin login??

See screen shot. Any thoughts??