Help Troubleshooting significant delay in processing in SP

[Jan Vilhuber]

Sorry I may have been a little confusing: I didn’t mean multiple apache servers share a single shib via the socket. It’s 1:1 (just as if shibd was running alongside apache on a VM). I just wanted to call it out as a potentially unusual deployment, but really it’s no different than a side-by-side apache/shib deployment for all intents and purposes.

Are there any extra debugs I can turn on that would show Memcached taking a while? I do have plans on moving to redis (with an in-house redis plugin; once it’s been more tested, I plan on sharing it somehow), but I’m not there yet..

Jan


From: users <users-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Date: Thursday, 24 February 2022 at 14:22
To: Shib Users <users at shibboleth.net>
Subject: Re: Help Troubleshooting significant delay in processing in SP
Memcache, which is known to be unstable and unreliable (I mean the plugin) jumps out as the most obvious cause. That many transactions isn't going to cause anything unusual in the SP itself. A full on load test with the same NameID will blow it up badly, but not at that scale.

If the gap in the log is sitting inside a bunch of memcache calls, I don't see much reason to think it's anything else. Just stop using it. If you're sharing a socket, you have to be sharing a shibd instance, in which case memcache doesn't add anything anyway.

-- Scott


--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!GEjU_1jlQXGQfQ!whhTNKS88CJ-rLUMPV89C5C0KSOhdp1a7LyxlnkBJXA2leuXo5UzZVmLGm2czc-R1A$<https://urldefense.com/v3/__https:/shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!GEjU_1jlQXGQfQ!whhTNKS88CJ-rLUMPV89C5C0KSOhdp1a7LyxlnkBJXA2leuXo5UzZVmLGm2czc-R1A$>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220224/61bc3fd5/attachment.htm>