i would like to be an http server for static content only. Due to this
requirement, the server should be really simple to code. But another
requirement is that i would like to best possible performance. I would like
to have minimal context switches and have a single process serving as many
connections as possible, i feel like going for kqueue.
On a single processor system, no secret. But on a SMP system the history is
different. I would like to have a http process per core. The question is
which decision to make:
0) To have a single process "accepting" incoming connection on port 80 and
send the new socket fd to one of the http server in a round-roubin manner,
or
1) Have a httpd server started. Have it performed socket, bind, listen.
Then it forks n-1 childs and after forking the child, everyprocess (parent
and childs) do "accept" on the socket fd listening for incoming
connections. The concern here is about the kernel awaking up policy in
terms of performance, i.e., awaking up more than one process when a new
connection is ready to be accept (only one process will have it and the
other will be put to sleep again).
The first approach leads to n+1 process. The second to exactly n process.
The code (only relevant part) for the second approach would be something
like:
sd = socket;
bind(sd ...);
listen;
while (n) {
p = fork();
if (!p) break; /* we are a child */
if (p == -1) break; /* we are the parent, error */
}
nc = accept(sd ...);
What you have to say ?
Thanks a lot for your time and cooperation.
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
On Tue, Nov 13, 2012 at 8:26 AM, Mark Blackman <m...@exonetric.com> wrote:
> On 13 Nov 2012, at 10:23, Friedrich Locke <friedrich.lo...@gmail.com>
> wrote:
> > Hi list members,
> > i would like to be an http server for static content only. Due to this
> [snip]
> > What you have to say
> benchmark nginx to see if it does the job already.
Friedrich Locke <friedrich.lo...@gmail.com> wrote:
> 0) To have a single process "accepting" incoming connection on port
> 80 and send the new socket fd to one of the http server in a
> round-roubin manner, or
if you have N cores, create N - X processes or threads for handling the
requests. Leave at least one core for the OS, so, have X >= 2.
I would not fork at all. Have the threads ready when the requests are
coming.
At least this is what I did several years ago achieving the highest
performance. Make X a variable to be able to tune a bit.
You also should have a memory pool available to avoid calls to malloc
and free. You must have a limit for the memory pool. Free the memory in
the pool time to time so others can make use of the memory too.
> The first approach leads to n+1 process. The second to exactly n
> process.
You need at least one core for handling the tasks of the OS. If I
remember right, I took 10% of the cores plus one which I did not use
and I took at least one core.
This is all from memory. So, please consider that I could have missed
something out.
Define "high performance" , what are your expectations in terms of concurrent connections, requests/second and all ?
Allow me to shed some measure of light here, we're running 16x web servers with nginx doing *permanent* (as in, for all requests) URL rewriting and serving 500 req/s each.
These servers admittedly running debian are behind 4x freebsd boxes using a combination of PF, CARP and relayd on 8.3-STABLE.
The web servers deliver 200mb/second worth of *small* files (roughly 1kb javascripts).
They hardly ever reach 0.25 load average, on 8 cores + hyperthreading.
What I'm getting at here is, nginx *totally rapes* performance-wise, at least for our own needs.
If it is able to deliver 500 req/s (for each server) of small files, surely it can handle the load you're planning on throwing at it ?
On Nov 13, 2012, at 11:28 AM, Friedrich Locke <friedrich.lo...@gmail.com> wrote:
when i say high performance, i am looking something at least as fast as the
fastest performing http server on the market for a given set of requests on
the same pool of static files.
I am aware og ngnix, but i have to write my own http server. Using someone
else solution is not an option.
On Tue, Nov 13, 2012 at 8:57 AM, Fleuriot Damien <m...@my.gd> wrote:
> Define "high performance" , what are your expectations in terms of
> concurrent connections, requests/second and all ?
> Allow me to shed some measure of light here, we're running 16x web servers
> with nginx doing *permanent* (as in, for all requests) URL rewriting and
> serving 500 req/s each.
> These servers admittedly running debian are behind 4x freebsd boxes using
> a combination of PF, CARP and relayd on 8.3-STABLE.
> The web servers deliver 200mb/second worth of *small* files (roughly 1kb
> javascripts).
> They hardly ever reach 0.25 load average, on 8 cores + hyperthreading.
> What I'm getting at here is, nginx *totally rapes* performance-wise, at
> least for our own needs.
> If it is able to deliver 500 req/s (for each server) of small files,
> surely it can handle the load you're planning on throwing at it ?
> On Nov 13, 2012, at 11:28 AM, Friedrich Locke <friedrich.lo...@gmail.com>
> wrote:
> > Thank you Mark for suggestion, but my doubt still remains.
> > Regards.
> > On Tue, Nov 13, 2012 at 8:26 AM, Mark Blackman <m...@exonetric.com>
> wrote:
> >> On 13 Nov 2012, at 10:23, Friedrich Locke <friedrich.lo...@gmail.com>
> >> wrote:
> >>> Hi list members,
> >>> i would like to be an http server for static content only. Due to this
> >> [snip]
> >>> What you have to say
> >> benchmark nginx to see if it does the job already.
On 13 Nov 2012, at 11:03, Friedrich Locke <friedrich.lo...@gmail.com> wrote:
> Mark,
> when i say high performance, i am looking something at least as fast as the fastest performing http server on the market for a given set of requests on the same pool of static files.
> I am aware og ngnix, but i have to write my own http server. Using someone else solution is not an option.
Ok, fair enough. It's a shame you're not in a position to use proven high performance technology to minimise
your time-to-market, but I'll assume you've got a good reason to re-invent the wheel.
I think for design questions like that, freebsd-questions@ is not the ideal list, but I suggest
either freebsd-hackers@ or freebsd-net@ or a more general purpose networking list.
That's a shame, nginx is definitely a robust and fast server, it's
well maintained, it's patched quickly...
If you need proof of its prowess to convince your upstream managers,
I'd be inclined to provide you with a diagram of our architecture for
this particular project, as well as the graphs (network traffic,
server loads, requests/sec...)
On 13 November 2012 12:03, Friedrich Locke <friedrich.lo...@gmail.com> wrote:
> when i say high performance, i am looking something at least as fast as the
> fastest performing http server on the market for a given set of requests on
> the same pool of static files.
> I am aware og ngnix, but i have to write my own http server. Using someone
> else solution is not an option.
> On Tue, Nov 13, 2012 at 8:57 AM, Fleuriot Damien <m...@my.gd> wrote:
>> Define "high performance" , what are your expectations in terms of
>> concurrent connections, requests/second and all ?
>> Allow me to shed some measure of light here, we're running 16x web servers
>> with nginx doing *permanent* (as in, for all requests) URL rewriting and
>> serving 500 req/s each.
>> These servers admittedly running debian are behind 4x freebsd boxes using
>> a combination of PF, CARP and relayd on 8.3-STABLE.
>> The web servers deliver 200mb/second worth of *small* files (roughly 1kb
>> javascripts).
>> They hardly ever reach 0.25 load average, on 8 cores + hyperthreading.
>> What I'm getting at here is, nginx *totally rapes* performance-wise, at
>> least for our own needs.
>> If it is able to deliver 500 req/s (for each server) of small files,
>> surely it can handle the load you're planning on throwing at it ?
>> On Nov 13, 2012, at 11:28 AM, Friedrich Locke <friedrich.lo...@gmail.com>
>> wrote:
>> > Thank you Mark for suggestion, but my doubt still remains.
>> > Regards.
>> > On Tue, Nov 13, 2012 at 8:26 AM, Mark Blackman <m...@exonetric.com>
>> > wrote:
>> >> On 13 Nov 2012, at 10:23, Friedrich Locke <friedrich.lo...@gmail.com>
>> >> wrote:
>> >>> Hi list members,
>> >>> i would like to be an http server for static content only. Due to this
>> >> [snip]
>> >>> What you have to say
>> >> benchmark nginx to see if it does the job already.
On Tue, Nov 13, 2012 at 3:08 AM, Mark Blackman <m...@exonetric.com> wrote:
> On 13 Nov 2012, at 11:03, Friedrich Locke <friedrich.lo...@gmail.com>
> wrote:
> > Mark,
> > when i say high performance, i am looking something at least as fast as
> the fastest performing http server on the market for a given set of
> requests on the same pool of static files.
> > I am aware og ngnix, but i have to write my own http server. Using
> someone else solution is not an option.
> Ok, fair enough. It's a shame you're not in a position to use proven high
> performance technology to minimise
> your time-to-market, but I'll assume you've got a good reason to re-invent
> the wheel.
> I think for design questions like that, freebsd-questions@ is not the
> ideal list, but I suggest
> either freebsd-hackers@ or freebsd-net@ or a more general purpose
> networking list.
If there is NO any absolute requirement to write a new http server in a
clean room approach ,
any existing related software with suitable license may be utilized to
generate a new fork and
make necessary additions with possible translation to another programming
language .
Please do NOT take the following sentences against your personality ,
they are only to remind you about problems :
If you are not able to fork an existing http server software in your
programming language ( the programming language you want to use ) and
modify it with respect to your special needs , then it is very likely that
you will not be able to write an equivalent software .
If you attempt to create such a software , with the above condition , at
the end ,
your gain will be amount of knowledge you gained , amount of time and
resources ( money , time , etc. ) you lost .
If you will use a different programming language and you do not know the
programming languages used by suitable licensed http server software , then
study development history of such http server software and get information
about its difficulty , problems , cost , human effort requirements , etc. ,
.
This will supply to you a clear road map for you development .
> >>>>> "Friedrich" == Friedrich Locke <friedrich.lo...@gmail.com> writes:
> Friedrich> I am aware og ngnix, but i have to write my own http
> Friedrich> server. Using someone else solution is not an option.
> As this is a very unusual requirement (given that nginx is available
> under the most free license available), I think you owe us a better
> explanation.
On Tue, Nov 13, 2012 at 08:23:38AM -0200, Friedrich Locke wrote:
> 0) To have a single process "accepting" incoming connection on port 80 and
> send the new socket fd to one of the http server in a round-roubin manner,
You could spend all day wondering. But if you really want to
know and not just argue, you should do as the author of that web
server says: "Profile. Don't speculate."
It may just be that context switches are not the real bottleneck
in your service.
_______________________________________________
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
