Time |
S |
Nick |
Message |
20:00 |
|
thd |
kados: are you present? |
20:02 |
|
kados |
thd: yep |
20:07 |
|
thd |
kados: the page generation time is a function of network speed. Why is that? |
20:08 |
|
kados |
e? |
20:09 |
|
thd |
kados: on my dial-up connection I have circa 54 seconds while less than 1 second locally |
20:11 |
|
thd |
locally meaning either another local copy of the same script or a text based browser on the remote system |
20:12 |
|
thd |
kados: but should a page generation time not be how long it took the script to generate the code for the page irrespective of the data transmission time? |
20:13 |
|
thd |
kados: the value is generated from a simple difference taken in Unix epoch seconds between the start and end of the script |
20:14 |
|
chris |
the script doesnt stop until its delivered its content |
20:14 |
|
chris |
think of it this way |
20:14 |
|
chris |
does a script that prints to a file run faster than one that prints to a console |
20:15 |
|
chris |
the answer is usually yes |
20:16 |
|
chris |
its the way i/o works, you cant push out output faster than the device receiving can handle |
20:17 |
|
thd |
chris: so any script that generates a web page waits constantly for a data receipt acknowledgement? |
20:17 |
|
chris |
the script itself doesnt, apache does |
20:18 |
|
chris |
which in turn tells the script |
20:18 |
|
thd |
chris: so Apache is executing the code for the application language? |
20:18 |
|
chris |
its just like writing to a disk |
20:18 |
|
chris |
the i/o handler has to tell the program give me more datat |
20:18 |
|
chris |
-t |
20:19 |
|
thd |
chris: I can see the similarity to writing to file but it was counter intuitive |
20:19 |
|
chris |
how? |
20:20 |
|
thd |
chris: I had simple expected the time it took to generate a page was a function of the time it took to execute the code for the page on the local system independent of where the data was being sent |
20:20 |
|
chris |
its just the same as running a file that writes to a file locally |
20:21 |
|
chris |
vs the same script that writes to a file over a network |
20:21 |
|
chris |
thd: that depends entirely on how you write your script and wear you do the timing |
20:22 |
|
chris |
ie, if you generate all the data, then stop the timer, then print it |
20:22 |
|
chris |
it should be the same irrespective of where you are printing it to |
20:22 |
|
chris |
if you time the print .. then thats dependent entirely on where its printing to |
20:22 |
|
chris |
make sense? |
20:22 |
|
chris |
wear=where of course :) |
20:23 |
|
thd |
chris:ok, that makes sense |
20:24 |
|
thd |
chris: yet writing out data as it is generated is perhaps the most common behaviour for web applications |
20:25 |
|
chris |
yep |
20:26 |
|
thd |
chris: however, if my connection is slow then I could have a timeout because I exceeded the maximum script wait time at some point |
20:26 |
|
chris |
yep, but that would probably happen either way |
20:26 |
|
chris |
whether its all generated then printed, or printed as generated |
20:27 |
|
thd |
chris:you mean Apache would time me out if I was receiving to slowly? |
20:27 |
|
chris |
eventually yes |
20:27 |
|
chris |
actually ur browser probably would |
20:27 |
|
chris |
before apache did |
20:28 |
|
chris |
but apache does clean up unfinished scripts |
20:28 |
|
chris |
otherwise you end up with a dead apache pretty fast |
20:32 |
|
chris |
ok, i have to go do some grocery shopping, back in a bit |
20:37 |
|
thd |
kados: are you still there? |
00:23 |
|
thd |
chris: have you fetched your groceries? |
00:24 |
|
thd |
chris: I have another related question |