Efficient methods
in [Embedded]
|
From: Karthik Balaguru on 21 Feb 2010 09:42 On Feb 21, 2:55 pm, David Schwartz <dav...(a)webmaster.com> wrote: > On Feb 20, 5:10 am, karthikbalaguru <karthikbalagur...(a)gmail.com> > wrote: > > > While reading about the various designs, interestingly i > > came across an info that the design of TCP servers is > > mostly such that whenever it accepts a connection, > > a new process is invoked to handle it . > > This is like a singly-linked list. It's the first thing you learn, and > so many people tend to assume it's used a lot in the real world. In > actuality, it's only common in special cases, such as when each > instance needs its own security context (like in 'telnetd' and > 'sshd'). > > > But, it seems that in the case of UDP servers design, > > there is only a single process that handles all client > > requests. > > This is the norm for TCP too, most of the time. But it's more > obviously reasonable for UDP, since there are no connections. You > can't create one process for each connection because there's no such > thing. > True. It depends on the nature of TCP and UDP. > > Why such a difference in design of TCP and > > UDP servers ? > > To the extent there is such a difference, it's because of the > different things the servers do. For example, TCP is commonly used for > web servers. Each web connection is a separate logical operation with > multiple steps that affect only that operation. However, a typical UDP > server (such as a time server or resolver) needs to maintain some > global state that each packet received minorly interacts with. > Agreed. > > How is TCP server able to handle > > large number of very rapid near-simultaneous connections ? > > Process-per-connection servers tend to do this very poorly. Yeah , it will overload the servers. > But one > trick is to create the processes before you need them rather than > after. > The trick of creating the process before the actual need sounds interesting and appears similar to pre-forking. Here a server launches a number of child processes when it starts. Those inturn would be serving the new connection requests by having some kind of locking mechanism around the call to accept so that at any point of time, only one child can use it and the others will be blocked until the lock is released. There seem to be some way out of that locking problem. Karthik Balaguru
From: karthikbalaguru on 21 Feb 2010 10:54 On Feb 21, 2:55 pm, David Schwartz <dav...(a)webmaster.com> wrote: > On Feb 20, 5:10 am, karthikbalaguru <karthikbalagur...(a)gmail.com> > wrote: > > > How is TCP server able to handle > > large number of very rapid near-simultaneous connections ? > > Process-per-connection servers tend to do this very poorly. It overloads the server. > But one > trick is to create the processes before you need them rather than > after. > But, how many processes should be created at the server ? How will the server know about the number of processes that it has to create ? Any ideas ? Thx in advans, Karthik Balaguru
From: David Schwartz on 21 Feb 2010 14:38 On Feb 21, 7:54 am, karthikbalaguru <karthikbalagur...(a)gmail.com> wrote: > But, how many processes should be created at the server ? > How will the server know about the number of processes that it > has to create ? Any ideas ? Note that this is a key weakness of the 'process-per-connection' model, and I recommend just not using that model unless it's mandated by other concerned (such as cases where security is more important than performance). But there are two techniques, and they are typically used in combination. One is static configuration. This is key on initial server startup. For example, versions of Apache that were process per connection let you set the number of processes to be started up initially. They also let you set the target number of 'spare' servers waiting for connections. The other technique is dynamic tuning. You monitor the maximum number of servers you've ever needed at once, and you keep close to that many around unless you've had long period of inactivity. Servers are going to be slow to start up anyway, and the time to create new processes is not way out of line with the time to fault in pages of code and other delays during server startup that you can do very little about. DS
From: rickman on 21 Feb 2010 19:23 On Feb 21, 10:54 am, karthikbalaguru <karthikbalagur...(a)gmail.com> wrote: > On Feb 21, 2:55 pm, David Schwartz <dav...(a)webmaster.com> wrote: > > > On Feb 20, 5:10 am, karthikbalaguru <karthikbalagur...(a)gmail.com> > > wrote: > > > > How is TCP server able to handle > > > large number of very rapid near-simultaneous connections ? > > > Process-per-connection servers tend to do this very poorly. > > It overloads the server. > > > But one > > trick is to create the processes before you need them rather than > > after. > > But, how many processes should be created at the server ? > How will the server know about the number of processes that it > has to create ? Any ideas ? If it is really just the creation time that is an issue for running many processes, one could always be waiting as a hot spare. When it is then turned loose for a new connection a new process could then be created as a background task. Rick
From: karthikbalaguru on 21 Feb 2010 21:22
On Feb 22, 12:38 am, David Schwartz <dav...(a)webmaster.com> wrote: > On Feb 21, 7:54 am, karthikbalaguru <karthikbalagur...(a)gmail.com> > wrote: > > > But, how many processes should be created at the server ? > > How will the server know about the number of processes that it > > has to create ? Any ideas ? > > Note that this is a key weakness of the 'process-per-connection' > model, and I recommend just not using that model unless it's mandated > by other concerned (such as cases where security is more important > than performance). > But, how is that technique of 'process-per-connection' very helpful for security ? > But there are two techniques, and they are typically used in > combination. One is static configuration. This is key on initial > server startup. For example, versions of Apache that were process per > connection let you set the number of processes to be started up > initially. They also let you set the target number of 'spare' servers > waiting for connections. > In case of static configurations, wouldn't that target number of servers started initially load the server ? There seems to be a drawback in this approach as the 'spare' servers/processes might be created unnecessarily even if there are only less clients. That is, if there are less clients, then those servers will be waiting for connections unnecessarily. This in turn would consume system resources. > The other technique is dynamic tuning. You monitor the maximum number > of servers you've ever needed at once, and you keep close to that many > around unless you've had long period of inactivity. > Dynamic tuning appears to overcome the drawbacks w.r.t static configuration, But the scenario of 'long period of inactivity' requires some thought. During that time, we might need to unnecessarily terminate and restart enough number of processes. But, since we cannot not be completely sure of the time of maximum traffic arrival, we might land up in having all those servers running unnecessarily for long time :-( . Any thoughts ? The process of termination and recreation also consume system resources. > Servers are going to be slow to start up anyway, and the time to > create new processes is not way out of line with the time to fault in > pages of code and other delays during server startup that you can do > very little about. > Thx in advans, Karthik Balaguru |