Thanks to all for you responses. Linda
Linda Toth University of Alaska - Office of Information Technology (OIT) - Identity and Access Management 910 Yukon Drive, Suite 103 907-450-8320 Fairbanks, Alaska 99775 [email protected] | www.alaska.edu/oit/ On Tue, Sep 10, 2013 at 1:56 PM, Andrew Morgan <[email protected]> wrote: > We had Ellucian run some load testing for our Luminis 5 deployment a > couple years ago, which ended up testing CAS. We created an instance of > CAS with dummy account data (local flat files instead of LDAP). I don't > know how many simultaneous logins were attempted, but we managed to have > nearly 2000 concurrent Luminis logins before the Luminis servers were too > sluggish. > > If you don't see any JVM errors in your Tomcat logs, then I wouldn't > expect any problems with CAS itself. I think Saml10SuccessResponseView is > generating a SAML response when the CAS client calls /samlValidate. The > broken pipe error indicates to me that the underlying TCP connection has > gone away, possibly due to a client timeout. > > Have you tried running Psi-Probe > (http://code.google.com/p/psi-**probe/<http://code.google.com/p/psi-probe/>) > in your Tomcat instance to monitor it? This tool can provide a lot of > useful information. The Connectors page can show you traffic volumes and > response time, as well as what each thread is doing. > > Other than that, I would use normal OS debugging and troubleshooting tools > - top, vmstat, reading Tomcat catalina logs. Are you running out of CPU, > memory, etc? > > What Ticket Registry are you using? Perhaps it is unable to keep up? What > about attribute resolution? Can your LDAP repository handle that many > simultaneous queries? > > Lots of things to check! > > Andy > > > On Tue, 10 Sep 2013, Linda Toth wrote: > > Good afternoon >> >> We have recently implemented SSO for Banner 8 via CAS. Our LDAP >> repository is AD. We are running one CAS server and are now in the process >> of load testing the capability of CAS to match the load volume tested when >> using only Banner BEIS authentication. >> >> The tests are set up through WebLOAD. The tests are designed by setting >> a fixed number of virtual users who attempt to log in at the same time. >> The tests start at 100, then 200, 250, 275, and 300. At 275 simultaneous >> attempts to login, the WebLOAD tool receives many Internal 500 errors. >> >> Some on the team assess the situation as an indication that CAS can not >> keep up with the load. Others suspect the tool itself, which must now >> contend with browser redirects while simulating a high volume of users. >> >> Which ever the case, I do know that there are no issues in volume >> connections to AD. All LDAP authentication steps are made. >> >> The Socket failure messages take the following form, but not always at >> the exact same juncture: >> >> 2013-09-05 07:40:39,174 DEBUG >> [org.jasig.cas.web.support.**SamlArgumentExtractor] >> - Extractor generated service for: >> https://<server>.alaska.edu:**443/<http://alaska.edu:443/> >> <target> >> 2013-09-05 07:40:39,178 ERROR >> [org.jasig.cas.web.view.**Saml10SuccessResponseView] >> - >> ClientAbortException: java.net.SocketException: Broken pipe >> >> 2013-09-05 07:40:42,235 ERROR >> [org.jasig.cas.web.view.**Saml10SuccessResponseView] >> - >> ClientAbortException: java.net.SocketException: Broken pipe >> >> Ellucian, when Atlassian, indicated this error was not fatal, however, >> our team is seeking a definite assurance that a single CAS server can >> manage such high volumes during peak times when login attempts can exceed >> 2000 in the first five minutes. >> >> Has anyone tested the upper limits of simultaneous CAS logins in a >> tomcat/apache configuration? >> >> Linda >> >> PS >> I also should mention that our team has not been interested in using >> tomcat 8443, but instead uses 443. Personally, I do not see a special >> advantage to doing it this way, but there it is. I am forwarding how our >> SA suspects the socket failures are occurring: >> >> Apache's default timeout is 300 seconds. Red Hat reduces the connection >> timeout for Apache to 60 seconds. Most users aren't going to wait more >> than 10 seconds, anyway. If tomcat does not respond to Apache before that >> timeout, Apache will close the connection and log the timeout expired >> messages David mentioned. When tomcat tries to respond after Apache has >> closed the connection it will throw a SocketException with the message >> "Broken Pipe". >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/**display/JSG/cas-user<http://www.ja-sig.org/wiki/display/JSG/cas-user> >> >> > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/**display/JSG/cas-user<http://www.ja-sig.org/wiki/display/JSG/cas-user> > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
