Hey Tom, Some thoughts below...
On Thu, May 30, 2013 at 11:54 PM, Tom Poage <[email protected]> wrote: > Evening, > > Question on experiences with replication reliability. > > I'm doing a bit of 'burn-in' testing of a new pair of CAS servers (3.5.2, > Ehcache, RMI replication). > > The testing loops in a single thread on randomized loginids from a pool of > 20k accounts, submitting a login POST to a random node of the pair, waits a > little bit (50ms), then submits the resulting service ticket to its companion > node. This generates about 7.5 authentication + service ticket validation > transactions per server per second. > > So I get an ST validation failure on the companion node in about 0.3% (3 in > 1000) of the cases. What was the cause of the ST validation failure? What was in the cas.log? Since ehcache is set to synchronous replication the ST should have already been available in the other node before CAS returned it to your test script. > > The service ticket cache is set to (the default) synchronous replication + > multicast on the RHEL 6 (VMware) VMs, Oracle Java 7, no JVM tuning, Tomcat 6. > The servers themselves are spec'd fairly small (1 GB, 1 CPU) when compared to > our existing physical CAS production servers. > > Before I try to dive into what might be a proverbial haystack, is the > occasional 'loss' (or delay) of a service ticket considered acceptable? If > so, at what rate? For a worst-case scenario (i.e. a fast CAS client), is 50ms > realistic? Only you can answer that for your situation. At some load any app is going to start to have problems, and your current test configuration may be closer to a stress test than a load test. As Jérôme points out the 50ms pause is likely way to short given the actual solution architecture. Consider that there are actually two https hops for a typical ST validation (browser -> service -> CAS). If you have the time, I'd live to hear the results with a 500ms wait time. And if you are really ambitions, would love to have the results against memcached ticket registry to compare to. Best, Bill > > Thanks! > Tom. > -- > 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 > -- 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
