I have a script that fetches information from a hundred website. It
takes a long time because each website takes a second for the server
to respond. Based on suggestions in this newsgroup I have speeded it
up. But why do servers take one second to spit back a small 3 kilobyte
text file. Why isn't it instant? How does voice over IP overcome this
'delay' problem?
Duke of Hazard
> I have a script that fetches information from a hundred website. It
> takes a long time because each website takes a second for the server
> to respond. Based on suggestions in this newsgroup I have speeded it
> up. But why do servers take one second to spit back a small 3 kilobyte
> text file. Why isn't it instant? How does voice over IP overcome this
> 'delay' problem?
Good question.
Since you are posting this to a PHP group, I assume this is some sort
of web based thing and there are lots of things that can slow down a
remote retrieve.
Personally, I would start with network analysis to see how much time
it takes to send the request and how long it takes for a response to
come back and go from there depending on what is seen.`
--
Jim Pennino
Remove .spam.sux to reply.
Duke of Hazard schreef:
> I have a script that fetches information from a hundred website. It
> takes a long time because each website takes a second for the server
> to respond. Based on suggestions in this newsgroup I have speeded it
> up. But why do servers take one second to spit back a small 3 kilobyte
> text file. Why isn't it instant? How does voice over IP overcome this
> 'delay' problem?
Hi,
If you requests the webpages in parallel, and not sequential, your
script will be a lot faster (but needs a lot more memory.).
About the delay: If you fetch a 3K file from a webserver in a far-away
location (networkwise), it takes time to deliver the message.
Like Jim suggested: You need network analisis tools to see why. But even
if you do know why, I think there is little you can do to overcome that
problem.
Other reasons might simply be a slow server, a busy server, etc..
(Why VOIP is fast? I don't know. Maybe it uses UDP instead of TCP/IP.)
Regards,
Erwin Moller
jimp@specsol.spam.sux.com wrote:
> Duke of Hazard
>> I have a script that fetches information from a hundred website. It
>> takes a long time because each website takes a second for the server
>> to respond. Based on suggestions in this newsgroup I have speeded it
>> up. But why do servers take one second to spit back a small 3 kilobyte
>> text file. Why isn't it instant? How does voice over IP overcome this
>> 'delay' problem?
>
> Good question.
>
> Since you are posting this to a PHP group, I assume this is some sort
> of web based thing and there are lots of things that can slow down a
> remote retrieve.
>
> Personally, I would start with network analysis to see how much time
> it takes to send the request and how long it takes for a response to
> come back and go from there depending on what is seen.`
>
Having a small delay in responding ios a good way to prevent DOS attacks.
I.e. rapid and repeated downloads of the same thing, won't result in a
saturated server.
..
Hi,
Erwin Moller wrote:
> > How does voice over IP overcome this 'delay' problem?
> [...]
> (Why VOIP is fast? I don't know. Maybe it uses UDP instead of TCP/IP.)
It certainly does (all VOIP protocols I know of, most of them using RTP
for speech transport -- note that signalling is a different matter!).
That alone saves you an SYN/ACK roundtrip compared to TCP. But that's
not all. It also usually sets the QOS bits on the IP packets to
"throughput". Depends on the routing infrastructure if this information
is used, respected or just kept. Also, we talk about (two)
unidirectional channels which are allowed to have some loss. Not even
remotely comparable.
Parallel fetching would indeed be the solution for the problem in
question here. It even doesn't necessarily mean a CPU or memory
overhead when looking at the relative resource consumption over time...
-hwh
On Apr 2, 10:05 pm, Duke of Hazard
> I have a script that fetches information from a hundred websites. It
> takes a long time because each website takes a second for the server
> to respond. Based on suggestions in this newsgroup I have speeded it
> up. But why do servers take one second to spit back a small 3 kilobyte
> text file. Why isn't it instant?
Not only is the server a mechanical device (=slowness) with a limited
bandwidth (more delays) but every router between you and each of the
servers you query adds additional layers of slowness.
On 3 Apr, 10:06, The Natural Philosopher
> j...@specsol.spam.sux.com wrote:
> > Duke of Hazard
> >> I have a script that fetches information from a hundred website. It
> >> takes a long time because each website takes a second for the server
> >> to respond. Based on suggestions in this newsgroup I have speeded it
> >> up. But why do servers take one second to spit back a small 3 kilobyte
> >> text file. Why isn't it instant? How does voice over IP overcome this
> >> 'delay' problem?
>
> > Good question.
>
> > Since you are posting this to a PHP group, I assume this is some sort
> > of web based thing and there are lots of things that can slow down a
> > remote retrieve.
>
> > Personally, I would start with network analysis to see how much time
> > it takes to send the request and how long it takes for a response to
> > come back and go from there depending on what is seen.`
>
> Having a small delay in responding ios a good way to prevent DOS attacks.
>
> I.e. rapid and repeated downloads of the same thing, won't result in a
> saturated server.
> .
No it isn't.
As soon as the request lands on your server, you've opened up a port
and spawned a new process or thread requiring memory and scheduling.
Using tarpitting to avoid DOS nearly always backfires - you're just
giving the blackhat the meas to carry out a DOS. The quicker you free
up resources for the next request, the better. It is a valid way to
prevent leeching though as the OP has found out.
> Why isn't it instant?
Certainly 3 seconds seems excessive. But the OPs framing of his
question indicates that he's going to have trouble finding out /
understanding the answers.
> How does voice over IP overcome this 'delay' problem?
1) do you have a VOIP connection to these same IP addresses? Probably
not.
2) because although it's still packet based routing, the session setup
overhead is done only once per call
3) because it uses UDP mostly rather than TCP - and stream reassembly
can cope with dropped / out of sequence packets
4) because the input data stream is not normally a bottleneck
5) because the end points in a VOIP session are usually only trying to
handle one request at a time
C.