php execution time

[Rozmaha]

Hey, so quick question, what would be a good time to set for execution
time using set_time_limit if I wanted to upload say a 100 mb file. I
know bandwidth and everything is important to know, but maybe if you
could give me a good number that works in any case.

Thanks

[AnrDaemon]

Greetings, Rozmaha.
In reply to Your message dated Thursday, June 26, 2008, 23:19:48,

Hey, so quick question, what would be a good time to set for execution
time using set_time_limit if I wanted to upload say a 100 mb file. I
know bandwidth and everything is important to know, but maybe if you
could give me a good number that works in any case.

1. set_time_limit has nothing to do with file uploads, unless you are uploading
files from your script (using cURL i.e.)
Refer to the
http://www.php.net/manual/en/info.co...max-input-time
instead.
2. Use FTP for such big files.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[C. (http://symcbean.blogspot.com/)]

On Jun 26, 9:10 pm, AnrDaemon <[e-mail]:

Greetings, Rozmaha.
In reply to Your message dated Thursday, June 26, 2008, 23:19:48,

Hey, so quick question, what would be a good time to set for execution
time using set_time_limit if I wanted to upload say a 100 mb file. I
know bandwidth and everything is important to know, but maybe if you
could give me a good number that works in any case.

1. set_time_limit has nothing to do with file uploads, unless you are uploading
files from your script (using cURL i.e.)
Refer to thehttp://www.php.net/manual/en/info.configuration.php#ini.max-input-time
instead.
2. Use FTP for such big files.

--
Sincerely Yours, AnrDaemon <[e-mail]>

FTP sucks - for lots of reasons. HTTP[s] is a far more sensible
protocol for moving files in either direction. For the best
performance/security use scp or rsync over ssh.

C.

[Jerry Stuckle]

C. (http://symcbean.blogspot.com/) wrote:

On Jun 26, 9:10 pm, AnrDaemon <[e-mail]:

>Greetings, Rozmaha.
In reply to Your message dated Thursday, June 26, 2008, 23:19:48,

>>Hey, so quick question, what would be a good time to set for execution
time using set_time_limit if I wanted to upload say a 100 mb file. I
know bandwidth and everything is important to know, but maybe if you
could give me a good number that works in any case.

1. set_time_limit has nothing to do with file uploads, unless you are uploading
files from your script (using cURL i.e.)
Refer to thehttp://www.php.net/manual/en/info.configuration.php#ini.max-input-time
instead.
2. Use FTP for such big files.

--
Sincerely Yours, AnrDaemon <[e-mail]>

FTP sucks - for lots of reasons. HTTP[s] is a far more sensible
protocol for moving files in either direction. For the best
performance/security use scp or rsync over ssh.

C.

Wrong. FTP is much faster and more efficient when transferring files -
because that's what it is specifically designed for.

I would never handle such large files over http - it's missing some good
features, such as resume capability. Then there's the conversion of new
line characters for text files. And bunches of other things.

And if you want security, there's sftp.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Michael Fesser]

..oO(C. (http://symcbean.blogspot.com/))

>FTP sucks - for lots of reasons. HTTP[s] is a far more sensible
protocol for moving files in either direction.

FTP may be old and ugly, but it's still the most efficient way for file
transfers. That's why it's called file transfer protocol ...

Micha

[C. (http://symcbean.blogspot.com/)]

On Jun 27, 2:37 pm, Michael Fesser <[e-mail]:

.oO(C. (http://symcbean.blogspot.com/))

FTP sucks - for lots of reasons. HTTP[s] is a far more sensible
protocol for moving files in either direction.

FTP may be old and ugly, but it's still the most efficient way for file
transfers. That's why it's called file transfer protocol ...

Micha

NO IT IS NOT.
- It has no built-in support for compression
- It has no caching functionality
- It has no error detection
- The line-endings thing is only defined for 7-bit ascii (0 padded to
8 bits per char)
- It sends passwords in clear text (although basic HTTP auth is little
better)
- Unless you use the passive hack or a clever firewall it will not
traverse NAT
- It only provides file-system level access
- It doesn't not have any functionality for sending meta-data

Yes, it allows you to range operations (resume) but so does HTTP (inc
webDAV) and range operations are implicit in rsync.

....and that's before I get started on the vagaries of specific
implementations.

C.

[Jerry Stuckle]

C. (http://symcbean.blogspot.com/) wrote:

On Jun 27, 2:37 pm, Michael Fesser <[e-mail]:

>.oO(C. (http://symcbean.blogspot.com/))

>>FTP sucks - for lots of reasons. HTTP[s] is a far more sensible
protocol for moving files in either direction.

FTP may be old and ugly, but it's still the most efficient way for file
transfers. That's why it's called file transfer protocol ...

Micha

NO IT IS NOT.
- It has no built-in support for compression

Neither does HTTP in most cases.

- It has no caching functionality

Wrong.

- It has no error detection

Wrong.

- The line-endings thing is only defined for 7-bit ascii (0 padded to
8 bits per char)

Wrong.

- It sends passwords in clear text (although basic HTTP auth is little
better)

Wrong. (sftp)

- Unless you use the passive hack or a clever firewall it will not
traverse NAT

Same with http. And passive mode is not a "hack".

- It only provides file-system level access

It is FILE transfer protocol, after all.

- It doesn't not have any functionality for sending meta-data

FILES don't have metadata.

Yes, it allows you to range operations (resume) but so does HTTP (inc
webDAV) and range operations are implicit in rsync.

...and that's before I get started on the vagaries of specific
implementations.

C.

OTOH, HTTP has significantly more overhead, size limits, is much slower,
cannot resume an interrupted transfer...

You really should learn what you're talking about before you make claims
like this.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Michael Fesser]

..oO(C. (http://symcbean.blogspot.com/))

>On Jun 27, 2:37 pm, Michael Fesser <[e-mail]:

>.oO(C. (http://symcbean.blogspot.com/))

>FTP sucks - for lots of reasons. HTTP[s] is a far more sensible
protocol for moving files in either direction.

FTP may be old and ugly, but it's still the most efficient way for file
transfers. That's why it's called file transfer protocol ...

Micha

NO IT IS NOT.
- It has no built-in support for compression

Just a minor issue and easily solved with explicit compression (.gz for
example).

>- It has no caching functionality

Why would you need that for file transfers? Where and what would you
like to cache?

>- It has no error detection

Neither does HTTP. TCP ensures correct transfers. If you have to check
the file integrity, you have to use MD5/SHA1 hashes anyway, independent
of the used transfer method.

>- The line-endings thing is only defined for 7-bit ascii (0 padded to
8 bits per char)

Who cares about line endings? Binary transfer works almost always. Only
some old and broken software relies on OS-specific line endings. In my
FTP program the only file extension for ASCII transfers is .pl. All the
rest is seen as binary, which is how it's supposed to be, because I want
my files to be transferred exactly as they are.

>- It sends passwords in clear text (although basic HTTP auth is little
better)

sFTP exists if necessary.

>- Unless you use the passive hack or a clever firewall it will not
traverse NAT

That's IMHO the only real drawback. A NAT router has to look into the
actual payload, not only at the packet headers (but other protocols have
the same problem and routers are usually prepared for that). NAT routing
of sFTP is even more complicated, but also possible.

>- It only provides file-system level access

Of course it does. What else would you expect from a _file_ transfer
protocol?

>- It doesn't not have any functionality for sending meta-data

What meta data do you need? How should that meta data be stored in the
several file systems? Which file systems actually do that?

Remember: We are talking about raw files here, not about some document
like an HTML page that's going to be interpreted by a viewer/browser.

>Yes, it allows you to range operations (resume) but so does HTTP (inc
webDAV) and range operations are implicit in rsync.

rsync is nice, but requires a server, which is not always available. You
would hardly find it on a shared host, while FTP is always there.

Micha

[I V]

On Sun, 29 Jun 2008 08:35:25 -0400, Jerry Stuckle wrote:

>- It sends passwords in clear text (although basic HTTP auth is little
better)

Wrong. (sftp)

You do know that the only thing SFTP has in common with FTP is the three
letter "FTP", right? They're completely separate protocols.

[Jerry Stuckle]

I V wrote:

On Sun, 29 Jun 2008 08:35:25 -0400, Jerry Stuckle wrote:

>>- It sends passwords in clear text (although basic HTTP auth is little
better)

Wrong. (sftp)

You do know that the only thing SFTP has in common with FTP is the three
letter "FTP", right? They're completely separate protocols.

Not at all. They are separate - but related.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jerry Stuckle]

I V wrote:

On Sun, 29 Jun 2008 08:35:25 -0400, Jerry Stuckle wrote:

>>- It sends passwords in clear text (although basic HTTP auth is little
better)

Wrong. (sftp)

You do know that the only thing SFTP has in common with FTP is the three
letter "FTP", right? They're completely separate protocols.

Ah, I just realized the lack of communications. I was talking about FTP
over SSH - not used very often, but available. I think you're talking
about SSH File transfer - much more commonly used.

Sorry I wasn't more clear.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Michael Fesser]

..oO(I V)

>On Sun, 29 Jun 2008 08:35:25 -0400, Jerry Stuckle wrote:

>>- It sends passwords in clear text (although basic HTTP auth is little
better)

Wrong. (sftp)

You do know that the only thing SFTP has in common with FTP is the three
letter "FTP", right? They're completely separate protocols.

Depends. SFTP has different meanings. There is a protocol called SFTP,
but FTP through an SSH tunnel and FTP over SSL are also often called
SFTP (or FTPS in the latter case).

Micha

[Peter H. Coffin]

On Mon, 30 Jun 2008 13:05:32 +0200, Michael Fesser wrote:

.oO(I V)

>>On Sun, 29 Jun 2008 08:35:25 -0400, Jerry Stuckle wrote:

>>>- It sends passwords in clear text (although basic HTTP auth is little
better)

Wrong. (sftp)

You do know that the only thing SFTP has in common with FTP is the three
letter "FTP", right? They're completely separate protocols.

Depends. SFTP has different meanings. There is a protocol called SFTP,
but FTP through an SSH tunnel and FTP over SSL are also often called
SFTP (or FTPS in the latter case).

SSH-tunneled FTP is still FTP, and I wish people would quit trying to
label stuff that happens to be tunneled differently from the straight
protocol. It's not "w-FTP" because you happen to have an 802.11b hop in
the mix, is it? SSL-wrapped FTP is FTPS; it's only called SFTP by the
gormless.

--
"... I've seen Sun monitors on fire off the side of the multimedia lab.
I've seen NTU lights glitter in the dark near the Mail Gate.
All these things will be lost in time, like the root partition last week.
Time to die...". -- Peter Gutmann in the scary.devil.monastery

[Jerry Stuckle]

Peter H. Coffin wrote:

On Mon, 30 Jun 2008 13:05:32 +0200, Michael Fesser wrote:

>.oO(I V)

>>On Sun, 29 Jun 2008 08:35:25 -0400, Jerry Stuckle wrote:
- It sends passwords in clear text (although basic HTTP auth is little
better)
Wrong. (sftp)
You do know that the only thing SFTP has in common with FTP is the three
letter "FTP", right? They're completely separate protocols.

Depends. SFTP has different meanings. There is a protocol called SFTP,
but FTP through an SSH tunnel and FTP over SSL are also often called
SFTP (or FTPS in the latter case).

SSH-tunneled FTP is still FTP, and I wish people would quit trying to
label stuff that happens to be tunneled differently from the straight
protocol. It's not "w-FTP" because you happen to have an 802.11b hop in
the mix, is it? SSL-wrapped FTP is FTPS; it's only called SFTP by the
gormless.

Then there are a lot of gormless people in this world!

You're fighting a losing battle on this one.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Peter H. Coffin]

On Mon, 30 Jun 2008 20:31:16 -0400, Jerry Stuckle wrote:

Peter H. Coffin wrote:

>SSH-tunneled FTP is still FTP, and I wish people would quit trying to
label stuff that happens to be tunneled differently from the straight
protocol. It's not "w-FTP" because you happen to have an 802.11b hop in
the mix, is it? SSL-wrapped FTP is FTPS; it's only called SFTP by the
gormless.

Then there are a lot of gormless people in this world!

You're fighting a losing battle on this one.

I know, but I keep trying. It took *three days* to sort this out with a
vendor a year or two back.

--
"It's 106 light-years to Chicago, we've got a full chamber of anti-matter,
a half a pack of cigarettes, it's dark, and we're wearing visors."
"Engage."