Server Error?

See attached.

My customer gets this error when trying to run custom php scripts against a MySQL database.

She has tried it in Firefox & Chrome; same result in both.

When I do it, it works as it should (no error).

The host is GoDaddy.

Any ideas?

I'm GUESSING it's Apache; I really don't know.
Screen-Shot-2015-07-31-at-2.55.49-PM.png
Richard KortsBusiness Owner / Chief DeveloperAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

hieloCommented:
Take a look at the apache error log to see what is being reported.  Also, make a note of the exact url she is accessing.
Dave BaldwinFixer of ProblemsCommented:
It is most likely an error in your scripts that is sensitive to the REMOTE_ADDR that she is coming from.  Is she able to run any simple scripts on the same server?  I always put up a simple test script to make sure PHP itself is running.  The standard 'Hello World' script will do for that.
<?php
echo "Hello World";
?>

Open in new window

Richard KortsBusiness Owner / Chief DeveloperAuthor Commented:
Dave,

I think it's GoDaddy. I was able to run two of the processes myself, then I got the same error on another one.

Everything she was running ran earlier, many times. These are "month end reports".

I think it is execution time related; that is, the longer the script runs, the greater the odd's it will fail.

I'm setting it up to test on a NON-GoDaddy server.

Richard
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

Dave BaldwinFixer of ProblemsCommented:
I think it is execution time related; that is, the longer the script runs, the greater the odd's it will fail.
I don't see how that has anything to do with Godaddy.  The max_execution_time on both my Godaddy Linux and Windows accounts is 30 seconds as it is on my own web site account elsewhere and on Network Solutions accounts for two of my clients.  It's also the default in 'php.ini' http://php.net/manual/en/ini.list.php

Now I am responsible for two accounts that have longer execution times but you normally have to set that yourself or get your host to change it.
Richard KortsBusiness Owner / Chief DeveloperAuthor Commented:
Dave,

The customer (owner) call GoDaddy; they told him (I HAD NOT communicated what I thought to the owner) to increase the maximum execution time in php.ini.

I didn't think it was that simple on a shared hosting plan, I called GoDaddy, the tech support person said to create a file called .user.ini at the site root & put the php ini commands in there.

max_execution_time was set to 120 (2 minutes) in php.ini.

So I put ini_set('max_execution_time', 300); into that file.

What is your reaction to that?

FYI, the programs failing on Friday are running fine today (no changes) BEFORE I did this .user.ini thing.

Thanks,

Richard
Dave BaldwinFixer of ProblemsCommented:
Sounds good to me.  That only works on the Linux accounts last time I asked.  For my Windows account, I would have to recreate the entire 'php.ini' file which of course I do not have access to.
Richard KortsBusiness Owner / Chief DeveloperAuthor Commented:
Dave,

So I did that & the plot thickens. I upped the time to 300 (5 minutes). The customer ran one specific report, it gave the same server error message as last week.

Do you know if they measure max_execution_time in elapsed time or cpu time?

Thanks,

Richard
hieloCommented:
How big are these reports? Are you querying more than you need to?  A lot of developers develop the habit of executing:
SELECT * ...

but end up using only some of the fields returned in by the query.  It is more efficient if you query just for the fields that you actually need.  Also, do you have indexes on your tables?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Dave BaldwinFixer of ProblemsCommented:
Doesn't matter how they measure it.  You need to change the code to execute more quickly... or move it off the web to a local server where you can run it as long as you want.
Richard KortsBusiness Owner / Chief DeveloperAuthor Commented:
The problem is not solved.

Or, I should say, it disappeared.

Today all the reports run fine.

I did find one temporary table that was created was not being cleared out at the end (as it should have been), I fixed that.

But the cause is not clear, that was not the only report that failed.

On Friday I moved the whole database & all the php, etc., to another server I use, everything worked fine (& VERY QUICKLY) there.

So I am convinced it is GoDaddy related & will pop up again.

I am awarding points for the good ideas presented & effort.

Thanks
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Apache Web Server

From novice to tech pro — start learning today.