http server

I copy from a book a simple server with sockets using forking with linux 2.4
I read (not understood all, but must thank very much Mister Tannenbaum) a
book about os design
and I discover that threads exists for linux too.
I read about 2.6 kernels the wonderful kernel 2.6, thanks to an answer here
..

My question are :

- Are threads much more efficient than process with copy on demand like
linux does
in server like program?
Are threads only a easier way for programmers, or some marketing discovery?

- Wonderful Kernel 2.6 documentation says that this kernel has some changes
made for tcp/ip and that it is big improvement for apache, and this is
reason why khttp is not needed anymore. What kind of improvement are they
talking of ?

- Is there any sort of improvement in putting many ethernet nic on the pci
bus ?

BR.

RosalieM wrote:
> - Are threads much more efficient than process with copy on demand like
> linux does
> in server like program?
> Are threads only a easier way for programmers, or some marketing discovery?

I don't know the specifics but untill you get a better reply, this might
put you in hte right direction.

A proces is just about the same as starting a completley new program
with all what that means in memory overhead etc.

One process can have many internal threads wo share the same memory area.

That is just a simple and probably in many ways wrong explanation but
depending on how much you know before it might help a little.

Tim

In comp.os.linux.networking RosalieM <(E-Mail Removed)> wrote:

> Are threads only a easier way for programmers, or some marketing
> discovery?

Threads can offer better performance depending on what your server
program is doing. Its preferable to use threads in the following
scenarios

* You need to share a lot of data between server children. You can't
easily do this in a forked architecture.

* The duration of the "connection" (TCP or UDP) is very short compared
to the time taken to fork a new process. But you can have pre-forked
servers which can lessen the need for threads.

All in all, it's generally better not to use threads if you can avoid
it, as you open yourself up to a lot of locking issues which complicate
your code and make it harder to debug.

> - Wonderful Kernel 2.6 documentation says that this kernel has some
> changes made for tcp/ip and that it is big improvement for apache, and
> this is reason why khttp is not needed anymore.

That and nobody liked/used it, IIRC.

Can you tell us in which file you got this information? Are you talking
about pthreads or that new thread system that RedHat introduced in RH9
(nptl or some such).

> - Is there any sort of improvement in putting many ethernet nic on the
> pci bus ?

No, as they are all sharing the bandwidth of the PCI bus. But this is
more of a concern when you use Gigabit ethernet.

--
Cameron Kerr
(E-Mail Removed) : http://nzgeeks.org/cameron/
Empowered by Perl!

"Cameron Kerr" <(E-Mail Removed)> a écrit dans le message de
news:(E-Mail Removed)...
> In comp.os.linux.networking RosalieM <(E-Mail Removed)> wrote:
....
> Threads can offer better performance depending on what your server
> program is doing. Its preferable to use threads in the following
> scenarios
>
> * You need to share a lot of data between server children. You can't
> easily do this in a forked architecture.

If i get mmap memory or a shm file and put my data into it. All my processes
will share this data, i mean for reading or i must lock for writing, and
each new process knows that memory from his parent ?

> * The duration of the "connection" (TCP or UDP) is very short compared
> to the time taken to fork a new process. But you can have pre-forked
> servers which can lessen the need for threads.

How can i have a idea of what is done and time needed to switch to a new
thread, and compare with a new process made by forking and an old process
that became eligible ? What what is the impact of linux strategy copy on
demand for processes in this case?

> All in all, it's generally better not to use threads if you can avoid
> it, as you open yourself up to a lot of locking issues which complicate
> your code and make it harder to debug.
>

Thanks for this advices about threads and processes.

> > - Wonderful Kernel 2.6 documentation says that this kernel has some
> > changes made for tcp/ip and that it is big improvement for apache, and
> > this is reason why khttp is not needed anymore.
>
> That and nobody liked/used it, IIRC.
>
> Can you tell us in which file you got this information? Are you talking
> about pthreads or that new thread system that RedHat introduced in RH9
> (nptl or some such).

I can tell you, I found this information in "wonderful+linux" google search,
then search into with keyword "apache".

They spoke about "performance bottlenecks that prevented Apache ..." do you
know more ?

> > - Is there any sort of improvement in putting many ethernet nic on the
> > pci bus ?
>
> No, as they are all sharing the bandwidth of the PCI bus. But this is
> more of a concern when you use Gigabit ethernet.
>

For http server again, where could be the bottelnecks?

> --
> Cameron Kerr
> (E-Mail Removed) : http://nzgeeks.org/cameron/
> Empowered by Perl!

Bash, perl, php should be buried alive, the sooner the best ...

BR.

"RosalieM" <(E-Mail Removed)> wrote in message
news:40d2eee0$0$21593$(E-Mail Removed)...
[snip]
> How can i have a idea of what is done and time needed to switch to a new
> thread, and compare with a new process made by forking and an old process
> that became eligible ? What what is the impact of linux strategy copy on
> demand for processes in this case?

Threads share the memory space of the process. There is no copy-on-write.
That is one of the things that make a thread more "lightweight" than a
(forked) process, there is no need to prepare a new memory map for a new
thread.

>
> > All in all, it's generally better not to use threads if you can avoid
> > it, as you open yourself up to a lot of locking issues which complicate
> > your code and make it harder to debug.
> >

You can say that again, threads can be MUCH harder to debug because they
share the same memory space. They don't necessarily have to share memory
across threads though - separate threads may use their own areas of memory
for their work - but a bug in one thread can trash the memory being used in
another thread, which can't happen when forking (unless you use shared
memory). Basically, if you use the same data in two different threads, you
BETTER know what you are doing or there will be very hard to find bugs (race
conditions, deadlocks, etc.).

>
> > > - Is there any sort of improvement in putting many ethernet nic on the
> > > pci bus ?
> >

The linux kernel has support for using multiple NIC's together (it's called
trunking or something), but the other end of the link has to have the same
support enabled and of course, you have to use multiple network cables. The
PCI bus can transfer much more than one NIC can handle, but more than three
100-megabit NIC's is overkill. There is no benefit for having multiple
gigabit ethernet cards. The PCI bus can't even keep one fully busy.

> For http server again, where could be the bottelnecks?

One bottleneck is file I/O. Hard disks seek time is a limiting factor for
how many pages per second that you can deliver. This is the reason very busy
webservers tend have incredible amounts of RAM (to keep in memory frequenly
accessed data on the hard disk). Also, checking .htaccess all the way back
to the root adds significant I/O overhead. Another bottleneck is spawning
CGI processes.

"Doug Gale" <(E-Mail Removed)> a écrit dans le message de
news:thMAc.344831$(E-Mail Removed) .cable.rogers.com...
> "RosalieM" <(E-Mail Removed)> wrote in message
> news:40d2eee0$0$21593$(E-Mail Removed)...

....

> Threads share the memory space of the process. There is no copy-on-write.
> That is one of the things that make a thread more "lightweight" than a
> (forked) process, there is no need to prepare a new memory map for a new
> thread.... threads can be MUCH harder to debug because they
> share the same memory space. They don't necessarily have to share memory
> across threads though - separate threads may use their own areas of memory
> for their work - but a bug in one thread can trash the memory being used
in
> another thread, which can't happen when forking (unless you use shared
> memory). Basically, if you use the same data in two different threads, you
> BETTER know what you are doing or there will be very hard to find bugs
(race
> conditions, deadlocks, etc.).

thanks

> > > > - Is there any sort of improvement in putting many ethernet nic on
the
> > > > pci bus ?
> The linux kernel has support for using multiple NIC's together (it's
called
> trunking or something), but the other end of the link has to have the same
> support enabled and of course, you have to use multiple network cables...


> > For http server again, where could be the bottelnecks?
>
> One bottleneck is file I/O with Hard disks... Another bottleneck is
spawning
> CGI processes .
>

If i mesured that my computer can handle 100 processes doing
their I/O accesses and their spawning through a socket or pipe,
cant I espect that kernel usage for I/O of the nic would be not so much?

I supposed to use two machines, one using iptable dnat and many nics to do
load balancing
to another computer with many nics too, anyway pci wont handle more than 3
100MB nic?

This way of doing is not competitive compared to one Gigabit nic each side,
even if i have plenty of sockets connecting and sending little amount of
data instead one sending a lot of data?
Depends also of kernel and amount of memory reserved for nic, depends of how
kernel shedule I/O of the nic...

Where can i find documentation about this kinds of problems?

BR.

"Menno Duursma" <(E-Mail Removed)> a écrit dans le message de
news(E-Mail Removed)...
> On Sat, 19 Jun 2004 15:00:24 +0200, RosalieM wrote:
> > "Doug Gale" <(E-Mail Removed)> wrote:
> >> "RosalieM" <(E-Mail Removed)> wrote :
>
> >>>>> - Is there any sort of improvement in putting many ethernet nic on
> >>>>> the pci bus ?
>
> >> The linux kernel has support for using multiple NIC's together (it's
> >> called trunking or something),
>
> Indeed, but the driver for it is called "bonding" though:
> file:/usr/src/linux/Documentation/networking/bonding.txt
>
> >> but the other end of the link has to have the same support enabled and
> >> of course, you have to use multiple network cables...
>
> With 10Base-T or 100Base-TX Ethernet only 4 out of the 8 wires of an UTP
> cable are actually being used (pin 1, 2, 3, and 6). Thus (for testing) one
> could try using a single cable, with two RJ45 jacks crimped on each end...
>
> >> > For http server again, where could be the bottelnecks?
> >>
> >> One bottleneck is file I/O with Hard disks... Another bottleneck is
> >> spawning CGI processes .
>
> http://www.fastcgi.com/
>
> [ ... ]
>
> > I supposed to use two machines, one using iptable dnat and many nics to
> > do load balancing to another computer with many nics too, anyway pci
> > wont handle more than 3 100MB nic?
>
> Well, the standard PCI bus is 32 bits wide, and runs at 33MHz.
> Furthermore, it's a half-duplex shared medium. Theoretically if a NIC were
> to have the bus all to itself maximum throughput (in Mbit/s) would be:
>
> $ echo $[33*32]
> 1056
>
> However, since in a given machine there will at least be HD-controllers on
> the bus as well, and a since TCP acts full-duplex. One might be _very_
> happy to get half that (over a Gbit connection). (And i wouldn't expect a
> 3*100 setup to do any better then 200Mbit/s or so.)
>
> > This way of doing is not competitive compared to one Gigabit nic each
> > side, even if i have plenty of sockets connecting and sending little
> > amount of data instead one sending a lot of data?
>
> Gigabit Ethernet carts aren't all that expensive anymore, so why bother?:
>
http://www.tigerdirect.com/applicati...asp?CatId=1175
>
> Some NIC/driver benchmarks:
> http://www.cs.uni.edu/~gray/gig-over-copper/
>
> > Depends also of kernel and amount of memory reserved for nic, depends of
> > how kernel shedule I/O of the nic...
> >
> > Where can i find documentation about this kinds of problems?
>
> http://datatag.web.cern.ch/datatag/howto/tcp.html
> http://people.redhat.com/alikins/system_tuning.html
>
> --
> -Menno.
>
Thanks i found many doc, and httpserv to discover bottlenecks in live.

Hi
The http server is modeled with a father listen socket process that fork
with accept for incomming sockets.
I like this way of doing as the server for a client is a lone process.

I test server and discover that it cant accept more than 3 rate per second
if i want it to give response in less than a second. httpperf learned me
that. To improve this :
i can try to use threads instead of forking (i beleive before that threads
was windows only)
try to fork process before new connexion come

But i dont know in what direction i should look to change the process that
control a socket. I mean when server fork, son and father share same
sockets, father close service socket and son keep descriptor to this service
socket, but how can son give this socket to another process? This is task
needed if i want to fork becore connexion come ?

And more how can i do this : incomming connection S is accepted by computer
A, A check something send a file in response in S and then gives connexion
to computer B, from now computer B will answer to S until the end ?

Thanks

"RosalieM" <(E-Mail Removed)> wrote in message
news:40da9ee9$0$27048$(E-Mail Removed)...

> I test server and discover that it cant accept more than 3 rate per second
> if i want it to give response in less than a second. httpperf learned me
> that. To improve this :
> i can try to use threads instead of forking (i beleive before that threads
> was windows only)
> try to fork process before new connexion come

Okay, you have listed two different solutions here and seem to be
confusing them.

One is pre-forking. This means that you fork *before* you accept the
connection. This eliminates the overhead of the 'fork' in the time it takes
you to respond to a new connection.

The other is threading. This means that you don't fork at all but
instead use threads within the same process.

> But i dont know in what direction i should look to change the process that
> control a socket. I mean when server fork, son and father share same
> sockets, father close service socket and son keep descriptor to this
> service
> socket, but how can son give this socket to another process? This is task
> needed if i want to fork becore connexion come ?

If you fork before the connection arrives, then both processes have the
service socket. The son calls 'accept' and goes on to handle the connection.

> And more how can i do this : incomming connection S is accepted by
> computer
> A, A check something send a file in response in S and then gives connexion
> to computer B, from now computer B will answer to S until the end ?

You can do that any number of different ways depending upon your exact
requirements. Here are two:

1) Computer A acts a proxy and continues to copy data from S to B.

2) Computer A directs computer S to connect to B directly.

DS

"David Schwartz" <(E-Mail Removed)> a écrit dans le message de
news:cbfasg$rp3$(E-Mail Removed)...
>
> "RosalieM" <(E-Mail Removed)> wrote in message
> news:40da9ee9$0$27048$(E-Mail Removed)...
>
....
> Okay, you have listed two different solutions here and seem to be
> confusing them.
>
> One is pre-forking. This means that you fork *before* you accept the
> connection. This eliminates the overhead of the 'fork' in the time it
takes
> you to respond to a new connection.
>
> The other is threading. This means that you don't fork at all but
> instead use threads within the same process.
>
....
> If you fork before the connection arrives, then both processes have
the
> service socket. The son calls 'accept' and goes on to handle the
connection.
>
I did not imagine this step possible, I supposed that only one listen socket
can be bind to one adress, but in fact it is a copy of the fd and father and
son have the same socket. Cool. Thanks very much.

In general how can a process give connexion (service socket) to another
process ?

> You can do that any number of different ways depending upon your exact
> requirements. Here are two:
>
> 1) Computer A acts a proxy and continues to copy data from S to B.
>
> 2) Computer A directs computer S to connect to B directly.

I thought that proxy could be an aswer to my problem, i prefer search
another solution first. Proxy accept connexion from S, create connexion to B
and copy data as fast as it can? Proxy need rapid cpu?

In other hand if computer A acts as a firewall and router. Iptables DNAT to
B.
I hoped that computer A could load sharing with B, B1, B2 if traffic
increase and A act to limit traffic also.
Can i make A begin new connections with B and then change after traffic to
direct it to B1 ?

BR.