Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jul 2008 08:05:32 +0200
From:      Alexander Leidinger <Alexander@Leidinger.net>
To:        Rahul <rahulone@gmail.com>
Cc:        freebsd-performance@freebsd.org, Julian Elischer <julian@elischer.org>
Subject:   Re: Real Insight on Performance
Message-ID:  <20080716080532.18862vjyr477xls0@webmail.leidinger.net>
In-Reply-To: <4804a6670807151717r54f2889fq6c9c70afebee413d@mail.gmail.com>
References:  <4804a6670807151328y2cf30363x9b808912286ea1f5@mail.gmail.com> <487D1069.3030801@elischer.org> <4804a6670807151717r54f2889fq6c9c70afebee413d@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Rahul <rahulone@gmail.com> (from Tue, 15 Jul 2008 20:17:46 -0400):

> For example: I would like to run a high performance web server that
> can handle up to 200 connections per second and serve them with great
> speed. That's where the concern for multi-threaded support. Depending

Serving 200 connections per second for static data is not hard. And =20
you don't need multi-threading for that. Multiple processes is =20
actually better than multi-threading in this regard, as you don't have =20
to do locking of filedescriptors in the the webserver over multiple =20
threads. The difference between linux and FreeBSD should be not big =20
for single CPU/core systems, but if you increase the number of =20
CPUs/cores this may be different. See the postgresql (it uses =20
processes, not threads like mysql) graphs in =20
http://people.freebsd.org/~kris/scaling/7.0%20and%20beyond.pdf to get =20
an idea about the scaling of more or less independent processes in =20
FreeBSD.

> on the request, I may have to load (and possibly unload) dynamic
> modules to perform calculations, and if need be, fetch data from
> either DB or flat file. It could involve connecting to a process on

As soon as you have calculations and/or DB accesses involved, it =20
mostly depends upon the DB optimizations ("good" tables, indexes, data =20
volume, queries, good concurrency of the DB, ...) and the computation, =20
not on the OS. So without any specific workload, we can not really =20
give recommendations (besides giving FreeBSD a try and working with us =20
if there's problem).

> another box to get request specific command strings. This process
> could run for almost 20 hours straight and OS still has to be able to
> keep in shape.

The OS doesn't care about how long a process runs. But if you talk =20
about good responsiveness of the OS while a process uses a lot of =20
memory and CPU, FreeBSD will handle it good (and from what I heard and =20
seen better than Linux, but I don't have numbers at hand).

Bye,
Alexander.

--=20
  Leela: Well, someone's in a good mode.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID =3D 72077137



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080716080532.18862vjyr477xls0>