We saw horrible response times even at relatively low load. I don't have the numbers with me here. We were running it on two Sun V240s. Our current set up with two Sun T5120 and repcache performs significantly faster (ignoring the fact that the machines are in general a lot faster than the V240).
-Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Fri, Oct 3, 2008 at 8:00 AM, Andrew Ralph Feller, afelle1 < [EMAIL PROTECTED]> wrote: > Now that is something interesting! What performance expectations did it > not meet? Throughput (# logins / second)? Network Utilization? > > Thanks, > Andy > > > On 10/2/08 3:16 PM, "Scott Battaglia" <[EMAIL PROTECTED]> wrote: > > I probably pasted someone's example. We've never used it successfully > here. And by successful I mean that it met our performance expectations. > ;-) > > -Scott > > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > On Thu, Oct 2, 2008 at 3:46 PM, Andrew Ralph Feller, afelle1 < > [EMAIL PROTECTED]> wrote: > > Scott, > > Yeah, I thought yall would have done so lest that feature might not have > made it into the project. =) Though since SVN blame/praise shows you > checked it in at revision 39423, I was hoping you had some knowledge about > the configuration choices made. Was this file provided by someone else > originally and simply included? > > Thank you, > Andrew > > > On 10/2/08 2:07 PM, "Scott Battaglia" <[EMAIL PROTECTED] < > http://[EMAIL PROTECTED]> > wrote: > > Sorry, we deploy using repcache (memcached) at Rutgers. > > -Scott > > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > On Thu, Oct 2, 2008 at 2:15 PM, Andrew Ralph Feller, afelle1 < > [EMAIL PROTECTED] <http://[EMAIL PROTECTED]> > wrote: > > Anyone? > > > > > On 10/1/08 2:17 PM, "Andrew Feller" <[EMAIL PROTECTED] < > http://[EMAIL PROTECTED]> <http://[EMAIL PROTECTED]> > wrote: > > Since we originally deployed CAS, a sample configuration file for Jboss > Cache has been distributed with the CAS server ( > https://www.ja-sig.org/svn/cas3/tags/cas-3-2-1-final/cas-server-integration-jboss/src/test/resources/jbossTestCache.xml). > Upon comparing it with our current configuration, I have noticed there > have been several discrepancies, which I hoped could be explained. > > JGroups discrepancies > > 1. <FD> has been commented out in favor of <FD_SOCK> > 2. <pbcast.NAKACK> and <UNICAST> are both used > 3. <FRAG> has been included > > > JBoss Cache Discrepancies > > 1. UseReplQueue, ReplQueueInterval, ReplQueueMaxElements are declared > but are only used by asynchronous replication > 2. TransactionManager is specified yet the online documentation for > cluster has it being removed ( > http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS ) > > > My primary focus is on the JGroup changes as I don't know if FD_SOCK uses > the same notion of shunning as FD. The source behind FD_SOCK shows removal > of suspect members and broadcasting the removal to the cluster, so it should > be okay. I am also curious why the <FRAG> entity was introduced; were > people having replication packets that were too large or being blocked due > to size? > > Thanks, > Andrew > > > -- > Andrew R. Feller, Analyst > Information Technology Services > 200 Fred Frey Building > Louisiana State University > Baton Rouge, LA 70803 > (225) 578-3737 (Office) > (225) 578-6400 (Fax) > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
