Re: Mehr Speed?
"Jens W. Klein" <[email protected]>
| Newsgroups | gmane.comp.web.zope.german |
|---|---|
| Organization | Klein & Partner KEG, BlueDynamics Alliance |
| Message-ID | <1238409148.6818.52.camel@minime> |
Am Montag, den 30.03.2009, 11:37 +0200 schrieb Andreas Gabriel: > Wir arbeiten mit ETags, somit kann der Cache (auch Squid) zwischen > Intranet/Internet unterscheiden. Eigenwerbung ;) Das macht Plone mit CacheFu ja standardmäßig auch schon ;-) Im übrigen kann ich jedem anstelle Squid den Varnish empfehlen. Er ist neben der einfachereren und kompakteren Konfiguration auch vom Speichermanagement wesentlich moderner und effizienter programmiert. Und seit Version 2 ist er stabil. Und von wegen Intranet: Ich denke da eher an Optimierungen an den Object-Caches selber. Kleinigkeiten wie ein Pound z.B. der sein Load-Balancing am __ac Cookie (also dem Authentifizierungencookie) auf einen Zeo-Client festnagelt hilft ungemein. So hat Herr Benutzer 'seine' Objekte in 'seinem' ZEO-Client schon im Cache und sie müssen nicht jedesmal aus der DB geladen und entpickelt werden, wie das bei ungesteuertem Round-Robin passieren würde. Ich habe letztens einen Cluster für ein Intranet (schulische Kommunikationsplattform und Prozessverwaltung) aus drei ZEO-Client (Rendering) Maschinen + weitere Maschinen für die anderen Dienste für derzeit 1500 User (ausgelegt für Parallel-Last mit bis zu 300 Usern) installiert. Die Maschinen sind Dual-Quadcores mit 16GB RAM. Jede Maschine hat 16 ZEO-Clients (je ein Thread) und einen Memcached. Im Hintergrund werkeln ZODB-Server, File-Server, Mail-Server mit SASL, LDAP + Kerberos, vor den Clients stehen Nginx, Varnish und Pound. Trotz Hardware: Das ganze Konstrukt läßt sich nicht ohne detaillierte Profilings auf verschiedenen Ebene dazu bewegen gute Performance zu liefern. Bei der Konstruktion kommt ja auch die Kommunikation via IMAP und LDAP im Hintergrund dazu, die auch gecached werden will. Memcached tut hier gute Dienste. Unsere Plattform basiert auf Plone 2.5, was aber effektiv kein Nachteil ist, naja und ganz soviel ist vom Plone nicht übrig geblieben. Viel Zeit für User und ZEO-Client läßt sich definitiv mit Ajax sparen, ich glaube hier liegt die Zukunft. ESI wäre auch eine Möglichkeit, aber ich glaube, dass es nicht ganz so praktikabel ist, zumal die Development Setups komplizierter werden. gruss Jens -- Jens Klein Software Architect Managing Director, General Partner +43 512 890077 BlueDynamics Alliance WEB APPLICATIONS, ZOPE, PLONE, HOSTING Klein & Partner KEG production: concept, development, design http://bluedynamics.com consulting: analysis, coaching, training http://zoplo.com management: projects, process, community _______________________________________________ zope mailing list [email protected] https://mail.dzug.org/mailman/listinfo/zope