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 and over 5 to 8 seconds for Jboss. - We are getting average response time for 100 concurrent users as ~10 to 11 seconds for JPA and for Jboss. - And for 250 concurrent users the response time is degrading to over ~>15 to 25 seconds for both. Jboss Cache response time on the higher end. Before I go into analyzing as to the cause of such high response times, (Machine configurations etc...) I would like to know the stats confirmation - and any other tuning that is required (for JPA already I have already put in the patch for cleaning expired tickets). Shivani. On Mon, Sep 7, 2009 at 5:28 PM, Marvin Addison <marvin.addi...@gmail.com>wrote: > > 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 going with JPATicketRegistry on Oracle primarily because we have > a solid Oracle infrastructure that is administered by capable DBAs. > > > Any performance metrics available for them serving as basis of > comparison?. > > Comparative performance metrics that are meaningful are tough to come > by. There are many anecdotes and little data. I recall someone wrote > to the list recently describing their switch from > JPATicketRegistry/Oracle to Memchache for a very high traffic site. I > imagine that's the best you'll get as far as a meaningful comparison. > > > I understand that by changing the scope of the transaction (for > > getTickets/deleteTickets method) has resolved the issues related to > deadlock > > faced in JPATicketRegistry. > > It has been resolved as far as our testing has indicated. Others have > reported positive results from the fix as well. > > We're going live with our JPATicketRegistry-based CAS next week, and > I'd be happy to provide a status update in a month or so. I wouldn't > mind providing some rough performance metrics. I can say that in our > stress testing were were able to handle ~3000 transactions/min with > our JPATicketRegistry setup. I expect the results in production, on > beefier DB hardware, could be greater but it's doubtful we'll see that > kind of traffic even during peak periods. > > M > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > shivani.chan...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to cas-dev@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-dev
