On 2007-08-16 18:45:08 -0500, Peter A Eisch wrote: > On Thu, 16 Aug 2007, Charlie Brady wrote: > > On Thu, 16 Aug 2007, Peter Eisch wrote: > > > > > > As I noted, forkserver was hit or miss without some safeguard to catch > when it tanked. And it did.
Early versions of forkserver died if a child died at an inopportune
moment. That was fixed quite a long time ago and I think it was only a
problem with perl 5.6 (save signals in 5.8 should have taken care of
this). Other than that I don't remember any case where the parent
process of forkserver died.
> > > I have apache running on these systems already for other reasons ...
> >
> > Not everyone does. But your reasons for preferring one start script to
> > another are beside the point. I'm merely trying to discover the details
> > and the basis of assertions about performance.
> >
>
> The assertion about performance is that can get "Plugins already loaded"
> 150 times or so per child (just looking at one child in the live logs
> now).
If that is supposed to be an argument why apache must be faster than
forkserver, I don't follow it. I don't get this message at all with
forkserver (and since its at LOGWARN level, I should see it if it
happens). I dimly recall that with some old version I did get it
reliably once per child, because load_plugins was called a second time
just after the fork - I don't remember when this was fixed.
> > > As to the overall efficiency and speed, I'd really figure that -async can
> > > lay a beat-down on anything that doesn't select() socket arrays.
> >
> > That's speculation, not benchmarking.
> >
>
> No, kind sir. Systems (W. Richard Stevens era) and kernel scheduler
> programmers understand this.
There is a difference between potential performance and actual
performance. Just because a select-based state-machine is potentially
faster, doesn't mean it is measurably faster in the real world. There
are too many other variables involved.
So I agree with Charlie here. Arguing that something must be faster
because it uses select is just speculation. If you want a real
comparison, you need to benchmark it. Of course with benchmarks, you
have to problem that you need a realistic workload, and with qpsmtpd you
probably won't find two installations which use the same plugins, so
results probably cannot be generalized.
Metrics I think are relevant:
> Maybe you have some specific metrics you'd like for me to gather?
* Processed connections per time unit.
* Accepted messages per time unit.
* Latency for accepted messages.
* System load (for a given workload)
* Memory usage (for a given workload)
A change in these metrics when switching from one method to another on
the same machine is probably a good indicator for a given set of plugins
and a given workload.
I don't think any set of metrics is comparable between different systems
and different workloads. A synthetic workload might be useful, though.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | [EMAIL PROTECTED] |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
signature.asc
Description: Digital signature
