CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question

On Fri, 2005-02-11 at 09:44, Wesley D Craig wrote:
> On 07 Feb 2005, at 18:28, Brett Lomas wrote:
> > I have been noticing an alarmingly high amount of time the application
> > (the cosign daemon) spends in the system. It can by up to 3 times the
> > user time.
> Looking at one of our production servers, the ratio is even higher: 
> more like 1:10 to 1:20.  This doesn't surprise me, particularly, as 
> cosignd doesn't really *do* very much.  A typical cosignd transaction 
> is a network read, an open (in a big directory), a read, a close, a 
> network write.  The most intense thing done in user space is crypto, 
> presuming the server doesn't have a crypto card.
> This server that I'm looking at has 821 cosignd's running.
> > I am sure it is no the fork, because i have hacked at the daemon to
> > prefork a large number of children and handle the connections like 
> > that.
> What was the performance like before doing preforks?  What platform are 
> you running on?

Well, the improvement was really noticable. We dont prefork at all here
now, but I have changed the SIGCHLD to ingore so I dont get all of the
signals (and the children dont go zombie).

I noticed a BIG improvement when we put the daemon and ticket
directories onto TMPFS (kinda like RAM disk).

> > When I do an strace of one of the daemons it give nothing which stands
> > out, except for the incredibly large number of getpid calls. I am to
> > understand this is the SSL Cyrpto multi-threaded support. I have gotten
> > ride of a lot of this because defining callbacks for these, and yet
> > still a high amount of system time is spent.
> getpid() is pretty lightweight.  I don't think it's OpenSSL's 
> multi-threaded support, but it *is* OpenSSL.  Have you built cosignd 
> with profiling?  I'd be interested to know what actions your profile 
> tool takes.
> :wes

Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010