Meinungsbild: Performanz

Ich nutze momentan Drupal mit 155 Contrib-Modulen + 5 kleine eigene Module auf nem VServer. DB-Tabellen habe ich knapp 250.
4 GB RAM + 8 GB SWAP - der Server ist ein Super-Micro mit SAS-Platten und hat, neben meinem VServer, noch eine weitere Instanz drauf.

Ich setze Memcache und APC ein.

Bei 10 Usern gleichzeitig werden die Seiten in 1 - 1,3 Sekunden ausgeliefert.
Bei 20 Usern gleichzeitig in 1,2 - 1,4 Sekunden.
Bei 30 Usern gleichzeitig in 1,3 - 1,5 Sekunden.
Bei 40 Usern gleichzeitig in 1,4 - 1,6 Sekunden.

Der Aufruf der Module-Übersicht im Admin-Bereich dauert, wenn weitere 30 User gleichzeitg auf mein Projekt zugreifen, ca. 2 Sekunden. Auf meinem Desktop-PC mit XAMPP dauert das ungefähr 10 mal so lange (obwohl ich dann der einzige User bin) ;-)

Testweise habe ich auch schon Varnish eingesetzt, dort werden die Seiten, bei 100 gleichzeitigen Usern, in einem Wimpernschlag, gemessen, in 300 ms ausgeliefert (Facebook nutzt auch Varnish).

Boost setze ich nicht ein.

Ich hatte, testweise, auch schon einen VServer bei einem Massenanbieter (da waren auf dem Server zwischen 25 - 100 andere Vserver drauf) - das konnte man aber, performance-technisch, völlig vergessen.

P.S. Der PR wird nicht herabgestuft wenn "die Seitenladezeit schlecht ist" ....

Gruß Matthias

Man kann hier schwer verallgemeinern. Ich kenne Installationen mit einer dreistelligen Anzahl von Modulen, die auch eingeloggt flott laufen und welche mit wenigen Modulen die ächzen und stöhnen, jeweils auf Hardware (dediziert oder gut dimensioniert virtuell) die mehr als ausreichend ist.
Selbst wenn zwei Sites genau dieselben Module verwenden kann auf derselben Hardware ganz unterschiedliche Perfomance dabei herumkommen. Wie und womit man seine Inhaltstypen aufbaut, wie man sie themet, wie man die Views aufbaut, ... hat alles Einfluss auf die Endperformance.

Dass es Contrib-Module gibt die für sich gesehen oder in Kombination mit bestimmten anderen Modulen und je nachdem wie man sie einsetzt zu Engpässen kommen kann, ist unbestritten. Hält man sich die Komeplexizität des Systems einmal vor Augen und die Tatsache, dass jede Installation gewissermaßen einzigartig ist und es gerade bei Modulen, die von wenigen Leuten entwickelt und genutzt werden schwierig ist die Problemfälle frühzeitig zu erkennen und dagegen zu arbeiten erscheint auch logisch.

Hier sind auch immerwieder sie Site-Builder selbst gefragt qualifiziertes Feedback in den Issue Queues zu geben, Patches beizusteuern und damit aktiv an der Weiterentwicklung teilzunehmen. Das ist auch nicht zu viel verlangt wenn man schaut wieviel Arbeit in die Module geflossen ist, die wir alle kostenlos einsetzen können.

Grundsätzlich kann ich auf einem Wald-und-Wiesen-Hosting nicht allzu viel erwarten. Ein Hosters ist bestrebt jede Maschine möglichst gut auszulasten um so viel Umsatz pro Maschine zu machen wie möglich, während er den Arbeitsaufwand durch Automatisierung und das Fehlen von kundenspezfisichen Einstellungen möglichst gering hält. Ordentliche Leistungsreservern sind nur möglich wenn der Hoster seine Maschinen monitort, bzw. nur eine geringe Anzahl Kunden / Webs darauf zulässt, dafür muss er die Preise aber entsprechend anheben. Auch dann beeinflussen sich die Webs aber alle noch gegenseitig. Garantierte Ressourcen kann es nur bei virtuellen und dedizierten Servern geben. Grundsätzlich gilt: You get what you pay for.

Und einen Shared Hosting Server bekommst du mit zunehmender Anzahl von Webs immer schlechter optimiert. PHP Opcode Caches, MySQL Query Cache, etc. produzieren am laufenden Band Cache Misses weil sich die Daten der verschiedenen gehosteten Projekte gegenseitig aus den Caches raushauen.

Meine Kunden haben in der Regel bereits ein Hosting, oder ich empfehle ihnen eines, passend zum Projekt. Typischerweise sind sie in Sachen Shared Hosting bei Hosteurope, All Inkl., oder haben virtuelle Maschinen (Hosteurope, Linode, Mediatemple) oder dedizierte.
Ich selbst hoste auf einer virtuellen und ein paar dedizierter Maschinen. Nur in einem Umfeld das ich rundherum betreuen und monitoren kann bin ich überhaupt in der Lage Performance aussagekräftig zu messen, Bottlenecks zu identifizieren und Gegenmaßnahmen einzugreifen. Webserver, Datenbank und PHP haben alleine schon jeweils dutzende verschiedener Stellschrauben die auf die gehosteten Projekte hin optimiert werden wollen, zudem gibt es noch diverse andere Möglichkeiten mehr Performance / Skalierbarkeit zu erreichen (Boost, APC, Memcache, nginx, Varnish, Multi-Server, MariaDB / Percona, CDN, ...).

Bei Kunden kommt ein bunter Mix von allem möglichen zum Einsatz. Je nachdem was im Einzelfall Sinn macht. Daneben gilt es natürlich Ursachen auf den Grund zu gehen und auzumerzen. D.h. Codes zu checken, Cachegrind-Dateien zu untersuchen, etc.

Und wie lonit schon schrieb hat der Pagerank nicht das geringste mit Ladezeiten zu tun.

@lonit:
Bei 4 GB RAM wirst du im Normalbetrieb nie erleben, dass du die 8 GB voll bekommst. Vorher ist die Karre total abgesoffen. Eine Karre die regelmäßig swappt braucht RAM. Mehr CPU-Power kann auch helfen, aber RAM aufrüsten ist in 99% der Fälle eher und günstiger möglich.

Hi und danke für deine schnelle Antwort - ein paar Rückfragen dazu:

Wie genau hast du das implementiert, nutzt du die hierfür erhältlichen Module?

...hast es aber aus WELCHEM Grund dann doch nicht getan?

Ich glaube nicht, daß man meinen Anbieter so nennen kann, aber wie auch immer, wo bist du denn? Eine gute Empfehlung ist ja nie zu verachten!

Ich kenne die Kriterien von Google nicht (wer schon!), aber wenn mich Google selbst als "dringender Verbesserungshinweis" auf die Ladezeiten hinweist? Egal, das war nur eine Randbemerkung, wichtiger ist mir das Endbenutzererlebnis. :-)

Hast Du schon mal ueber Hosting in Amazons EC2-Cloud nach gedacht. Zum Kennenlernen gibt es eine Micro-Instance frei und dann kannst Du weiter aufruesten, bis die Hardware die gewuenschte Performance bringt.

APC ist ein serverseitiger Cache ... hierbei muss nicht bei jedem Seitenaufruft die PHP Datei geparst und interpretiert werden. Installiert wird der (unter Debian) einfach über apt-get install php5-apc

Memcache(d) ist ein Cache-Server der diverse Daten (die normalerweise aus der Datenbank gezogen werden) im Arbeitsspeicher vorrätig hält sodss bei gleichen Anfragen nicht die Datenbank belastet wird sondern diese direkt aus dem Arbeitsspeicher bedient werden. Das geht natürlich viel schneller.

Zu APC bzw. Memcache(d) einfach mal Google bemühen.

Der Grund war banal. Erstens wollte ich Varnish nur mal testen (das Teil rockt aber gewaltig) denn Varnish ist ja eigentlich für High-Traffic-Projekte gedacht (es kann bis zu 3000 Zugriffe pro Sekunde bedienen). Zweitens: Man muss Varnish über VCL (Varnish Configuration Language) beibringen was nicht gecached werden soll (wichtig z.B. für Statistikprogramme). Solche Abfragen sollen nicht von Varnish "bearbeitet" werden sondern vom Apache. Da ich aber, als Varnish lief, Probleme hatte mein liebgewonnenes, niedliches Statistiktool weiter zu nutzen und ich zum damaligen Zeitpunkt sehr wenig Zeit hatte, was mich daran hinderte mich intensiver mit VCL zu beschäftigen, habe ich Varnish einfach wieder runter geschmissen. Es war ja soweiso nur zum Testen.

Zu einem späteren Zeitpunkt werde ich aber Varnish wieder nutzen. Ich komme ja auch nicht aus dem Coder-Bereich - somit dauert das bei mir immer etwas länger wenn ich mich mit einer neuen "Script-Sprache/Language" beschäftigen muss. Diese Zeit werde ich mir dann, bei Bedarf, mal nehmen.

Varnish lief aber super und ein Loadbalance-Test brachte unglaubliche Ergebnisse. Da kommt man aus dem Staunen nicht mehr raus.

Ich hoste in Holland bei einem ganz kleinen Anbieter da ich was mit "Erotik" betreibe - somit würde Dir, für ein deutsches Projekt, eine Emfehlung nichts bringen.

Wende Dich diesbezüglich doch mal an den Alexander (http://www.drupalcenter.de/user/1336). Er ist hier, was Drupal und Server angeht, der Spezi. Er betreut ja auch den/die Server für Drupalcenter. Ich bin mir sicher er kann Dir bei allen Serverfragen professionell helfen.

Google weist darauf hin, reagiert bei langsamen Seiten aber nicht mit "PR-Verlust". PR-Verlust findet statt, wenn Deine Linkquellen an "Kraft verlieren" oder Du generell Links verloren hast oder Google seinen Algo angepasst hat oder aber wenn Du diverse "Black-Hat-Techniken" nutzt - dann bekommste aber nen grauen Balken ;-)

PR ist aber auch egal - das war früher mal wichtig - heute ist das nur noch ein optisches Rudiment.

Gruß Matthias

@Matthias
Welches Statistik-Tool verwendest du denn?

Hallo Toni,

das Stastistik-Tool ist noch aus meiner SEO-Spam-Zeit und wurde vom damaligen Coder, der unsere ganzen Scripte geschrieben hat, zusätzlich angefertigt. Das hat nicht einmal einen Namen und ist schon ziemlich "in die Jahre gekommen". Es gibt heute sicherlich wesentlich bessere und umfangreichere Statistik-Tools aber ich nutzte das schon so lange und möchte das ungern aufgeben. Die Macht der Gewohnheit eben. ;-)

Ich habe aber zwischenzeitlich schon mit jemandem gesprochen der sich sehr gut mit Varnish auskennt und derjenige hat mir an einem Beispiel gezeigt wie man diverse (dynamische) Pfade per VCL vom Caching ausschließt. Ich habe aber Varnish seitdem noch nicht wieder installiert - somit konnte ich das Gezeigte noch nicht ausprobieren bzw. umbiegen.

Das werde ich aber, wie schon erwähnt, bei Gelegenheit mal machen.

Der Server läuft ja auch (ohne Varnish) noch sehr gut und kam noch nie an seine Leistungsgrenze.

Abendliche Grüße
Matthias

Ich bin von der ganzen Cloudisierung nicht überzeugt. Für einen Dienstleister der Hosting anbietet oder Lösungen die Hosting beinhalten (Free-Blogs und dergleichen) mag das eine nette Geschichte sein um eine recht umfangreiche Infrastruktur abzubilden, erweiterbar zu erhalten und auch in Bezug auf internationalen Traffic auf unterschiedliche Datacenter zu verteilen.

Die Vielzahl aller Websites aber hat sprachabhängig einen eher lokalen Bezug und braucht nicht wie ein Baby-Facebook regelmäßig zusätzliche Leistung. Ein gängiger Root-Server ist derzeit sowohl leistungsfähiger, mit mehr Reservern ausgestattet und dabei noch günstiger als eine relativ kleine EC2 Instanz.

Und wenn das Ganze wächst, ist ja mitnichten so, dass ich meiner EC2 Instanz gegen ein entsprechendes Entgelt immer weiter Ressourcen zuschustern kann. Amazon arbeitet da auch mit Standard-Hardware und wenn die Instanz die Kapazitätsgrenze erreicht, muss ich eben zusätzliche Instanzen buchen und mir überlegen wie ich Dienste auf die Instanzen verteile. Das ist bei Root-Servern ebenso, sie bleiben aber leistungsfähiger und günstiger.

M.E. lohnt sich EC2 nur dann, wenn von vornherein bereits die Infrastruktur auf Wachstum ausgerichtet wird, damit ich wenn es soweit ist relativ unproblematisch neue Instanzen integrieren kann. Bis dahin muss sich das Ganze aber auch kostentechnisch rechnen.

Vllt. sehe ich das aber auch zu eingeschränkt. Die Cloud-Spezis mögen mich nötigenfalls verbessern.

Oder du wirst runtergestuft, wenn du DoFollow-Links verkaufst ;)

Da hast Du natürlich vollkommen recht. Auch da kann es zum PR-Verlust kommen.

Sonnige Grüße
Matthias

Spät aber immerhin, danke auch für deine Antwort noch, Alexander.