|Web host says I crashed the server|
I'm a self-taught PHPer.
My site was running fine until a week ago when the server seemed to be down a lot. When I contacted my web host, they said they would transfer my site to a seconday, "more" stable server. That's when my nightmare began.
After moving to the new server, they asked me to change my scripts to accomodate the register globals. Last night, my site got suspended. Web host says that one particular page is maxing out their CPU's 3GHz processing. This never happened before (my site has been up 2 years).
One possible explanation (I thought of) was that web owners were leaving them and due to shortage of funds, they have had to downgrade their servers package. Is this logical?
If not, Why would or could such a thing suddenly happen supposedly caused by a page that has hardly been updated? Virus?
Anyone? I'm in limbo right now... site is down and don't know what to do.
Well, maybe they are just speaking the truth.
Analyze the script that the host says is maxing out their CPU. Is there a hidden bug in it? A loop which uses increasing CPU time when the number of data items increases? Many calls to an external database?
As a professional programmer I know that every code may contain bugs, or unoptimized parts which seem to run fine when running in a small controlled environment but which produce weird results once the environment changes or dataset sizes increase.
|Well, maybe they are just speaking the truth. |
agreed... like I said... I am self taught in PHP. My skills are FAR from perfect!
Actually after re-reading my post it even sounded to me like I'm trying to shift the blame... I'm not. I'm just curious why my page is suddenly the cause of the server crashing. No changes to the page and not much change in traffic. Also only 2 records added the past month.
|Analyze the script that the host says is maxing out their CPU. Is there a hidden bug in it? |
Is there a systematic way to find such a bug?
|A loop which uses increasing CPU time when the number of data items increases? Many calls to an external database? |
My page calls to one database twice. My database consists of approx 500 records each about 300 words in length. My script merely retrieves a record and displays it. How many calls is too many?
|As a professional programmer I know that every code may contain bugs, or unoptimized parts which seem to run fine when running in a small controlled environment but which produce weird results once the environment changes or dataset sizes increase. |
can you point me to a good resource to learn?
I haven't had any CPU-usage issues with PHP lately, but in the old days, I had some bugs where missing or inappropriate GET paramaters would cause PHP to go into a loop. I don't know exactly what was going on.
I would ask the host to turn your site back on for a little bit, and then you go through all of your pages, submit all of your forms, and see if you can duplicate the problem. If the CPU is really being pegged, then you should be looking at an unresponsive page at that moment.
Also, check all of your form-handling scripts for proper cleaning of the GET/POST variables.
I had a slow performance on one of my busy sites, I solved the problem by caching the php pages. Might be something you could do too.
|My page calls to one database twice. My database consists of approx 500 records each about 300 words in length. My script merely retrieves a record and displays it. How many calls is too many? |
Could you post the pertaining script
I would definitely try to work on your PHP skills, and analyze your script.
That being said, PHP can be configured to be quite safe. They may want to look at the way their server is set up.
I have an ISP that has a very annoying "blame the customer first" customer support policy. It drives me batty, because they are an excellent and cheap ISP, but I always have to go through the %$#@! "Is your computer plugged in?" crap before I get them to admit that yes, they did upgrade MySQL last night, and gee, they forgot to reset the usage meter, etc.
Well my new host seems to great for now. No problems with the page.
|I had some bugs where missing or inappropriate GET paramaters would cause PHP to go into a loop.... Also, check all of your form-handling scripts for proper cleaning of the GET/POST variables |
Am checking all pages now to see what can be done... that's a lot of pages! Sorry.. but what do you mean by "cleaning" of the GET/POST variables? Do you mean re-initializing?
|I had a slow performance on one of my busy sites, I solved the problem by caching the php pages. Might be something you could do too. |
Definitely could be part of the problem. Of ALL my pages, this is the one that doesn't allow caching because I read on another section of this forum how caching allows easy copying and plagiarizing content. If the new web host holds up, I will then ask them to monitor CPU usage during my busy periods and try to peg the section of that page that is supposedly causing the problem.
|I would definitely try to work on your PHP skills, and analyze your script. |
This is going to sound really crappy, but with running my businesses and maintaining my sites I learn as I go along... what I mean is I tend to learn only the stuff that I need for the moment! (... avoiding apples being thrown at me!)
Cleaning is essentially ensuring that you're getting back what you think you're getting. For example, just because you set up a set of radio buttons for someone to click, a mischievous person could craft the POST returned and substitute a little mini-SQL statement for the simple numeric result you'd planned on. Then when you INSERT that into your database, the mini-SQL gets executed as well, wreaking havoc on your data or even displaying something in the person's browser that you really don't want to be showing. That's called SQL injection.
You prevent it by using functions like intval() on values you know should oughta be integers, using the returned values as lookups in arrays (since they can't be manipulated on the other end), using msql_real_escape_string(), etc. There's good articles around the internet on it. I haven't been here long enough to know what's right here on webmasterworld on the subject - I expect a search would yield some good stuff.
Yes indeed we have about a ton and 1/2 good posts about security and injection
One item I really like is to foresee how may char and spaces could be used and set a limit for ex: using strlen(), I do a double check A) using preg_match() and (kind of over killer) B) eregi() to look for signs that could be used in SQL injection
Not to mention
But to go back to your example
Check boxes or DD boxes
I check if the user is sending me the expected values
As you know and that's really what a PHP newcomer needs to fathom is
“How will I make sure that data sent is the data expected?”
“Could I do something before it reaches my DB?”
This one could be answered by using a SWITCH
Imagine you ONLY expect Yes or No
Then you set two cases a yes and a no
If the $_POST value when red in an Array is not yes or not
Then .. ALERT and exit()
The very first precautions I take when dealing with registered users
Is to secure the registration form
You may use
A function to disallow any CC
Set a spammer trap by setting an user invisible email field then check if (!empty) and exit()
Check that UN and PW are unique, allow only for a single registration
Check the IP is from an acceptable IP location
Check my bad_words function
Check that email address is well formed
And using getmxrr() validate the domain
Of course I set some rand() to be manually entered before accessing any form
I'd do some more checking along the lines of what mcavic suggested ... in the dat being sent to your server as GET or POST.
Your hosting provider asked you to modify your scripts to conform to their register_globals settings (probably "off" on the new server and "on" on the old), so you probably went in and changed stuff like
$username=$_GET['user']; ... which leads me to think that it might indeed be a mishandling of the $_GET or $_POST arrays, perhaps even creating a loop as PHP parses through those arrays.
Despite what some people might say PHP is quite robust, especially on servers of the current generation. It takes more than 500 database entries to consumate all CPU power, even with the worst programming.
Without examining the original script and running it on a server with profiling capability, analizing the issue is like poking in the dark. Here is what I would do.
First, install a server (Apache, PHP, MySQL) on your local computer. XAMPP will help you there. This way you can monitor the script directly.
Second, install and run the script on one of those free hosting servers. Some of them actually offer MySQL databases and enough web space to run serious stuff there. I imagine that those free accounts do not get the full power of the system which would show you how the script would run under limited conditions.
And if you still have no clue after that and if you really are concerned about it, maybe it is time to let a professional take a look at it.
All the best.
i've had a host tell me the same thing before, but it turns out as being a cheap host.. they were overstuffing their servers and my site was the biggest one, so they axed me.
wouldn't have known otherwise if it hadn't happened to others