We run memcached on the same servers that run CAS. We actually run them with the repcache patch which means they both have the data in them.
On Tue, Feb 9, 2010 at 2:42 AM, Rolly Ferolino <[email protected]> wrote: > 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 < > [email protected]> 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 <[email protected]>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 < >>> [email protected]> 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 [email protected] as: >>>> [email protected] >>>> >>>> To unsubscribe, change settings or access archives, see >>>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>>> >>> >>> >>> >>> -- >>> Rolly Ferolino >>> [email protected] >>> >>> -- >>> 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 >> >> > > > -- > Rolly Ferolino > [email protected] > > -- > 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
