We tested CAS last fall and again just after the first of this year when load testing our new Liferay portal. With the Liferay testing we pushed over 2000 simultaneous connections on two Liferay servers with CAS logins handled by two clustered servers. The Liferay servers became the bottleneck with over 2000 servers (really some of our portlets calling to other slower systems), but the CAS portion held up very well. I had stats on the CAS auth portion which indicated that CAS response was <30ms throughout. System load on the CAS servers indicated that they could still handle plenty more. That didn't tell us anything about what the upper limit might be for CAS, but it made it clear that 2000 simultaneous sessions was not a problem at all. We did get some 500 errors during our load testing which we did using Jmeter. Most of those came when the servers doing the load testing couldn't keep up. I found that running more loadtest servers with each handling a limited number of concurrent sessions (<500) provided smoother test without all the 500s. We did get some 500s at the high end of the testing when our Liferay servers were getting pretty stressed, but we knew that came from the Liferay server stress. I would take a look to see if your servers doing the load testing are getting stressed.
Happy testing Ted Fisher Bowling Green State University. -----Original Message----- From: Linda Toth [mailto:ltt...@alaska.edu] Sent: Tuesday, September 10, 2013 5:38 PM To: cas-user@lists.jasig.org Subject: [cas-user] Socket error at high volumes 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/<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 cas-user@lists.jasig.org as: tffi...@bgsu.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
