yes I get a performance improvement of about 5%
could you port your patches to the 2.4.5-ac4 kernel? I'd love to see if the ac
improvements and yours add to each other.
Thanks,
- Fabio
Jens Axboe wrote:
> On Tue, May 29 2001, Fabio Riccardi wrote:
> > "Leeuw van d
yes I get a performance improvement of about 5%
could you port your patches to the 2.4.5-ac4 kernel? I'd love to see if the ac
improvements and yours add to each other.
Thanks,
- Fabio
Jens Axboe wrote:
On Tue, May 29 2001, Fabio Riccardi wrote:
Leeuw van der, Tim wrote
Ok, things are fast again now! :))
Performance is back to that of 2.4.2-ac26, and stability is a lot better. Under
heavy FS pressure 2.4.5-ac2 is about 5-10% faster than vanilla 2.4.5, the aa1,2
kernels have the same performance of vanilla 2.4.5.
Which one of your changes affected performance
a license for commercial
exploitation of the code (i.e. running a commercial web site).
Sorry for the inconvenience,
- Fabio
Fabio Riccardi wrote:
> Dear all,
>
> I finally managed to package the X15 web accelerator for the first
> source release.
>
> The current release incl
Same here, I have a dual 1GHz PIII with 4G, I don't get an oops but an infinite
loop of:
> mm: critical shortage of bounce buffers.
Indeed this message has been pestering me in all the recent .4-acx kernels when
the machine is under heavy FS pressure.
In these kernels I observe a
Same here, I have a dual 1GHz PIII with 4G, I don't get an oops but an infinite
loop of:
mm: critical shortage of bounce buffers.
Indeed this message has been pestering me in all the recent .4-acx kernels when
the machine is under heavy FS pressure.
In these kernels I observe a significative
for commercial
exploitation of the code (i.e. running a commercial web site).
Sorry for the inconvenience,
- Fabio
Fabio Riccardi wrote:
Dear all,
I finally managed to package the X15 web accelerator for the first
source release.
The current release includes a CGI module, an Apache
Ok, things are fast again now! :))
Performance is back to that of 2.4.2-ac26, and stability is a lot better. Under
heavy FS pressure 2.4.5-ac2 is about 5-10% faster than vanilla 2.4.5, the aa1,2
kernels have the same performance of vanilla 2.4.5.
Which one of your changes affected performance
Dear all,
I finally managed to package the X15 web accelerator for the first
source release.
The current release includes a CGI module, an Apache configuration
module and several salability improvements. It is a beta 1, quite stable
but it may/will still contain a few bugs. The README is a bit
Dear all,
I finally managed to package the X15 web accelerator for the first
source release.
The current release includes a CGI module, an Apache configuration
module and several salability improvements. It is a beta 1, quite stable
but it may/will still contain a few bugs. The README is a bit
Hello,
I have uploaded a new release of X15 that hopefully solves all the RFC bugs.
I say hopefully because I haven't had the opportunity to fully test the
request pipelining. Is there anything to automatize such tests?
>From what I could measure X15 is still a good 5% faster than TUX.
You can
Hello,
I have uploaded a new release of X15 that hopefully solves all the RFC bugs.
I say hopefully because I haven't had the opportunity to fully test the
request pipelining. Is there anything to automatize such tests?
From what I could measure X15 is still a good 5% faster than TUX.
You can
ok, I'm totally ignorant here, what is a pipelined request?
btw: please be kind with my mistakes, X15 _is_ alpha code anyway... :)
- Fabio
Ingo Molnar wrote:
> yet another anomaly i noticed. X15 does not appear to handle pipelined
> HTTP/1.1 requests properly, it ignores the second request
Ingo,
I'm really impressed by your feedback! How do you manage to discover so many
things?
I fixed the bug, and checked that it hadn't affected my specweb results.
Indeed specweb never issues closing 1.1 connections, it would use a 1.0
request with close in that case.
Moreover even if a
Ingo,
I'm really impressed by your feedback! How do you manage to discover so many
things?
I fixed the bug, and checked that it hadn't affected my specweb results.
Indeed specweb never issues closing 1.1 connections, it would use a 1.0
request with close in that case.
Moreover even if a
ok, I'm totally ignorant here, what is a pipelined request?
btw: please be kind with my mistakes, X15 _is_ alpha code anyway... :)
- Fabio
Ingo Molnar wrote:
yet another anomaly i noticed. X15 does not appear to handle pipelined
HTTP/1.1 requests properly, it ignores the second request if
his should make sure that you
don't exceed your system resources. The definition of old and the sweep
frequency are user configurable.
You can download the new version
from: http://www.chromium.com/X15-Alpha-3.tgz
- Fabio
Ingo Molnar wrote:
> On Tue, 1 May 2001, Fabio Riccardi wrote:
>
don't exceed your system resources. The definition of old and the sweep
frequency are user configurable.
You can download the new version
from: http://www.chromium.com/X15-Alpha-3.tgz
- Fabio
Ingo Molnar wrote:
On Tue, 1 May 2001, Fabio Riccardi wrote:
This is actually a bug in the current
Our intention is to release X15 with an open source license.
This will happen as soon as the codebase stabilizes a bit, that is when we go
beta (in two - three weeks).
At the moment we just don't have the time...
The reason why I released the alpha binary version is that several people
would
>From my experience system calls are not an issue.
What costs a lot is moving data around, since modern CPUs spend most of their
time in memory/bus wait cycles...
- Fabio
Linus Torvalds wrote:
> >I think that applies to all really high-performance servers.
>
> Note that it is definitely not
From my experience system calls are not an issue.
What costs a lot is moving data around, since modern CPUs spend most of their
time in memory/bus wait cycles...
- Fabio
Linus Torvalds wrote:
I think that applies to all really high-performance servers.
Note that it is definitely not
Our intention is to release X15 with an open source license.
This will happen as soon as the codebase stabilizes a bit, that is when we go
beta (in two - three weeks).
At the moment we just don't have the time...
The reason why I released the alpha binary version is that several people
would
This is actually a bug in the current X15, I know how to fix it (with
negligible overhead) but I've been lazy :)
give me a few days...
- Fabio
Ingo Molnar wrote:
> hm, another X15 caching artifact i noticed: i've changed the index.html
> file, and while X15 was still serving the old copy,
that
the date stamp was required to be really up-to-date.
- Fabio
dean gaudet wrote:
> On Sun, 29 Apr 2001, Fabio Riccardi wrote:
>
> > I can disable header caching and see what happens, I'll add an option
> > for this in the next X15 release.
>
> heh, well to be honest
that
the date stamp was required to be really up-to-date.
- Fabio
dean gaudet wrote:
On Sun, 29 Apr 2001, Fabio Riccardi wrote:
I can disable header caching and see what happens, I'll add an option
for this in the next X15 release.
heh, well to be honest, i'd put the (permanent) caching
I can disable header caching and see what happens, I'll add an option for this
in the next X15 release.
Nevertheless I don't know how much this is interesting in real life, since on
the internet most static pages are cached on proxies. I agree that the
RFC asks for a date for the original
e my request for help for testing X15 on higher end
server architectures.
X15 is still very young alpha code and I can surely improve its performance
in many ways.
- Fabio
Ingo Molnar wrote:
> On Fri, 27 Apr 2001, Fabio Riccardi wrote:
>
> > I'd like to announce the first release of X15
request for help for testing X15 on higher end
server architectures.
X15 is still very young alpha code and I can surely improve its performance
in many ways.
- Fabio
Ingo Molnar wrote:
On Fri, 27 Apr 2001, Fabio Riccardi wrote:
I'd like to announce the first release of X15 Alpha 1, a _user
I can disable header caching and see what happens, I'll add an option for this
in the next X15 release.
Nevertheless I don't know how much this is interesting in real life, since on
the internet most static pages are cached on proxies. I agree that the
RFC asks for a date for the original
In both cases (X15 and TUX) the CPU utilization is 100%
There are no IO bottlenecks on disk or on the net side.
I think that the major bottleneck is the speed of RAM and the PCI bus, wait
cycles.
We are basically going at the speed of the hardware.
- Fabio
"David S. Miller" wrote
Dear All,
I'd like to announce the first release of X15 Alpha 1, a _user space_
web server that is as fast as TUX.
On my Dell 4400 with 2G of RAM and 2 933MHz PIII and NetGear 2Gbit NICs
I achieve about 2500 SpecWeb99 connections, with both X15 and
TUX (actually X15 is sligtly faster, some 20
In both cases (X15 and TUX) the CPU utilization is 100%
There are no IO bottlenecks on disk or on the net side.
I think that the major bottleneck is the speed of RAM and the PCI bus, wait
cycles.
We are basically going at the speed of the hardware.
- Fabio
David S. Miller wrote:
Fabio
Ingo Molnar wrote:
> > On a Dell PowerEdge 1550/1000 the published TUX 2 result is 2765.
> >
> > If you take into account the fact that the 1550 has a faster processor
> > (1GHz) and a more modern bus architecture (Serverworks HE with memory
> > interleaving and a triple PCI bus), the
Alan,
SPEC connections are cumulative of static (70%) and dynamic (30%) pages, with the
dynamic using quite a bit of CPU (25%-30%) and the static pages dataset of several
(6-8) gigabytes.
The chromium server is actually much faster than thttpd and it is a complete web
server.
- Fabio
Alan
:
> On Fri, 23 Mar 2001, Fabio Riccardi wrote:
>
> > I'm building an alternative web server that is entirely in _user
> > space_ and that achieves the same level of performance as TUX.
> > Presently I can match TUX performance within 10-20%, and I still have
> > quite a
Ingo Molnar wrote:
On a Dell PowerEdge 1550/1000 the published TUX 2 result is 2765.
If you take into account the fact that the 1550 has a faster processor
(1GHz) and a more modern bus architecture (Serverworks HE with memory
interleaving and a triple PCI bus), the performance is
Alan,
SPEC connections are cumulative of static (70%) and dynamic (30%) pages, with the
dynamic using quite a bit of CPU (25%-30%) and the static pages dataset of several
(6-8) gigabytes.
The chromium server is actually much faster than thttpd and it is a complete web
server.
- Fabio
Alan
:
On Fri, 23 Mar 2001, Fabio Riccardi wrote:
I'm building an alternative web server that is entirely in _user
space_ and that achieves the same level of performance as TUX.
Presently I can match TUX performance within 10-20%, and I still have
quite a few improvements in my pocket.
very
with a cost, is it worth it?
Could you make a port of your thing on recent kernels?
I tried and I failed and I don't have enough time to figure out why, that should be
trivial for you though.
TIA, ciao,
- Fabio
Mike Kravetz wrote:
> On Tue, Apr 03, 2001 at 05:18:03PM -0700, Fabio Riccardi wr
Alan Cox wrote:
> > for the "normal case" performance see my other message.
>
> I did - and with a lot of interest
thanks! :)
> > I agree that a better threading model would surely help in a web server, but to
> > me this is not an excuse to live up with a broken scheduler.
>
> The problem has
Alan,
for the "normal case" performance see my other message.
I agree that a better threading model would surely help in a web server, but to
me this is not an excuse to live up with a broken scheduler.
The X15 server I'm working on now is a sort of user-space TUX, it uses only 8
threads per
Dear all,
I've spent my afternoon running some benchmarks to see if MQ patches would
degrade performance in the "normal case".
To measure performance I've used the latest lmbench and I have mesured the
kernel compile times on a dual pentium III box runing at 1GHz with an 133MHz
bus.
Results
Dear all,
I've spent my afternoon running some benchmarks to see if MQ patches would
degrade performance in the "normal case".
To measure performance I've used the latest lmbench and I have mesured the
kernel compile times on a dual pentium III box runing at 1GHz with an 133MHz
bus.
Results
Alan,
for the "normal case" performance see my other message.
I agree that a better threading model would surely help in a web server, but to
me this is not an excuse to live up with a broken scheduler.
The X15 server I'm working on now is a sort of user-space TUX, it uses only 8
threads per
Alan Cox wrote:
for the "normal case" performance see my other message.
I did - and with a lot of interest
thanks! :)
I agree that a better threading model would surely help in a web server, but to
me this is not an excuse to live up with a broken scheduler.
The problem has always
with a cost, is it worth it?
Could you make a port of your thing on recent kernels?
I tried and I failed and I don't have enough time to figure out why, that should be
trivial for you though.
TIA, ciao,
- Fabio
Mike Kravetz wrote:
On Tue, Apr 03, 2001 at 05:18:03PM -0700, Fabio Riccardi wrote:
I
Hello,
I sent a message a few days ago about some limitations I found in the
linux scheduler.
In servers like Apache where a large (> 1000) number of processes can be
running at the same time and where many of them are runnable at the same
time, the default Linux scheduler just starts trashing
Hello,
I sent a message a few days ago about some limitations I found in the
linux scheduler.
In servers like Apache where a large ( 1000) number of processes can be
running at the same time and where many of them are runnable at the same
time, the default Linux scheduler just starts trashing
web server?
BTW2: what about the HP scheduler patches?
Thanks, ciao,
- Fabio
Mike Kravetz wrote:
> On Thu, Mar 29, 2001 at 01:55:11PM -0800, Fabio Riccardi wrote:
> > I'm using 2.4.2-ac26, but I've noticed the same behavior with all the 2.4
> > kernels I've seen so far.
> &g
"J . A . Magallon" wrote:
> It all depends on your app, as every parallel algorithm. In a web-ftp-whatever
> server, you do not need any synchro. You can start threads in free run and
> let them die alone.
even if you don't need synchronization you pay for it anyway, since you will have
to use
(p)threads woud
help in any way, unless it is the VM context switch overhead that is playing a
role here, which I wouldn't think is the case.
- Fabio
"J . A . Magallon" wrote:
> On 03.29 Fabio Riccardi wrote:
> >
> > I've found a (to me) unexplicable system behaviour w
; On Thu, 29 Mar 2001, Fabio Riccardi wrote:
>
> > Date: Thu, 29 Mar 2001 13:19:05 -0800
> > From: Fabio Riccardi <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: linux scheduler limitations?
> >
> > Hello,
> >
> > I'm working on
Hello,
I'm working on an enhanced version of Apache and I'm hitting my head
against something I don't understand.
I've found a (to me) unexplicable system behaviour when the number of
Apache forked instances goes somewhere beyond 1050, the machine
suddently slows down almost top a halt and
Hello,
I'm working on an enhanced version of Apache and I'm hitting my head
against something I don't understand.
I've found a (to me) unexplicable system behaviour when the number of
Apache forked instances goes somewhere beyond 1050, the machine
suddently slows down almost top a halt and
Riccardi wrote:
Date: Thu, 29 Mar 2001 13:19:05 -0800
From: Fabio Riccardi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: linux scheduler limitations?
Hello,
I'm working on an enhanced version of Apache and I'm hitting my head
against something I don't understand.
I've
(p)threads woud
help in any way, unless it is the VM context switch overhead that is playing a
role here, which I wouldn't think is the case.
- Fabio
"J . A . Magallon" wrote:
On 03.29 Fabio Riccardi wrote:
I've found a (to me) unexplicable system behaviour when the number of
"J . A . Magallon" wrote:
It all depends on your app, as every parallel algorithm. In a web-ftp-whatever
server, you do not need any synchro. You can start threads in free run and
let them die alone.
even if you don't need synchronization you pay for it anyway, since you will have
to use the
web server?
BTW2: what about the HP scheduler patches?
Thanks, ciao,
- Fabio
Mike Kravetz wrote:
On Thu, Mar 29, 2001 at 01:55:11PM -0800, Fabio Riccardi wrote:
I'm using 2.4.2-ac26, but I've noticed the same behavior with all the 2.4
kernels I've seen so far.
I haven't even tried
Dave, Zach,
thanks for your help, I've implemented a file descriptor passing mechanism
very similar to that of Zach's and it worked.
The problem now is performance, fd passing is utterly slow!
On my system (a 1GHz Pentium III + 2G RAM) I can do 1300 SpecWeb99 with a
khttp-like socket passing
Dave, Zach,
thanks for your help, I've implemented a file descriptor passing mechanism
very similar to that of Zach's and it worked.
The problem now is performance, fd passing is utterly slow!
On my system (a 1GHz Pentium III + 2G RAM) I can do 1300 SpecWeb99 with a
khttp-like socket passing
Fantastic!
I was not aware of it, sorry... where can I find some doc?
- Fabio
"David S. Miller" wrote:
> Fabio Riccardi writes:
> > How can Apache "grab" the file descriptor?
> >
> > My understanding is that file descriptors are data structures pr
How can Apache "grab" the file descriptor?
My understanding is that file descriptors are data structures private to
a process...
Am I missing something?
- Fabio
"David S. Miller" wrote:
> Fabio Riccardi writes:
> > How could this be fixed?
>
> Why not
Hi,
I've been working for a while on a user-space web server accelerator (as
opposed to a kernel space accelerator, like TUX). So far I've had very
promising results and I can achieve performance (spec) figures
comparable to those of TUX.
Although my implementation is entirely sitting in user
Hi,
I've been working for a while on a user-space web server accelerator (as
opposed to a kernel space accelerator, like TUX). So far I've had very
promising results and I can achieve performance (spec) figures
comparable to those of TUX.
Although my implementation is entirely sitting in user
64 matches
Mail list logo
