<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="en-VN" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">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..<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Jan<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">users <users-bounces@shibboleth.net> on behalf of Cantor, Scott <cantor.2@osu.edu><br>
<b>Date: </b>Thursday, 24 February 2022 at 14:22<br>
<b>To: </b>Shib Users <users@shibboleth.net><br>
<b>Subject: </b>Re: Help Troubleshooting significant delay in processing in SP<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<br>
<br>
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.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="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$</a>
<br>
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<o:p></o:p></span></p>
</div>
</div>
</body>
</html>