| To: | gh@xxxxxxxxxx |
|---|---|
| Subject: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000 |
| From: | "David S. Miller" <davem@xxxxxxxxxx> |
| Date: | Fri, 06 Sep 2002 11:58:04 -0700 (PDT) |
| Cc: | Martin.Bligh@xxxxxxxxxx, hadi@xxxxxxxxxx, tcw@xxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, niv@xxxxxxxxxx |
| In-reply-to: | <E17nOIa-0003Xy-00@w-gerrit2> |
| References: | <20020906.113448.07697441.davem@redhat.com> <E17nOIa-0003Xy-00@w-gerrit2> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
From: Gerrit Huizenga <gh@xxxxxxxxxx> 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. |
| Previous by Date: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000, Gerrit Huizenga |
|---|---|
| Next by Date: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000, Gerrit Huizenga |
| Previous by Thread: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000, Gerrit Huizenga |
| Next by Thread: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000, Gerrit Huizenga |
| Indexes: | [Date] [Thread] [Top] [All Lists] |