On May 10, 2008, at 11:46 AM, Getchell, Adam wrote:
Adam,
I'm sure you're feeling frustrated but please be civil.
Please, show me where I used abusive language, ad-hominem attacks,
or other instances of "uncivil" behavior.
Adam, again I'm sure it's just your frustration talking but it
appeared that you were reading too much antagonism into responses from
someone who was trying to be genuinely helpful. You are also shooting
in so many directions that it's hard for anyone to respond in a
constructive way. It might be more helpful to focus the discussion on
the actual problem rather than escalate a simple request for help into
a wide-ranging unproductive argument that doesn't seem likely to
resolve your technical issues.
So, enterprise authentication using CAS isn't important to a CMS?
This is not what Martin said and I doubt it was even implied.
Actually, it was implied. The product that was said to "suck" was
PloneCAS, which is the product that provides CAS Authentication for
Plone.
No, it was not implied. Please reread the context. Martin was just
pointing out the irrelevancy of "badly behaved products" to the issue
of scalability and the difference between ZEO servers and clients.
From the context, I'm not even sure Martin was necessarily agreeing
with your assessment that PloneCAS is a "badly behaved product". I
personally have never heard of PloneCAS. The only CAS products I've
heard of are CAS4PAS, PloneCASLogin, and collective.castle.
You do realize that your first citation is over 3 years old? And the
second citation appears to be mostly just a howto on setting up some
There seems to be a state of denial about this issue.
Let me be clear: I'm not the only person who experiences this, and/
or who has said this. I've used Plone for more than a few years, and
was one of the first people on our campus to use it. We have a local
Zope/Plone group that meets regularly, and if you look at our Plone
sites, they are some of the largest for our campus.
And all of us have experienced, to one degree or another, the issues
I'm talking about. I appear to have one of the larger deployments
(since we converted our entire College website with 24,000 pages
according to the automated testing tools), so naturally I seem to
have run into the issues rather more heavily.
The fact is that there are plenty of large deployments using Plone
without these issues... although truthfully, I'm not really sure what
are your "issues" other than the error apparently thrown by
RedirectionTool.
As I asked before, is there some, more recent document, which
highlights how to structure Plone for a large scale deployment? If
there is, I'd sure like to read it ...
I don't know if there is a single document on this but the basics are
discussed in a bunch of places... A ZEO server with several clients.
A proxy cache server in front (with or without CacheFu). Plenty of
memory, CPU and diskIO. This usually solves most performance
issues... unless you've got badly behaved products. ;-)
In extreme cases, sometimes you need take extra measures but it's hard
to generalize about this without intimate knowledge of your actual
bottlenecks.
monitoring tools if you've got a problem Zope instance -- it does not
appear to make any claim that suggests that Zope's "performance is
known to be poor".
From the reference -- 'Most people who have been working with Zope
and Plone for some time have learned on one day or another, what it
means for Zope to "spin". It incessantly uses 100% cpu ...'
Most of us don't consider that performance to be good.
You're reading too much into this. It does not say that Zope's
performance is known to be poor. It just says that sometimes, if you
work with Zope long enough, you will experience a "spinning" Zope.
Personally, I think the exposition in that document is a little over-
the-top but spinning Zopes do occur sometimes.... although the last
one I personally remember in a production site was over two years
ago. The cause is usually a bad product or funky customization.
I've never experienced a deployment that needed anything like ZEO
Raid
or RelStorage. As has been pointed out before, it seems unlikely
that
your performance issues would be due to ZEO server bottlenecks. Is
there a specific reason that you feel this is your problem?
Our main site keels over frequently when it was on our Zope/Zeo
cluster. On its own box, it only restarts itself 1-5 times per day.
It still restarts 1-5 times a day on a non-ZEO configuration? This
doesn't sound like a scalability issue.
Nobody said anything about different "boxes" -- just different
"instances". In any case, you're talking about a different kind of
"scalability". Being able to scale up to multiple Plone instances in
a single Zope is not really a performance issue as much as a
management issue. Let's not confuse the issues. Perhaps in your
case, the management issue is minimal. Only you can determine that.
What do you mean by "instance"?
Install Zope (n front ends plus ZEO backend). Add Plone site. Repeat
x 20.
That's the setup I'm talking about. As far as I can tell, it's the
most natural way to add different websites (e.g. Plone sites with
different URLs). It also turns out not to be very performant. (Note:
there's only one ZEO box, with one data.fs, which for us is <2GB)
Install IIS/Apache. Add sites x 20, with host header redirection. No
problems. Add dynamic elements (.NET, modPHP). Still no problems.
If needed, load-balance. Note: that it's very easy to load balance
the back-end database among two or more boxes.
That's the scalability issue compared with other platforms.
Again, although I've never done this, I'm pretty sure you can add 20
Plone sites to a single Zope cluster if you like, assuming your Zope
isn't broken somehow. The issues are mostly management. Keeping
track of the different software stacks required by each Plone site and
updating them in sync when necessary. The management issues are
easier if they all share the same stack but if there are any
significant customizations (and there almost always are), I don't envy
you when you have to migrate 20+ sites from Plone 2.5 to Plone 3.0 in
one evening. But it's still doable... perhaps one way to manage
upgrades is to separate out each Plone site into its own ZODB mount
point and to move the mount to another cluster with the updated
software stack.
Ric
_______________________________________________
Setup mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/setup
