John Proctor <firstname.lastname@example.org> wrote:
| Edi Weitz <email@example.com> wrote in message
| > The whole point of my article was that all this doesn't matter
| > as long as you are sending 12 MB of data to a web browser.
| That is not true at all. For a web based enterprise app a user can
| move 12 MB in a few hours easily. Now imagine 200 concurrent users
| doing that on that webserver...
Sheesh! You're consistently missing Edi's rather obvious point!!
As long as your web based enterprise app can saturate your Internet
connection using *anything* less than 100% of the CPU, it doesn't
*matter* how many users you pile on it -- they're all going to
bottleneck on the outgoing network pipe, leaving some of the CPU
"Good enough" means being able to fill whatever speed pipe you can
afford, and once you can do that, well, then it's good enough.
It only takes a modest amount of tuning to saturate, say, a 10 Mb/s pipe.
Running Edi's last version on my Athlon 1600+ (1.4GHz), it wrote a
13.6 MB file in 1.27 seconds of real time (1.19 sec. CPU time).
That's over 10 MB/s -- over 85 Mb/s! -- with is a lot more Internet
bandwidth than I'll ever see.
p.s. My current web server chugs along very happily with only
768 kb/s (SDSL), which is why (for example) I don't really worry
about the performance differences between HTOUT & CL-WHO [see
the recent "html generation API" thread].
Rob Warnock, PP-ASEL-IA <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607