SP State and Clustering

[Bill Moseley]

On Tue, Mar 14, 2017 at 7:02 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > I'm asking because it takes quite a bit of time to restart shibd (about 8
> > minutes) and during this time the SP is unavailable.
>
> There is no earthly reason shibd would take 8 minutes to start up barring
> no resources or a totally screwed up approach to metadata. Even the eduGAIN
> metadata aggregate doesn't take much more than a minute or so, still bad,
> but nothing like that. And we have that improved now so that initial
> startup doesn't verify the signature on the backup file, so I doubt it even
> takes that long. You're doing something wrong.
>

$ shibd -v
shibboleth 2.4.3

Watching shibd start just now (using strace and top) it took 8 minutes, and
for about almost 6 minutes of that it was just spinning at 100% cpu not
making any system calls.  By the end it's using over 2GB of virtual and
1.1GB of resident memory.

We have seven federations configured as well as a few direct IdPs.  Does
that still seem unreasonably long for that much configuration?  If so, any
suggestion on additional debugging?



>
> > Our load balancer is currently configured for sticky sessions (by IP)
> for the SP cluster.  So, if one of
> > the SPs in the cluster is taken down then any in-flight authentications
> would fail.
>
> Any in flight logins will fail on the initial redirect to a resource no
> matter what (unless the state is offloaded).
>

Yes, that makes sense.

I don't suppose there a way to have the "POST /Shibboleth.sso/SAML2/POST"
on our SP run a script directly instead of making the redirect back to the
original resource, right?


Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170317/2c36731b/attachment.html>