60 Second Shutdown

[Chrille]

I've heard that the servers shuts down PHP scripts and other scripts that runs for over 60 seconds. I find this as a HUGE problem since it limits my and others opportunities to start huge communities which requires loading time or any upload database or whatever.

Is PowWeb really ment only to server personal websites with 400gb bandwidth and 20gb discspace? No one can download or upload anything larger then 40mb with this problem and it needs to be fixed ASAP.

And I'm seeing the FTP problem on the forums everywhere and I can tell you all that it's this problem that creates your FTP issues that disconnects you etc. Remember you can't upload things for longer then 60 seconds on PowWeb, so don't even think about huge scripts for your website. Only small things work, if you don't want to upload the whole script file by file. :(

Regards

[djwtwo]

We're on shared hosting. Script timeouts can, admittedly, be annoying, but they're to be expected on shared hosting to prevent one user's scripts from monopolizing the resources we all share. If you truly have a "huge community" you may be better served by dedicated hosting.

FTP isn't subject to this limit, and I've had no problem putting large files on my site via FTP. If people are having issues with FTP timing out, it's almost certainly caused by some other issue (most of the issues of FTP reports I've seen on the forums have been reports of huge latency, not across-the-board timeouts). Download isn't subject to this limit if you're not returning the result via a script, either, so my users have been able to download these files as well. Since some scripts generate files on-the-fly, and the download time gets figured in, some folks (myself included) have had to modify a script or two to generate a temporary file that can be returned on its own, but avoiding the script limit is at least possible there.

There was initially a problem with large uploads where the upload time counted against the script execution limit, even though the script hadn't been run at that point, but that has been resolved, as far as I know.

Last I knew, large databases could be uploaded, and you can then have support actually run the import to avoid the script execution limit (this was true before migration, too.)

[ifs_it]

Chrille,

I found this thread after experiencing problems when users attempt to download files larger than 4MB. The XLS and ZIP that are downloaded end up corrupted because after ~60 seconds, the file transfer quits.
The PHP code I use for this is solid, I use it on other sites, in shared hosting environments for much larger files.

So is this true that there is a 60 second 'no matter what' time limit?

Could a POWWEB person confirm this?

Thanks!

[djwtwo]

If the file is being returned through a PHP script (through readfile() or the like), this will happen on PowWeb. It's a hard limit, and from what I understand of it from other discussions, is actually being imposed at the mod_perl level. How large a file you'd be able to cope with would be dependant on file size plus the client's bandwidth.

See this thread (http://forum.powweb.com/showthread.php?t=69026) for a workaround. There are some other threads that have discussed this, including talk from PowWeb staff. Should be easy to find with a forum search.

[rtoohil]

There's a 60 second limit on PHP scripts that are outputting data. There's no time limit (unless you're killing the server) on scripts that are uploading data.

It's not a 60 second limit on downloads. It's a 60 second limit on the execution time of PHP scripts. The reason is that, by and large, if you looked at a table of scripts that execute on a webserver, or maybe a histogram is more accurate, 99.99% of them execute in well under 10 seconds.

Of the .01% that execute in longer than 60 seconds, the vast majority are being exploited and are a major contributor to the periodic CGI slowdowns.

It's sort of the long tail effect, except in this case, the end of the tail isn't full of cool, unknown bands or authors, it's full of hackers, spammers, and general-mularkey-causers.

[tpoynton]

while i am not well-versed in scripting/php, i would like to respectfully disagree with your assertion that the vast majority of the .01% of scripts that run longer than 60 seconds are maliciuous. I ran into problems with this post-migration when i used a script to download a file to the user using the readfile() php function. the file is only about 1mb, but if the user was on a slow dial up connection, they would get cut off. not malicious, and I find it hard to believe the problem i had was uncommon. I used a workaround that is documented here in the forum and am happy now, but...

[joshuamc]

while i am not well-versed in scripting/php, i would like to respectfully disagree with your assertion that the vast majority of the .01% of scripts that run longer than 60 seconds are maliciuous. I ran into problems with this post-migration when i used a script to download a file to the user using the readfile() php function. the file is only about 1mb, but if the user was on a slow dial up connection, they would get cut off. not malicious, and I find it hard to believe the problem i had was uncommon. I used a workaround that is documented here in the forum and am happy now, but...

The issue you are referring to actually refers to a bug we had in on mod_perl layer. That was fixed (http://forum.powweb.com/showthread.php?t=69148).

[tpoynton]

The referenced thread(s) talk exclusively about htaccess. I do recall a bug being addressed that fixed this for uploads, but not downloads. Since I do not have a good way of testing this, I am going to leave things alone, and will have to take your word on it.

perhaps this thread (http://forums.powweb.com/showthread.php?p=395296) is a better reference? It says it 'should' resolve most problems. Can you say explicitly that files being downloaded using the readfile() PHP function that take longer than 60 seconds (due to file size or slow connection) will not timeout? Being explicit just might put this thorny issue to bed...

[rtoohil]

I'm not saying that there aren't people doing legitimate things with PHP/Perl/Python that don't get bit by the 60 second limit. But believe me, the vast majority of scripts that get executed on our servers that run over 60 seconds are not doing legitimate things. They're, almost without exception, someone's poorly written PHP script or old phpBB/some other install that's not been updated in years and gets exploited.

At that point, the script causes that server to, in essence, act as a zombie for the exploiter as they attempt to setup botnets or send out thousands of messages of spam. We have lots of ways of locking these accounts down, but the 60 seconds timeout helps a lot.

Unfortunately, this does impact downloads. It does not impact uploads.

All this being said, we're constantly evaluating our setup and looking for ways to improve it. We might find another way of monitoring CGI exploitation and overuse, and then be able to remove the limits.

The flipside of the limits, of course, is probably moving to some sort of timeslicing universe where you can only use X% of CPU usage per hour (or something like that). I find that method less attractive because it brings your site down if you do something silly in your script or get exploited, but maybe that's better to bring the issue to the creator's attention.

In any event, to not bury the lede, the 60 second script timeout will eat downloads that go through PHP and get sent out as an octet stream.

[tpoynton]

Thanks for the detailed, candid response!

[ShotoDojo]

All this being said, we're constantly evaluating our setup and looking for ways to improve it.
The good news is, this is one of the few times (the ONLY time I can remember having seen in the forums) where something is said that the bottlenecks might (just might) be fixed.
Everywhere else seems to say "The limit is fixed and it's not going to change." That translates to "Eat <stuff> and die."
I'm not saying that there aren't people doing legitimate things with PHP/Perl/Python that don't get bit by the 60 second limit.
We might find another way of monitoring CGI exploitation and overuse, and then be able to remove the limits.
The flipside of the limits, of course, is probably moving to some sort of timeslicing universe where you can only use X% of CPU usage per hour (or something like that). I find that method less attractive because it brings your site down if you do something silly in your script or get exploited, but maybe that's better to bring the issue to the creator's attention.
The bad news is, they keep swatting at mosquitos with sledge hammers (and I think the mosquito landed on their forehead some time ago).
If you are looking for script expoitation, why not look for script expoitation? If you are looking for overloading the server, why not look for overloading the server?
Shared processing has been around for over 40 years. It's called timesharing, and except for some silly moves early on (such as favoring the infinite loop), it is pretty cut and dried.

Try this on for size:
The script engine runs your script. If it hits xx seconds running, then your script is suspended and every other script in the queue gets to run before you get to run again. If you run more the yy times (say, ten), then everybody else in the queue gets to run zz times before you run (unless they also are over yy).
Meanwhile, Unix/Linux/Whateverix keeps everything else running in between the moments the script engine actually wants CPU time.
And beyond a certain total time, a message can be sent to the PowWeb Cops and to the user, that his script is suspect.

Simple and easy. Your script will run to completion eventually. The bigger/longer it is, the slower it runs. Unless no one else is wanting the engine. But it runs. And if it is really suspicious, the Cops come in and look.

[rtoohil]

Try this on for size:
The script engine runs your script. If it hits xx seconds running, then your script is suspended and every other script in the queue gets to run before you get to run again. If you run more the yy times (say, ten), then everybody else in the queue gets to run zz times before you run (unless they also are over yy).
Meanwhile, Unix/Linux/Whateverix keeps everything else running in between the moments the script engine actually wants CPU time.
And beyond a certain total time, a message can be sent to the PowWeb Cops and to the user, that his script is suspect.

Simple and easy. Your script will run to completion eventually. The bigger/longer it is, the slower it runs. Unless no one else is wanting the engine. But it runs. And if it is really suspicious, the Cops come in and look.

There's absolutely other ways of doing timesharing. Some hosts allocate you hourly/daily/monthly CPU limits and when you exceed them you're done for the day (unless you go in and pay more money). Round-robin timesharing would work with the exception that we'd get thousands of support calls wondering why a script was taking minutes/hours/days to finish. At least today we can give an answer, even if it is not one that everyone likes.

[SPS]

I think it's time that someone from the benchwarmers spoke to this issue. Amidst all of the technical finger pointing on ways to best handle this problem, there has been no mention of customer satisfaction.

Powweb: Your paying customers are ALWAYS right. If a customer violates any part of their agreement, then you should terminate their account. Whose idea was it to implement such a drastic "line in the sand" attitude with the rest of us? It appears as though the easiest solution for you was forced on your customer base with no warning or explanation until it was too late. Stop blaming your customers’ script writing ability for actions they had nothing to do with.

If Powweb's new direction on growth is geared toward a small, agile group of webmasters that enjoy the challenges of an ever-changing landscape; then you're on the right path.

I've been a customer for 5 years and switched to a new provider today.

[YvetteKuhns]

If Powweb's new direction on growth is geared toward a small, agile group of webmasters that enjoy the challenges of an ever-changing landscape; then you're on the right path.

I would prefer to be on that type of web hosting, because there would be a lot less problems, but...

Amidst all of the technical finger pointing on ways to best handle this problem, there has been no mention of customer satisfaction.

We did argue these points in several threads. The blame is on both the web host and the customer. For every action, there is a reaction. I do agree that the current handling of the problems is less than satisfactory in comparison with the PowWeb method before Endurance. The servers are different and the procedures are different.

Everyone is demanding change. Endurance wants us to change things. We want them to change things. We all have to work together. I have clients on other web hosts and most others wouldn't give us this must attention or consideration. You get what you get and there is no compromise.

In all my years, I personally have not had a script or site disabled, though there were a few times a form processing script was exploited to send spam. That is common anywhere. The script was changed or renamed and the problem was solved. Of course, that was the preEndurance PowWeb. Maybe Endurance would handle things differently, but it depends on how badly the server was affected.

I feel stuck in the middle here. I feel that customers should do their best to keep their sites running smoothly for the sake of everyone - themselves, their visitors, others on the server and the web host. If there is a problem observed by the web host, the web host should notify the customer and everyone should do their best to resolve things quickly. If someone repeatedly makes the same mistake or does not actually take the necessary steps, then disable that account.

There are people who are not programmers that try to run their own websites. They make honest mistakes and don't deliberately try to disable anyone's website or server. If you have no tolerance for anyone who makes a mistake, then you must be perfect! Nice for you! The rest of the humans should be treated as such.

[SPS]

I feel that customers should do their best to keep their sites running smoothly for the sake of everyone - themselves, their visitors, others on the server and the web host.

My intention with my response was not to initiate debate. I've already elected to let my last year of blind loyalty expire. I do feel like your point should be addressed though, because it lies at the heart of what I see happening more and more.

We are paying customers… not club members.

With forums becoming more and more popular as a support tool, it creates a new paradigm for customer service that few companies understand. What usually happens is occurring here. This is not a club of tech enthusiasts where the gifted become elitist members. Company representatives should not behave as anointed brawlers by stepping into these frays with excuses and "never-wrong" attitudes.

These forums should be viewed as an opportunity by the hosts as a way of listening to what their customers want. It takes a special kind of person to deal with constant criticism though. Not every technically-minded expert has the constitution for it. When they feel that the majority of the forum’s users “has their back” on general issues, it will become easier to fight back instead of listening to the smallest of voices.

If anyone still disagrees with what I’m saying… snip this thread and hang on to it. Whenever a company that you’re paying treats you like you don’t really matter, read it again. It will happen.

[rtoohil]

I'd just like to say that I'm not saying that we're not wrong. In an ideal world, we wouldn't need limits or have any issues.

However, the way things are currently setup, it's something we need to do. It doesn't mean it will always be that way -- it simply means that right now it's what we need to do. Believe me, we're listening!

Or, if you want to take the nefarious viewpoint, Joshua is listening and we just ignore him and tell him to go play ping-pong.

[IanS]

Or, if you want to take the nefarious viewpoint, Joshua is listening and we just ignore him and tell him to go play ping-pong.
Is he any good at the Ping Pong then? :D

[YvetteKuhns]

Joshua is listening and we just ignore him and tell him to go play ping-pong.

I don't believe you tell him to play ping-pong. I think he is the PR guy to tell us what we want to hear. ;)

[joshuamc]

Is he any good at the Ping Pong then? :D

I don't want to toot my own horn, but....Ryan can confirm. Although, he's never played me. I guess that's a good thing for him. :) On the other hand, I've never played Ryan in foosball and he apparently just won the big tourny.

I don't believe you tell him to play ping-pong. I think he is the PR guy to tell us what we want to hear.
HA! If only.

[IanS]

I don't believe you tell him to play ping-pong. I think he is the PR guy to tell us what we want to hear. ;)
Unfortunately for Josh, he often has to bear us bad new, things we don't want to hear :(

[YvetteKuhns]

Well, at least he is honest.

[joshuamc]

It's a job that takes ____ of steel. Argg. :)

[YvetteKuhns]

It's a job that takes ____ of steel. Argg.

Fill in the blank. Hey, I saw a video called BUNS of steel. I guess that is why you don't need an office chair. ;)

[joshuamc]

Fill in the blank. Hey, I saw a video called BUNS of steel. I guess that is why you don't need an office chair. ;)

Now that's just nuts.

[YvetteKuhns]

Now I have a vision of that darn Squirrelmail squirrel for nuts. Or those decorations hanging from big trucks. :D

[snowmaker]

Now I have a vision of that darn Squirrelmail squirrel for nuts. :D

:cool:

[Doc C]

It warms my heart to see you all playing nice for a change. :p

[YvetteKuhns]

Do you have these? (http://www.truck-nuts.com/index.html)

[Chrille]

Bump

I didn't mean to ruin your conversation about nuts :P

But are PowWeb working on something to solve this 60 second problem?

Regards

[YvetteKuhns]

Remember you can't upload things for longer then 60 seconds on PowWeb

but the 60 seconds timeout helps a lot.

Unfortunately, this does impact downloads. It does not impact uploads.

Hmmm... I haven't tried to upload anything that would take longer than 60 seconds. I do have high speed Internet, though. I believe there is a problem, because we could not successfully upload a backup of a database that was zipped.

[NeilFawcett]

The 60s limit was put in a long time ago. Don't forget there is also (or was at least) a 20s CPU limit as well.

So if you process hits 20 seconds of CPU usage it gets nuked.

[rtoohil]

I believe there is a problem, because we could not successfully upload a backup of a database that was zipped.

I think that's a slightly different beast, if you're talking about uploading via phpMyAdmin. phpMyAdmin fails because it attempts to upload the file, then unarchive it, then import it. It definitely falls prey to the 60 second timeout.

Having dealt with phpMyAdmin at other webhosts as well, it's unfortuantely not a terribly unique situation. Previously, to move a friend's message boards, I was breaking the database dump into manageable text chunks and executing from the phpMyAdmin SQL console.

It only took about 4 hours to move the message board ...

[joshuamc]

I think that's a slightly different beast, if you're talking about uploading via phpMyAdmin. phpMyAdmin fails because it attempts to upload the file, then unarchive it, then import it. It definitely falls prey to the 60 second timeout.

Having dealt with phpMyAdmin at other webhosts as well, it's unfortuantely not a terribly unique situation. Previously, to move a friend's message boards, I was breaking the database dump into manageable text chunks and executing from the phpMyAdmin SQL console.

It only took about 4 hours to move the message board ...

There's this really cool script that let's you upload your tar.gz or zip of the sql dump to a folder and then it will take care of importing it in such a way that the script doesn't time out. I'm just having a hard time finding it. I'll google more later when I have time.

Edit: Maybe i'm confusing two different things, but this might be helpful for someone who wants to import a large db: http://forum.powweb.com/showthread.php?t=60555

[YvetteKuhns]

I think that's a slightly different beast, if you're talking about uploading via phpMyAdmin.


Actually, we were trying to upload a backup for a client in another state to download through FileZilla, because she couldn't get it through OPS!

There's this really cool script that let's you upload your tar.gz or zip of the sql dump to a folder and then it will take care of importing it in such a way that the script doesn't time out.

http://www.ozerov.de/bigdump.php