Plone Deployments and Performances

[Francesco Ciriaci]

Hi all,

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 [phone] - mobile [phone]
skype: fciriaci - http://twitter.com/fciriaci






_______________________________________________
Enterprise mailing list
[hidden email]
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
______________________________________________________




_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Darryl Dixon - Winterhouse Consulting-2]

>
> 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

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[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
______________________________________________________




_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Darryl Dixon - Winterhouse Consulting-2]

>
> 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

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[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
______________________________________________________




_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise

[Laurence Rowe]

2009/9/14 Geir Bækholt · Jarn <[hidden email]>:

>
> 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

_______________________________________________
Enterprise mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/enterprise