Drupal auf Strato Premium XE sehr langsam
am 03.11.2006 - 16:18 Uhr in
Hallo,
hat jemand Erfahrungen mit Drupal und Strato? Ich habe schon von PowerWeb auf Premium upgraden müssen, damit Drupal überhaupt läuft (PowerWeb gewährt zu wenig Arbeitsspeicher). Nun ist es aber immer noch sehr langsam, trotz aktiviertem Caching. So dauert der Aufbau einer recht einfachen Seite bei Strato 6 Sekunden und angemeldet sogar 12 Sekunden. Lokal mit MAMP dauert ein Besuch der gleichen Seite als Gast 1,4 Sekunden und angemeldet auch nur 1,6 Sekunden. Die Bilder liegen schon im Cache vor.
Da der Konfigurationsbereich von Strato ebenfalls nicht sehr flott ist, vermute ich fast, das die Strato-Server einfach zu stark überlastet sind.
Gibt's vielleicht irgendwie Tricks, um die Sache weiter zu beschleunigen. Ich habe schon alle möglichen Module deaktiviert und auch mal das Devel-Modul aktiviert. Dieses zeigt immer recht hohe Ausführungszeiten von get_cache, aber das ist ja nicht representativ, da ich ja die Werte nur als Admin sehe, wo eh nicht gecachet wird.
Würde es was bringen, statt MySQL 5 auf MySQL 4 zu setzen?
Ich mache mir mittlerweile Sorgen mit Drupal auf das falsche Pferd gesetzt zu haben. Von Strato kann ich jetzt erstmal nicht weg, was ja schon wegen dem fehlenden mod_rewrite wurmt.
Tekl
- Anmelden oder Registrieren um Kommentare zu schreiben
Ich würde mir eher Sorgen
am 03.11.2006 - 17:31 Uhr
Ich würde mir eher Sorgen machen, mit Strato auf das falsche Pferd gesetzt zu haben.
Bisher hatte ich so ein Problem bei keinem anderen Provider!
Habe bei einem Setup auf Strato-Webspace das selbe Problem, den Arbeitsspeicher aber manuell erhöht (php.ini).
Kann mir nicht vorstellen, dass eine Wechsel von MySQL 4 auf 5 was bringt, höchstens insofern, dass der Datenbank-Server ein anderer und vielleicht schneller - respektive nicht so überlastet - ist.
vg
--
sanduhrs - drupalcenter
--------------------------------
http://erdfisch.de
--
sanduhrs · Stefan Auditor · Drupalcenter
http://drupal.org/user/28074 · http://association.drupal.org/user/646
Ich habe das gleiche Problem
am 03.11.2006 - 23:42 Uhr
Ich habe das gleiche Problem aber es laufen auch andere Scripts welche mit php zu tun haben sehr sehr langsam. Der Support weiss bescheid und mal sehen was dort geschieht. Es kann auch daran liegen dass sie gerade die ganzen Server umrüsten . . .
Sagen die das nicht immer? ;-)
am 04.11.2006 - 00:00 Uhr
Ich durfte neulich ein klein wenig "Strato" erleben und habe - wie immer - Host Europe empfohlen.
--------------------------------
http://www.autokauf-und-recht.de
--------------------------------
Re: Ich würde mir eher Sorgen
am 04.11.2006 - 01:15 Uhr
Vielen Dank für eure Antworten.
IHabe bei einem Setup auf Strato-Webspace das selbe Problem, den Arbeitsspeicher aber manuell erhöht (php.ini).
Wie das? Ist doch nur shared Webhosting? Habe ich da Einfluss auf die php.ini?
Tekl
--
Tekl
Ja, Du kannst bei Strato die
am 04.11.2006 - 08:23 Uhr
Ja, Du kannst bei Strato die komplette php.ini durch eine eigene ersetzen indem Du eine eigene schreibst und diese in das gewünschte Verzeichnis hochlädst.
vg
--
sanduhrs - drupalcenter
--------------------------------
http://erdfisch.de
--
sanduhrs · Stefan Auditor · Drupalcenter
http://drupal.org/user/28074 · http://association.drupal.org/user/646
Dabei hat Strato doch extra
am 04.11.2006 - 09:18 Uhr
Dabei hat Strato doch extra 'Performance Boost' im Premium Paket... hahaha :)
Ich war auch mal bei Strato. Und auch mal bei 1&1. Die bieten jede Menge tolle Features, die keiner braucht, aber die trotzdem einen Haufen Geld kosten. Die Performanz ist zum Kotzen und beim Service gehst du unter. Wenn du mal dieses Forum durchsuchst, es gibt ständig Leute, die mit Strato Probleme haben. An deiner Stelle würde ich mal die Webhostlist durchgehen und schauen, obs für deine Ansprüche nicht was anderes gibt.
Ich bin mit meiner (kleinen) Seite bei einem absoluten Billigprovider untergekommen, bekomme dort alles was ich brauche und vor allem 1a Service. Die Performanz ist nicht erste Sahne, aber auch keineswegs schlecht, und so wenig wie ich dafür zahle ist die Erwartungshaltung auch entsprechend gering. Bei Strato hab ich mich dumm und dämlich gezahlt und nichts an Leistung bekommen.
Bei hohen Ansprüchen, für eine große Seite, und wenn du das Know-How und die richtigen Freunde hast, stellt euren eigenen Server irgendwo hin und teilt euch die Kosten. Das ist nicht mehr so unbezahlbar wie früher, und man hat vollste Kontrolle über alles.
Re: Drupal auf Strato Premium XE sehr langsam
am 04.11.2006 - 18:30 Uhr
hat jemand Erfahrungen mit Drupal und Strato? Ich habe schon von PowerWeb auf Premium upgraden müssen, damit Drupal überhaupt läuft (PowerWeb gewährt zu wenig Arbeitsspeicher). Nun ist es aber immer noch sehr langsam, trotz aktiviertem Caching.
Ich habe mehrere dedizierte Server bei Strato, und die sind alle sehr flink. Nur Drupal kriecht eben vor sich hin. Mein Drupal 4.7 läuft auf einem "Strato High End Server SR", auf dem auch ein Mediawiki und Gallery2 installiert sind; letztere liefern akzeptable bis gute Reaktionszeiten (sprich: man kann halbwegs angenehm damit arbeiten, d.h. die Seiten werden in maximal 1-2 Sekunden ausgeliefert), während die Performance von Drupal absolut indiskutabel ist; ohne Last brauchen einzelne Seiten 15-20 Sekunden, wenn noch eine Handvoll (anonyme) Benutzer unterwegs sind, kann man schon mal zwei Minuten auf eine Seite warten.
Mit Strato hat das m.E. nichts zu tun, weil eben Mediawiki und Gallery2 auf derselben Hardware durchaus rund laufen - und das alles sind ja klassische LAMP-Anwendungen. Ich habe auch einen Windows 2003 Server auf ähnlicher Hardware bei Strato, und der ist sowohl performant bei mehreren hundert parallelen Benutzern als auch bombig stabil. Hardware- und netzseitig sehe ich bei Strato jedenfalls keinerlei Probleme; anders kann das aber natürlich bei Shared Hosting sein.
Da der Konfigurationsbereich von Strato ebenfalls nicht sehr flott ist, vermute ich fast, das die Strato-Server einfach zu stark überlastet sind.
Keine Ahnung, wie und wo du verwaltet wirst; bei mir laufen die Konfigurationsserver in ganz anderen Subnetzen; auch daraus kannst du m.E. kaum Rückschlüsse ziehen.
Ich habe schon alle möglichen Module deaktiviert und auch mal das Devel-Modul aktiviert.
Nach meinen bisherigen Erfahrungen steckt genau da der Wurm bei Drupal drin: Es gibt keinerlei Qualitätskontrolle bei den 3rd-party-Modulen, und viele davon sind buggy bis zum Abwinken. Die Wechselwirkungen von mehreren solchen Modulen sind dann endgültig vollkommen unkalkulierbar, da hilft nur systematisches Ausprobieren.
Zumindest bei meiner Installation weiß ich mit Sicherheit, dass Drupal erträglich schnell laufen würde, wenn ich _ausschließlich_ die Module aus dem Core verwenden würde - die sind auch stabil und gut durchgetestet, nur könnte ich dann mit Drupal praktisch nichts sinnvolles mehr anfangen.
Ich habe mir mal einen halben Tag Zeit genommen und die Wechselwirkungen meiner Module durchgetestet und alles weggeschmissen, was gravierende Störungen verursacht hat (bspw. nodewords) und nicht absolut notwendig war; damit konnte ich die Auslieferungszeiten einzelner Seiten immerhin von 30-45 Sekunden auf die jetzigen 15-20 Sekunden drücken; noch mehr Module möchte ich aber aus den o.g. Gründen nicht abwerfen, obwohl das sicherlich sinnvoll wäre.
Perspektivisch sehe ich als einzige Möglichkeit, die Hardware massiv aufzurüsten oder Drupal aufzugeben (bei >15.000 Nodes nicht wirklich eine Option); bei welchem Provider das dann geschieht ist ziemlich egal, für mich spricht jedenfalls weder bei der Hardware noch bei der Netzanbindung etwas gegen Strato (wohl aber deren "Support" und Vertragsgestaltungen). Mein Problem bei der Hardwareaufrüstung ist, dass die Drupal-Entwickler leider keinerlei Empfehlungen abgeben, jedenfalls habe ich nocht keine gefunden; wenn ich mir die Setups der größeren Drupal-Sites oder von drupal.org anschaue, wird mir jedenfalls (finanziell) schummerig.
Bei Shared Hosting würde ich mal durchrechnen, ob es sinnvoll wäre, ein Paket für den Apache und ein weiteres für MySQL anzumieten; falls die Server wirklich überlastet sind würde das natürlich nicht helfen, wohl aber, wenn die Hosting-Pakete lediglich unterdimensioniert wären.
Ich mache mir mittlerweile Sorgen mit Drupal auf das falsche Pferd gesetzt zu haben.
Das ist immer eine Frage der Optionen; ich bin beispielsweise heilfroh, nicht auf Typo3 gesetzt zu haben, wo anscheinend der Core selbst gammelig ist; bei Drupal ist wenigstens der Core stabil und man muß darauf hinarbeiten, dass eine Qualitätssicherung (und ein vernünftiger Deinstallationmechanismus) bei den Modulen eingeführt wird. Bis dahin muß man halt versuchen, möglichst konstruktiv auf die Modulentwickler einzuwirken, das ist natürlich zeitaufwändig und leider nicht immer wirklich produktiv (die amazontools sind beispielsweise seit Monaten ein einziges Desaster).
Re: Ja, Du kannst bei Strato die
am 06.11.2006 - 10:12 Uhr
Erstmal vielen Dank für die vielen Antworten. Ich kann unserem Kunden nicht ständig Serverwechsel empfehlen. Ich musste ihn ja schon zu Premium XE überreden. Da zog dann dass Argument, dass es mit einigen Mausklicks erledigt ist.
Ja, Du kannst bei Strato die komplette php.ini durch eine eigene ersetzen indem Du eine eigene schreibst und diese in das gewünschte Verzeichnis hochlädst.
vg
Also einfach in irgendein Verzeichnis? Muss es eine komplette php.ini sein, oder reicht einfach eine Datei wo ich "memory_limit = 12M" reinschreibe?
--
Tekl
Ja, einfach in irgendein
am 06.11.2006 - 10:25 Uhr
Ja, einfach in irgendein Verzeichnis. Für dieses und alle Unterverzeichnisse gelten dann die Einstelleungen - wie bei einer .htaccess. Du musst eine komplette php.ini bereitstellen, nur das ändern einzelner Werte ist - anders als bei der .htaccess - nicht möglich.
vg
edit: Achso, bitte beachte, dass das ändern der php.ini auf Deine Verantwortung passiert. Anbei die E-Mail vom Strato-Support:
Bitte beachten Sie, dass CMS in aller Regel sehr hohe Systemanforderungen stellen, die durch Ihr Webhostingpaket
eventuell nicht erfüllt werden.
Das memory_limit für PHP liegt tatsächlich bei allen unseren Webhostingpaketen, die PHP unterstützen beispielsweise bei 8 MB.
Prinzipiell können Sie einige PHP-Grundeinstellungen selbst ändern, indem Sie eine php.ini auf Ihrem Webspace ablegen.
Die für die Nutzung einer php.ini notwendigen Kenntnisse können wir jedoch nicht vermitteln.
Für die Änderungen übernehmen Sie die Verantwortung, Support können wir dafür nicht leisten.
Die Nutzung einer php.ini erfolgt also komplett auf Ihre eigene Verantwortung. Bringen Sie nicht die notwenigen Kenntnisse mit, dann sollten Sie eine solche Manipulation nicht vornehmen.
Fehlfunktionen sind z.B. bei den STRATO 'CGI' und beim 'Website Configurator' zu erwarten. Treten in diesem Zusammenhang Probleme auf und es befindet sich eine php.ini auf dem Webspace, so können wir z.B. für die STRATO 'CGI' und für den 'Website Configurator' keinen Support leisten.
--
sanduhrs - drupalcenter
--------------------------------
http://erdfisch.de
--
sanduhrs · Stefan Auditor · Drupalcenter
http://drupal.org/user/28074 · http://association.drupal.org/user/646
Hachja... zufriedene Kunden.
am 06.11.2006 - 10:45 Uhr
Hachja... zufriedene Kunden. :-)
Danke für deine Antwort.
am 06.11.2006 - 11:42 Uhr
Danke für deine Antwort. Ich habe mittlerweile festgestellt, dass bei Powerweb XE sowieso schon 20 MB voreingestellt sind und ich habe das auch mit diesem Skript nochmals gegengecheckt. Das sollte also nicht das Problem sein, oder. Ich tippe mittlerweile stark auf ein Problem mit der Datenbank, da ja auch phpmyadmin bei Strato sehr träge ist.
Kann man da noch irgendwie tunen? Gibt es für Drupal evtl. die Möglichkeit den Cache nicht in einer Datenbank ablegen zu lassen, sondern einfach in einem Verzeichnis?
--
Tekl
--
Tekl
Tekl schrieb Kann man da
am 28.12.2007 - 19:41 Uhr
Kann man da noch irgendwie tunen? Gibt es für Drupal evtl. die Möglichkeit den Cache nicht in einer Datenbank ablegen zu lassen, sondern einfach in einem Verzeichnis?
--
Tekl
Diese Frage würde mich auch mal interessieren!
---
www.party-riebel.de
---
Test my Drupal Themes online!
File cache
am 28.12.2007 - 19:54 Uhr
File caching geht mit diesem Modul: http://drupal.org/project/filecache
vg
--
md - DrupalCenter
mdwp* :: Drupal Services
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
Glaub, diese Modul ist fürs
am 28.12.2007 - 20:34 Uhr
Glaub, diese Modul ist fürs Testen ganz gut geeignet: http://drupal.org/project/memcache
Memcache
am 28.12.2007 - 21:19 Uhr
Wie der Name schon sagt ist das Modul allerdings nicht für File Caching, sondern Memory Caching da. D.h. man braucht einiges an Arbeitsspeicher. Außerdem ist das Modul nicht mal so eben installiert ind konfiguriert.
Was willst du damit testen? Dass, Memory Caching schneller als DB-Caching ist?
vg
--
md - DrupalCenter
mdwp* :: Drupal Services
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
Nein so meinte ich das
am 28.12.2007 - 21:29 Uhr
Nein so meinte ich das nicht. Ich wollte ihm das Modul nur noch mal als zusätzliche Möglichkeit nennen.
Seine Daten zu Cachen. Hab mich mit den Feinheiten dieses Moduls nicht auseinandergesetzt, hab auch nicht behauptet das dieses Modul das ist was er sucht.
Also sieh den Beitrag so wie er gedacht ist als kleine Info, die mit dem Thema mehr oder weniger zu tun hat.
Was der Autor der Frage, mit dieser Info anfängt ist ihm überlassen :)
Bei Benutzung eines Shared
am 28.12.2007 - 21:30 Uhr
Bei Benutzung eines Shared Hosting Pakets sind dererlei Gedanken lobenswert, aber in der Regel bringen sie nichts. Der Bottleneck ist die Maschine, die unter der Last der dreiunddrölzig auf ihre laufenden Webpräsenzen ächzt, beeinflussen kann man bestenfalls und in engen Grenzen die Last, die die eigene Site zur Gesamtlast beiträgt.
Entweder wechselt man auf ein Paket bei einem Hoster, wo mehr Leistung drin ist (aber die wenigsten Hoster geben bekannt was für Hardware sie benutzen und wieviele Kunden auf der Maschine liegen und auch dann ist nicht klar wie belastend diese sind). Ein echter Ausweg ist nur ein vServer mit prozentual zugesicherter Leistung, oder eine dedizierte Maschine. Da kann man auch an viel mehr Schrauben drehen...
Optimierung ist nur sinnvoll, wenn der Aufwand den Nutzen rechtfertigt.
--
"Look, Ma, I'm dead!"
Cell, Stephen King
Suchmaschinenoptimierung (SEO) & Drupal
Memcache
am 28.12.2007 - 22:03 Uhr
Wie der Name schon sagt ist das Modul allerdings nicht für File Caching, sondern Memory Caching da. D.h. man braucht einiges an Arbeitsspeicher. Außerdem ist das Modul nicht mal so eben installiert ind konfiguriert.
Was willst du damit testen? Das Memory Caching schneller als DB-Caching ist?
vg
--
md - DrupalCenter
mdwp* :: Drupal Services
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
Ich will damit nichts
am 28.12.2007 - 22:19 Uhr
Ich will damit nichts testen. Ich habe auch verstanden das es nicht für File Caching zu verwenden ist (sagt der Name ja schon...). Ich wollte es wie im letzten Beitrag schon erläutert nur als zusätzliche Info zu deinem Beitrag -> File Caching nennen.
Aber um diese Diskussion zu verkürzen, ignoriere doch einfach meinen Beitrag ;)
md schrieb File caching
am 28.12.2007 - 22:52 Uhr
File caching geht mit diesem Modul: http://drupal.org/project/filecache
vg
--
md - DrupalCenter
mdwp* :: Drupal Services
Erstmal Danke - werde es ausprobieren!
Habe aber parallel dazu dieses Modul http://drupal.org/project/fastpath_fscache getestet. Ihr könnt unten auf meinen Link klicken, da ist das Modul in Aktion.
Es hat mich positiv überrascht. Die Abfragen sind jetzt sehr schnell (leider nur für Gast-User). Der Seitenaufbau war mit tuning zuletzt bei ca. 5-8 Sekunden (Frontpage). Jetzt dürften es 0.5 - 1 Sekunden sein (Bilder dauern länger, da kein imagecache).
Das von dir gepostete Modul werde ich mir morgen genauer ansehen.
---
www.party-riebel.de
---
Test my Drupal Themes online!
Ignorieren
am 28.12.2007 - 23:28 Uhr
Ich will damit nichts testen. Ich habe auch verstanden das es nicht für File Caching zu verwenden ist (sagt der Name ja schon...). Ich wollte es wie im letzten Beitrag schon erläutert nur als zusätzliche Info zu deinem Beitrag -> File Caching nennen.
Aber um diese Diskussion zu verkürzen, ignoriere doch einfach meinen Beitrag ;)
Mein letzter Post in diesem Thread war leider doppelt.
Und - wir versuchen hier keine Beiträge zu ignorieren.
Alles zählt.
Guten Rutsch :-)
vg
--
md - DrupalCenter
mdwp* :: Drupal Services
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
Hallo, ich möchte das alte
am 03.04.2009 - 14:59 Uhr
Hallo,
ich möchte das alte Thema nochmal hervorkramen. Würde sich durch das Update auf die aktuelle Drupal-Version (6.10) eigentlich was verbessern? Man liest ja, dass Drupal schneller geworden sei. Bezieht sich das auch auf Datenbankzugriffe?
--
Tekl
--
Tekl
Auf eine allgemeine Frage
am 03.04.2009 - 15:53 Uhr
Auf eine allgemeine Frage eine allgemeine Antwort: Nein.
Wenn Dach und Fenster undicht, die Wände feucht und die Heizungen defekt sind, bringt es auch nichts sich ne neue Ledercouch ins Wohnzimmer zu stellen.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Suchmaschinenoptimierung (SEO) & Drupal
Hi, der Vergleich ist
am 03.04.2009 - 18:43 Uhr
Hi,
der Vergleich ist seltsam. Es kann ja sein dass in Drupal 4 einfach noch vieles schlecht optimiert war. Denn seltsamerweise wirbt Strato ja damit, dass Drupal unterstützt wird. Evtl. laufen aktuellere ja besser.
--
Tekl
--
Tekl
Besser vielleicht. Aber
am 03.04.2009 - 19:03 Uhr
Besser vielleicht. Aber "besser" lässt viel Raum ;)
Du wirst eh erst auf 5 und von 5 auf 6 upgraden müssen.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Suchmaschinenoptimierung (SEO) & Drupal
Strato ist schon ein Problem...
am 06.04.2009 - 17:32 Uhr
Hallo,
zieh dir doch mal diesen Thread rein...
http://www.drupalcenter.de/node/15393
---
Drupal 6.10 auf http://www.citykirche-schweinfurt.de http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/
---
Drupal 7.x 8.x auf https://www.citykirche-schweinfurt.de und ca. 15 weiteren (Liste auf https://www.kuschelkirche.de/webdesign-und-betreuung )
Drupal und Strato
am 05.05.2009 - 16:57 Uhr
passen einfach nicht zusammen, egal wieviel Zeit vergeht, egal wieviele Updates die bei Strato machen. Ich halte es inzwischen für unlauter, daß Strato angibt Dupal hosten zu können. Fakt ist, daß es nicht geht, bzw. es dem Zufall überlassen ist, ob man den einen guten Tag im Monat erwischt. 12 von 365 ist selbst für Anspruchslose zu wenig. PUNKT!!!