[Enterprise Plone] Plone Deployments and Performances
Francesco Ciriaci
this topic is in between technical needs and marketing material.
We have finally published the first slides on Plone deployments, in
fact nothing really new but at least something that can be re-arranged
and presented to some potential customers. Only two case studies with
few data are there, althought we have gathered much more data and
worked quite a lot in performances&deployments.
The slides:
http://www.slideshare.net/francescociriaci/plone-deployment-wpd2009
are not presenting an analysis of the performances, they are on
deployment only.
I'd like to work something out to "prove" that Plone can deliver not
only very powerful intranets and portals but also fast ones.
Anyway, many thanks to:
* Eric Brankaert - WFP
* Darryl Dixon - Winterhouse Consulting Ltd
* Kelly Craig - Earth Observing Laboratory | DIR
for the hints and the data.
More data and case studies:
In Reflab we are putting together data of important projects we
deployed or are deploying this year: two intranets and a portal.
Number of users, requests, page views and the corresponding hardware
resources deployed.
I'd like to ask in particular to Nate, Geir and Matt if they can share
similar data on the enterprise projects I know they have been working
on.
Thanks,
Francesco.
--
Francesco Ciriaci
Managing Director, Web Architect
Reflab - design, development and consulting
phone +39 050 754193 - mobile +39 333 4284675
skype: fciriaci - http://twitter.com/fciriaci
_______________________________________________
Enterprise mailing list
Enter...@lists.plone.org
http://lists.plone.org/mailman/listinfo/enterprise
Geir Bækholt · Jarn
On 8. sep.. 2009, at 20.55, Francesco Ciriaci wrote:
> The slides:
> http://www.slideshare.net/francescociriaci/plone-deployment-wpd2009
>
> are not presenting an analysis of the performances, they are on
> deployment only.
> I'd like to work something out to "prove" that Plone can deliver not
> only very powerful intranets and portals but also fast ones.
Some comments:
The basic deployments:
We *never* deploy anything without varnish and ZEO. Doing so is just
creating pain down the line. Even without mutlicore, the extra ZEO
instance is incredibly useful for debugging, migrations etc. It may
not even have to be turned on, but we always set it up.
You always need caching so Varnish is a must.
An extra bullet to the slide about pros for relstorage:
- Redundancy. Each client connects directly to the RMDBS(cluster?) so
you can remove ZEO as a single point of failure. This is almost
evident form the diagram but would be clearer if the arrows were
straight horizontal.
I'll try to dig up some numbers on our latest big deployment.
--
_______________________________________________________
Geir Bækholt · Managing Director, Jarn · www.jarn.com
Plone Solutions, Development, Hosting and Support
______________________________________________________
Darryl Dixon - Winterhouse Consulting
> On 8. sep.. 2009, at 20.55, Francesco Ciriaci wrote:
>
>> The slides:
>> http://www.slideshare.net/francescociriaci/plone-deployment-wpd2009
>>
>> are not presenting an analysis of the performances, they are on
>> deployment only.
>> I'd like to work something out to "prove" that Plone can deliver not
>> only very powerful intranets and portals but also fast ones.
>
> Some comments:
>
> The basic deployments:
> We *never* deploy anything without varnish and ZEO. Doing so is just
> creating pain down the line. Even without mutlicore, the extra ZEO
> instance is incredibly useful for debugging, migrations etc. It may
> not even have to be turned on, but we always set it up.
> You always need caching so Varnish is a must.
>
> An extra bullet to the slide about pros for relstorage:
> - Redundancy. Each client connects directly to the RMDBS(cluster?) so
> you can remove ZEO as a single point of failure. This is almost
> evident form the diagram but would be clearer if the arrows were
> straight horizontal.
>
This is an interesting point. Is there anyone out there (you guys Geir?)
who is using an Oracle RAC backend for RelStorage with frontend Zope?
> I'll try to dig up some numbers on our latest big deployment.
Please do :)
Darryl Dixon
Winterhouse Consulting Ltd
http://www.winterhouseconsulting.com
Geir Bækholt · Jarn
On 9. sep.. 2009, at 23.36, Darryl Dixon - Winterhouse Consulting wrote:
> This is an interesting point. Is there anyone out there (you guys
> Geir?)
> who is using an Oracle RAC backend for RelStorage with frontend Zope?
We do, yes. For an enterprise intranet. The scenario that funded the
development of RelStorage ;)
Laurence has proposed do a case study talk at the conference about
this i believe.
--
_______________________________________________________
Geir Bækholt · Managing Director, Jarn · www.jarn.com
Plone Solutions, Development, Hosting and Support
______________________________________________________
Darryl Dixon - Winterhouse Consulting
> On 9. sep.. 2009, at 23.36, Darryl Dixon - Winterhouse Consulting wrote:
>
>> This is an interesting point. Is there anyone out there (you guys
>> Geir?)
>> who is using an Oracle RAC backend for RelStorage with frontend Zope?
>
>
> We do, yes. For an enterprise intranet. The scenario that funded the
> development of RelStorage ;)
> Laurence has proposed do a case study talk at the conference about
> this i believe.
I'm very interested in this. We have a major client with an existing
Oracle RAC infrastructure that could be utilised for this. What sorts of
caveats are there around using loadbalanced/failover connections to the
RAC instance from Zope? Are there any limitations on replacing FileStorage
with RelStorage, or situations where it would be contra-indicated?
Any insight you can offer or recommended reading links would be greatly
appreciated.
regards,
Darryl Dixon
Winterhouse Consulting Ltd
http://www.winterhouseconsulting.com
_______________________________________________
Geir Bækholt · Jarn
On 10. sep.. 2009, at 00.26, Darryl Dixon - Winterhouse Consulting
wrote:
> I'm very interested in this. We have a major client with an existing
> Oracle RAC infrastructure that could be utilised for this. What
> sorts of
> caveats are there around using loadbalanced/failover connections to
> the
> RAC instance from Zope? Are there any limitations on replacing
> FileStorage
> with RelStorage, or situations where it would be contra-indicated?
If you already have an Oracle cluster, there isn't much overhead. For
write-intensive applications you should see a performance increase.
Each ZEO client has its own connection directly to the RAC, so there
is no need for extra loadbalancing beyond the one in front of the ZEO
clients.
It would be contra-indicated in all situations where you don't need
the enterprise-ness of the Oracle Cluster and don't have the RAC
running already. Filestorage is wonderful for its simplicity and
flxibility in dealing with backups and moving servers etc as long as
your demands are within its scope.
--
_______________________________________________________
Geir Bækholt · Managing Director, Jarn · www.jarn.com
Plone Solutions, Development, Hosting and Support
______________________________________________________
Laurence Rowe
>
> On 10. sep.. 2009, at 00.26, Darryl Dixon - Winterhouse Consulting wrote:
>
>> I'm very interested in this. We have a major client with an existing
>> Oracle RAC infrastructure that could be utilised for this. What sorts of
>> caveats are there around using loadbalanced/failover connections to the
>> RAC instance from Zope? Are there any limitations on replacing FileStorage
>> with RelStorage, or situations where it would be contra-indicated?
>
> If you already have an Oracle cluster, there isn't much overhead. For
> write-intensive applications you should see a performance increase. Each ZEO
> client has its own connection directly to the RAC, so there is no need for
> extra loadbalancing beyond the one in front of the ZEO clients.
>
> It would be contra-indicated in all situations where you don't need the
> enterprise-ness of the Oracle Cluster and don't have the RAC running
> already. Filestorage is wonderful for its simplicity and flxibility in
> dealing with backups and moving servers etc as long as your demands are
> within its scope.
To clarify a little, in our experience the network latency between the
Application Server and Database machines has a large effect on
performance, which is particularly acute before the object cache is
filled (as serial object loads multiply the network latency). Oracle
RAC also suffers from additional write latency inherent in any
multi-master transactional system:
"In RAC the node performing the write-transaction must take
ownership of the relevant area of the database: typically this
involves a request across the cluster interconnection (local IP
network) to transfer the data-block ownership from another node to the
one wishing to do the write. This takes a relatively long time (from
few milliseconds to tens of milliseconds) compared to single
database-node using in-memory operations."
http://en.wikipedia.org/wiki/Oracle_RAC
Given this, I would be reluctant to recommend such a system unless you
have a corporate data-management policy mandating it, or a very strict
availability requirement. For pure performance, it is difficult to
beat a single multi-core system packed with memory and fast disks. But
then you have to deal with failover yourself.
Laurence