Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000

2 messages, 2 authors, 2002-09-06 · open the first message on its own page

Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000

From: Gerrit Huizenga <hidden>
Date: 2002-09-06 18:53:50

In message [off-list ref], > : "David S. Miller" w
rites:
   From: Gerrit Huizenga [off-list ref]
   Date: Fri, 06 Sep 2002 11:19:11 -0700

TUX can optimize dynamic content just fine.

   The last I knew was that it could pass it off to another server.
Out of curiosity, and primarily for my own edification, what kind
of optimization does it do when everything is generated by a java/
perl/python/homebrew script and pasted together by something which
consults a content manager.  In a few of the cases that I know of,
there isn't really any static content to cache...  And why is this
something that Apache couldn't/shouldn't be doing?

gerrit

Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000

From: David S. Miller <hidden>
Date: 2002-09-06 19:00:42

   From: Gerrit Huizenga [off-list ref]
   Date: Fri, 06 Sep 2002 11:57:39 -0700

   Out of curiosity, and primarily for my own edification, what kind
   of optimization does it do when everything is generated by a java/
   perl/python/homebrew script and pasted together by something which
   consults a content manager.  In a few of the cases that I know of,
   there isn't really any static content to cache...  And why is this
   something that Apache couldn't/shouldn't be doing?

The kernel exec's the CGI process from the TUX server and pipes the
output directly into a networking socket.

Because it is cheaper to create a new fresh user thread from within
the kernel (ie. we don't have to fork() apache and thus dup it's
address space), it is faster.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help