Updating this thread:
The performance testing with Apache Jmeter "VT CAS test for ticket registry
cleaner testing"
gave us comparable results - to those stated by Marvin. This could be
attributed to the differences in the configuration of load testing (Eg: Ramp
up time was 60 seconds in jmeter
> Can you share with me the hardware configuration ? ( Memory/threads etc.)
CAS is running on a resource-constrained Linux VServer that would
correspond to moderate hardware in my opinion.
> When you say "instantaneous" - you mean to say that the response time -
> that is time taken to view the
Thanks, would check the indexes as well as run the Jmeter tests.
Can you share with me the hardware configuration ? ( Memory/threads etc.)
When you say "instantaneous" - you mean to say that the response time -
that is time taken to view the "Successful Login page" is less than a
second?
Regar
One thing to check is whether the appropriate indexes are on the tables or
not. That could affect the time.
Cheers,
Scott
On Tue, Sep 29, 2009 at 9:56 AM, Marvin Addison wrote:
> > For 50 concurrent users the avg login time is around 2 to 3 seconds for
> JPA
>
> We're seeing nothing like this.
> For 50 concurrent users the avg login time is around 2 to 3 seconds for JPA
We're seeing nothing like this. Authentication is almost
instantaneous from the user's perspective on our setup under moderate
load.
If you want a reasonable basis for comparison, configure the VT JMeter
test attached
Hi,
We have used F5 for load balancing and have deployed cas 3.2.1 on jboss
4.2.3 instance.
While measuring the login click for concurrent users using the hp load
runner tool: we are seeing the following metrics:
- For 50 concurrent users the avg login time is around 2 to 3 seconds for
JPA a
> Could you please guide me as to what factors (pros/cons) are existing for
> each of the ticket registry. (Memcache, JbossCache, JPATicketRegistry) .
I think Scott outlined the 3 options above clearly and concisely. Use
the one that best suits your needs your available infrastructure.
We're goin
Shivani,
* I believe the JBossCache is one of the more difficult ones to configure
and optimize.
* JPA-based is best if you plan on storing tickets for the long term OR you
already have a DB infrastructure in place for clustered DB.
* Memcached requires memcache servers in pairs with the repcache
Hello,
We are using CAS 3.2.1 and are exploring the different ticket registry
implementations that are available for clustering CAS.
Could you please guide me as to what factors (pros/cons) are existing for
each of the ticket registry. (Memcache, JbossCache, JPATicketRegistry) . Any
performance met
David, thanks for taking the time to consider the patch.
> If the ticket read, expire check, and delete are not in a single
> transaction, couldn't the cleaner delete a ticket that had just been renewed
> (if the expire check is based on most recent use)?
No, not in a way that would be unexpected
Marvin Addison wrote:
Regarding the performance issue, what if the transaction were limited to
reading a single Ticket and deleting it if it's expired?
I started leaning toward this sort of solution, but first I had to be
able to reproduce the problem in my environment. I was able to do
t
> Regarding the performance issue, what if the transaction were limited to
> reading a single Ticket and deleting it if it's expired?
I started leaning toward this sort of solution, but first I had to be
able to reproduce the problem in my environment. I was able to do
that and I created http://w
I like your CAS4 plan to make registries responsible for cleaning
themselves.
Regarding the performance issue, what if the transaction were limited to
reading a single Ticket and deleting it if it's expired? It's OK to get
the list of Ticket IDs outside of the transactions, since IDs that wer
> One of the things I've been working on with CAS4 is that Tickets, and the
> items they depend on, have implementations specific to the backing store (so
> that Authentication isn't lumped into a BLOB, for example).
That sounds like a good change, and will be more flexible in the long
run as tick
One of the things I've been working on with CAS4 is that Tickets, and the
items they depend on, have implementations specific to the backing store (so
that Authentication isn't lumped into a BLOB, for example). Its actually a
huge pain in the butt, and I'm not sure if its worth the effort (for one
> Update is only called when a ticket is acted upon (in a number of ways).
I see, so I need the client to do something to trigger the update and
mark the ticket expired, which is the problem I'm trying to solve. I
missed that consequence in your first response. Time to consider
other options.
T
Yes, and my point is that your recommendation for a Jpa specific
implementation only addresses (as far as I can tell, and maybe I read it
wrong) whatever is already covered the automatic cleanup in the
CentralAuthenticationServiceImpl.
Update is only called when a ticket is acted upon (in a number
> CentralAuthenticationServiceImpl [...] does what you want already
> If a TGT or Service Ticket is loaded and its found to be
> expired, its automatically removed.
I understand that CAS cleans up expired tickets in cases where the
client presents the expired ticket. The RegistryCleaner component
Marvin,
I think for the most part, this would not be necessary. If you look at the
code for CentralAuthenticationServiceImpl, it essentially does what you want
already (though there is one spot that doesn't, but its in a less used
area). If a TGT or Service Ticket is loaded and its found to be e
We did some load testing on our clustered dev CAS servers backed by
JpaTicketRegistry to investigate the performance problems others have
mentioned can be caused by DefaultTicketRegistryCleaner,
http://www.nabble.com/DefaultTicketRegistryCleaner---spikes-under-DB-load-td20200644.html
and
http://ww
20 matches
Mail list logo
