Thanks, Scott. Are you using the same two-node CAS servers as your memcached servers; or do you have separate servers for your memcached. One thing that worries us about memcached is the single-point of failure. Do you use a backend DB to reduce the risk (check memchached, if not exists check DB and load to memcached).?
Thanks, Rolly On Mon, Feb 8, 2010 at 11:10 AM, Scott Battaglia <scott.battag...@gmail.com>wrote: > We're using a two-node CAS server with memcached to handle about 50K > users. We have plenty of capacity left over. If I remember (or someone > reminds me) I can see if I can gather our authentication/seconds or > authentication/minute stats. I'm not at my desk now so I'll have to do it > tomorrow. > > Cheers, > Scott > > > On Fri, Feb 5, 2010 at 4:49 PM, Rolly Ferolino <rferol...@gmail.com>wrote: > >> Marvin, >> >> Thank you for the reply. Would you mind sharing your cluster >> configuration? We are testing our installation on a four-node Tomcat >> cluster, using JBOSS Cache to replicate the TicketRegistry. We are planning >> to serve 80K users and I am concern right now on how much users and how many >> nodes this setup can scale to. Any clustering war stories from the community >> will be greatly appreciated. >> >> Thanks, >> Rolly Ferolino >> University of Phoenix >> >> >> On Thu, Feb 4, 2010 at 12:48 PM, Marvin Addison <marvin.addi...@gmail.com >> > wrote: >> >>> > What is the best practice for hosting the SSL certificate? >>> >>> There's no best practice here. If you want to leverage the SSL >>> offloading capabilities of your load balancing hardware, host the >>> certificate on the LB and forward the request to a non-SSL port on the >>> application server. If you feel the SSL handling capability of your >>> LB is negligibly better than your application servers, host the >>> certificate on each app server. I would argue there may be a security >>> risk in the first scenario since you are trusting the network behind >>> your LB, but this is a reasonable assumption in many cases. >>> >>> I should note that we think SSL offloading is largely vendor snake oil >>> and we like the ability to control our app server configuration, >>> including SSL handling, instead of having to cooperate with our LB >>> admins for the SSL setup. (They're great, it's just that we have >>> adopted a strategy of "keep the LB stupid" which has worked well for >>> us. Additionally our "big iron" ServerIron devices only recently got >>> the SSL offloading working to the satisfaction of our LB admins. >>> YMMV.) >>> >>> M >>> >>> -- >>> You are currently subscribed to cas-user@lists.jasig.org as: >>> rferol...@gmail.com >>> >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>> >> >> >> >> -- >> Rolly Ferolino >> rferol...@gmail.com >> >> -- >> You are currently subscribed to cas-user@lists.jasig.org as: >> scott.battag...@gmail.com >> >> >> >> 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: > rferol...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- Rolly Ferolino rferol...@gmail.com -- 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
