> Sure - badly behaved products suck. So, enterprise authentication using CAS isn't important to a CMS?
So, what would be the setup for using Plone in a large Enterprise? Say, if Microsoft got rid of SharePoint and started using Plone for their CMS? What would your build out look like? > But this has nothing whatsoever to do with scalability or the > difference > between a ZEO server and a ZEO client. Well, leaving out the products, Plone/Zope still doesn't scale (except possibly with ZEO Raid, which is in SVN so not looking production-ready yet) to more than one backend natively, and its performance is known to be poor, see for example [1], [2]. > 20+ Plone sites in one Zope instance is probably not a good idea, > unless > those 20+ sites are related in some way and share the same set of > products. They do. > > Should we be separate out more instances (thus, ZEO backends), or > > servers? > > Probably. > > > That's the aforementioned scalability issue. > > What is? The fact that you have to put Plone instances on different boxes. I had no problems running 20+ websites on even a single IIS box, and those could be easily load-balanced. If database driven with a SQL backend, SQL could be clustered as well. > to be different, which is almost always the case), then each of them > should be on their own deployment. Otherwise, you've got an enormous > headache in making sure that they don't conflict. At the most basic > level, what happens when site 1 wants to upgrade to Plone 3 and site 2 > needs to stay with Plone 2.5 for a bit longer? You're probably not understanding my deployment scheme ... we're at a University, running a College website and 20+ affiliated Centers. I have complete technical control of all of the sites -- they're on whatever version of Plone we choose. And I agree that Zope/Plone products are an enormous headache. > > But yes, we already carved out our main site and put it on a separate > > box, just to see if we could make sense of the errors and isolate the > > problem. > > Good. But, here's where I think we're seeing past each other -- I *shouldn't* have to. One server -- one site doesn't scale well. That why I refer to it as a "scalability" issue. > There's not much we can do to help you here with no details or > references. Did you see that stack trace I posted that pops up every second or so? > > For one thing, they were causing some of the issues by themselves, > > writing to disk when certain errors were triggered every 200 > > milliseconds or so. So we had to curtail them just on that. > > That sounds insane. I've never seen a Plone site do that. But you don't run Plone sites with 20 instances, right? > If you're getting an error twice per second, it's time to take the site > offline and fix the problem, not solider on mindlessly. And what's the suggested fix? Or even, direction to look? So, just dive into RedirectionTool.py? > I don't wish to be negative, but if you've spent "a couple of hundred > hours" and you haven't get got to the point where you've put a pdb in Not me, personally. If I'd have known the criterion for using Plone was intimate knowledge of Python debugging, I wouldn't have asked my web developers or system admins to use it. > that line and figured out what the problem is (or paid someone to do it > for you, if you don't know how), you need to look at how you're > investing your time and think about how you can get outside help in to > help you diagnose the problem before you sink any more cost into it. Right, so you're saying "Just fire up your Python debugger and go -- I'm not going to help you and if you can't help yourself or pay someone, don't use Plone." Got it. You're right, I'll have to decide if it's worth my time. We just had an RFP for content management systems for our entire campus. Plone was suggested, but not picked. I honestly would have tried to change that decision before, but I see that it was a wise one after all. > Martin > > -- > Author of `Professional Plone Development`, a book for developers who > want to work with Plone. See http://martinaspeli.net/plone-book [1] http://www.456bereastreet.com/archive/200503/content_management_with_plone/ [2] http://plone.org/documentation/how-to/coping-with-a-live-spinning-zope *************** * Adam Getchell, M.S. * Director of Information Technology * College of Agricultural & Environmental Sciences, UC Davis * [EMAIL PROTECTED] (530)752-8008 *************** "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu _______________________________________________ Setup mailing list [email protected] http://lists.plone.org/mailman/listinfo/setup
