Either a cluster of separate servers or a monster system running numerous instances.
On Fri, Mar 13, 2009 at 7:37 PM, Mark Mandel <[email protected]> wrote: > > Yeah... I have to wonder at 200,000 simultaneous single users on a > single server, regardless of the application server, let alone the > framework. If you have that high a load, I'd be looking at a > clustered solution right off the bat. > > Would anyone disagree with me? > > Mark > > On Sat, Mar 14, 2009 at 7:29 AM, Peter Bell <[email protected]> > wrote: > > I haven't done any load testing on ColdFusion or Transfer with anywhere > near > > that number of users, but as Brian said I'd do a really quick spike and > some > > load testing before you go too far with this. Mark, shoot me down if I'm > > wrong, but I wouldn't call that number of simultaneous users a typical > use > > case for Transfer (or even for a ColdFusion app). If you're really gonna > > have that kind of load out of the gate, you might find the speed of > > development benefits of CF are outweighed by the performance benefits of > > (say) a java based app. Also I'd be looking seriously at clustering > > strategies (I don't know how easy/possible it is to cluster with > Transfer) > > as I'm not sure if you'd want 200,000 logged in users running on a single > > machine (assuming they interact with the server with some frequency). > > Best Wishes, > > Peter > > > > On Mar 13, 2009, at 4:17 PM, Brian Kotek wrote: > > > > If any individual User only has a few attributes, then a oneToMany is > fine. > > If a User had 5,000 attributes, it would not be fine. > > > > 200,000 instances is a lot, but "a lot" depends on your hardware, RAM, > heap > > size, etc. With 200,000 simultaneous connections, I'm assuming this is a > > monster server. So it will probably be ok. Before you go too far I'd just > > run a load test and see how it works. > > > > > > On Fri, Mar 13, 2009 at 11:46 AM, John Whish <[email protected]> > > wrote: > >> > >> Hi Brian, I might be going down completely the wrong path with this. > >> I'm expecting 200,000 users logged in at once. The idea is to > "encapsulate > >> what changes" and stick all user attributes that aren't common to all > users > >> into another class. Users will probably only have 3-4 specific > attributes > >> (although as the system grows it will no doubt be added to). > >> As I understand it, 200,000 x 4 is a lot of objects to store in the > >> transfer cache so it will be constantly instantiating those objects. > >> Originally I was using the proxy before I decided to try storing a > struct > >> directly in the User object. > >> As I get the user object when they log in I don't see how I could use > >> a manyToOne in this scenario. > >> > >> I got the idea from the heads up OOA&D guitar store example, if that > >> helps. > >> > >> > > > > > > > > > > > > > > > > > > > > > -- > E: [email protected] > W: www.compoundtheory.com > > > > --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
