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/) 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/<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: mor...@orst.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
