Performance Optimierung

Hallo Roavei,

man muss zuerst wissen, wo deine Webseite läuft - im shared Hosting kann es je nach Anbieter vorkommen, dass deren Server ausgelastet ist. Probiere unter "Leistung" im Adminbereich (admin/settings/performance) die Einstellungen zum Cache. Die erste Optimierung ist meiner Meinung nach der richtige Provider.

Mit vielen Modulen habe ich bisher noch keine Probleme gehabt.

Grüße

Richy

hallo
Also ich befinde mich mit meiner Seite auf "Siteground".
Danke, die Option mit dem Cache ist mir bereits bekannt... gibt es sonst keine Möglichkeit zur Optimierung?

Hallo,

"Siteground" kenne ich nicht, aber habe den Anbieter überflogen. Es gibt noch verschiedene Cache-Module; die zum Teil erst in Verbindung mit APC, Memcache oder eAccelerator Sinn machen.

http://drupal.org/project/authcache - bietet verschiedene Cachemöglichkeiten an, ob Datei, Datenbank oder den o. g. php-Erweiterungen. Dabei muss die settings.php angepasst werden.

http://drupal.org/project/boost - auch eine Variante, aber dieses Modul kenne ich nicht.

Ansonsten gibt es auf http://drupal.org/node/326504 tiefergehende Informationen zum Thema.

Ich hoffe das hilft weiter. :)

Grüße

Richy

Hallo,

wäre vielleicht gut, wenn Du uns Deine Website nennen würdest, dann kann man besser helfen.

Schau Dir zum Beispiel mal dieses Tool an http://tools.pingdom.com/ oft kann man die Übertäter damit relativ schnell lokalisieren...

Drupal an sich ist nicht langsam, meist sind es wie Du geschrieben hast die vielen Module oder große Bilder bzw. schlechter Code in CSS oder Theme

*************************************************************************************************

Ich würde an deiner Stelle auch erstmal schauen was alles vom Start weg geladen wird. Ich habe mich in den letzten Wochen fast nur damit beschäftigt meiner Seite einen Performance-Schub zu verpassen. Die eigentlichen Module sind meist gar nicht so das Problem, sondern das etliche Module Javascript und Bilder ohne Ende laden. Dort würde ich an deiner Stelle als erstes ansetzen. Performancekiller sind auch fast alle Editoren, da diese viel Javascript mitbringen. Nimm den BUEditor, welcher auch hier auf Drupalcenter verwendet wird. Der ist echt gut und kein Performancefresser. Analysiere deine Seite damit: http://www.websiteoptimization.com/services/analyze/ und folge den Tipps(einen CSS Sprite Generator findest du hier). Für Grafiken und Icons nimm einen Kompressor und jage sie durch(PNG/JPG Kompressoren gibt es mehrere gute).

Boost kann ich dir empfehlen, aber erwarte dir nicht zu viel davon(eigentlich von keinem Cachemodul). Javascript und CSS sollten komprimiert und jeweils als eine Datei geladen werden. Schau mal bei dir in der page.tpl.php nach, wo <?php print $scripts; ?> geladen wird. Ist es ziemlich am Anfang, dann setze es nach unten(vor /html).

ich danke euch dreien für eure tipps und links :)

ich werde mich da mal durcharbeiten und schauen was ich optimieren kann. habe schon was interessantes rasugefunden: das laden aller bilder auf der seite dauert laut durch websiteoptimization.com bei einer 1.44Mb - Leitung ca. 11sec!!
werde sie mal komprimieren und schaun ob ich noch ein paar sprites einabauen kann.

falls ich nachdem, ich mich da durchgearbeitet habe noch immer nicht zufrieden bin mit dem ergebniss, dann werde ich euch mal den link geben und schaun ob ihr noch irgendwas findet.

schönen sonntag wünsch ich euch noch
lg Ripei

CacheRouter

Eine Frage - wann weiß ich, dass dieses Modul funktioniert? Nachdem ich die settings-php angepasst habe?
Ist es außerdem sinnvoll boost und cacherouter gleichzeitig zu installieren? Wenn nicht, welches von den beiden ist dann eher zu empfehlen?

So einfach ist das leider nicht, da cacherouter mehrere Module unterstützt(und für ein par davon darfst du am Server Hand anlegen).

Boost ist sinnvoll, da du so mit statischen Seiten arbeitest. Dadurch erreichst du schon einen kräftigen Performance-Schub. Die meisten Module, welche Cacherouter unterstützt, nützen nur bei sehr großen Datenbanken und sehr hohem Traffic etwas(bin da auch noch am testen, lesen und spielen). Ich würde an deiner Stelle wenn, dann nur Boost einsetzen. Wie lange lädt denn deine Seite jetzt und auf wieviel KB hast du deinen Code heruntergedrückt? Wieviele http Requests hast du?

gruß

Wenn die Seite danach schneller ist, hast du es richtig eingerichtet.

Wie Tom schon anmerkte unterstützt Cacherouter mehrere Backends (Datenbank, APC, Memcache, ..) um Caching zu implementieren.

Ob Memcache oder Boost besser ist, muss jeder anhand seiner laufenden Systemparameter selbst entscheiden. Ohne gescheites Monitoring ist das mehr oder minder ein Ratespiel.

Memcache kann man einsetzen, wenn man für die entsprechend oft abgefragten Datenschnipsel ausreichend RAM zur Verfügung hat, den man dem Rest des Systems fortan vorenthalten kann. Bei ausgelagertem DB-Server bietet sich Memcache zudem an, weil es die schiere Menge an DB-Abfragen und den damit einhergehenden Overhead für Netzwerkverbdindungen zum DB-Server signifikant verringert. In der Praxis dürften hier allein etwa 85% der Zugriffe abgefangen werden können, die sonst auf die internen Cache-, Session und Variablen-Tabellen gehen. Dies sind oftmals aber nicht die Abfragen, die Performance kosten, das hängt aber stark vom Einzefall ab.

Ansonsten gehen File-Caching (Boost) und Speicher-Caching (Memcached) auf unterschiedliche Datenpfade. Im Worst Case auf einem Alles-in-einem-Server kann Boost bremsen, wenn das Dateisystem vom OS nicht ausreichend gecached werden kann und die Prozessoren aus ihrer Sicht stundenlang darauf warten müssen, dass die Platten eine kleine Datei nach der anderen einlesen. Über die Platten müssen dann nicht nur die PHP-, JS-, CSS- und sonstige Dateien geliefert werden, sondern es werden zusätzlich auch noch die statischen HTML Dateien gelesen und geschrieben.

Memcache hat hier deutliche Vorteile, weil Seek-Times im Zehner-Nano-, statt Milisekunden-Bereich liegen und Datentransferraten zwischen CPU und RAM mal wenigstens bei Faktor 10 bis 100 liegen. Grundvoraussetzung ist aber, dass wenn der Webserver an seinen konfigurierten Grenzen für max. Prozesse operiert, das System nicht anfängt auszulagern. Also muss man mal den Worst-Case durchrechnen, was in einem solchen Fall Webserver, System und DB an RAM brauchen. Was dann über ist kann man mal zu einem größeren Teil für nen Memcached abknapsen.

Hier geht aber wie gesagt nix ohne Monitoring um später nachzujustieren und seine Überschlagsrechnungen auf die Probe zu stellen und etwas Kenne vom Apachen, MySQL, etc.

Patentlösungnen gibt es keine.

P.S.:
Wenn ich rausbekommen habe, wie man sich für so ne Aktion qualifiziert, schaue ich mal, ob ich für die DC Paris ne Präse zusammen bekomme, die für verschiedene Zielgruppen mal die Möglichkeiten der Analyse und Optimierung umreißt. Könnte man ein schönes begleitendes PDF zu stricken...

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

hallo...
danke für eure kommentare und anregungen..

habe jtzt mal das boost modul ausprobiert; ein traum... alles ist in null,nichts da :)
problem ist nur, dass meine lieben angemeldeten user nichts davon haben... und das wird sich mit einem cache modul wahrscienlich auch nicht ändern lassen oder?

@tom: ich habe bis jetzt hauptsächlich mal geschaut, dass ich die bilder komprimiere, und die scripts im template geb ich erst am ende aus... jo und sonst werd ich mal weiter schauen, ob sich noch was machen lässt...

bzgl. http-request und code größe... die ist noch ziemlich gleich - wüsste nicht wie ich die verkleinern könnte.

Wenn deine eingeloggten User nicht andere (mehr und größere) Bilder zu sehen bekommen als anonyme Benutzer, kann das logischerweise nicht der Bottleneck sein.

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

welche Module laufen denn bei dir? Wieviel RAM steht dir zur Verfügung? Hast du Zugriff auf den Server?
Es vertragen sich auch nicht alle Module miteinander und können deine Seite unter Umständen richtig lahm legen. Manche lassen auch nach Deaktivierung/Deinstallation ihren Müll in der Datenbank und lassen die Seite zum Krückstock werden. Ich habe das jetzt bei mir schon ein par mal durch. Kannst es ja mal mit php Caching probieren, wenn du genügend RAM hast. APC im Zusammenspiel mit Cacherouter kann ich dir da nicht empfehlen, wenn du mit Sections arbeitest. Das hat bei mir die Arbeit vom Section Modul lahm gelegt.(Kann bei mir allerdings auch eine falsche Einstellung von APC gewesen sein. ich war dann zu faul den Fehler zu suchen.) Du kannst es aber auch so laufen lassen und dir passend einrichten, ohne dass das Cachrouter Modul seine Finger im Spiel hat, oder ein anderes PHP Caching Modul nehmen.
Kennst du dich mit Servern aus? Wenn nicht, dann lasse auf jeden Fall die Finger von dem Server, wo du jetzt deine Seite hast und richte dir zu Hause erstmal einen lokal ein und teste dort, bevor du dir deinen Live-Server zerschießt. Ist eh besser, wenn du dich damit gründlichst beschäftigst, zwecks Sicherheit(und Performance). Du kannst so eine Menge RAM einsparen, da du etliches was normale Server im Hintergrund laufen lassen(ist wirklich ziemlich viel Müll bei den meisten Hostern) einsparen kannst und dir nur das absolut nötigste installierst. So Sachen wie Plesk, Confixx und Konsorten brauchst du nicht wirklich und rauben dir nur Speicher(und Nerven)(sind außerdem zusätzliche Angriffspunkte). Der einzigste Nachteil ist dann, das deine Heimat für einige Zeit die Shell ist. Wenn du dir alles zu Hause eingerichtet hast, mache ein Image. Dann kannst du anfangen und experimentieren. Wenn du damit fertig bist, fängst du mit der Datenbank an. Ich empfehle dir dafür erstmal den hier als kleine Hilfe.

hast du einen Link zu deiner Seite? dann schaue ich sie mir mal an.

gruß tom

Plesk / Confixx / etx. sind in aller Regel unkritisch, da sie über den normalen Webserver des Systems laufen. Greift keiner drauf zu, brauchen sie auch keine Ressourcen (wie bei jeder anderen auf dem Server befindlichen Website auch). Das bischen Cron das die machen fällt auch nicht ins Gewicht.

Bei Systemen wie ISPConfig 2 (ab der 3er läuft ISPC auch über den System-Indianer), Webmin, etc. werden auch kaum Ressourcen benötigt und wenn sie nicht gebraucht werden, werden sie ggf. eh vom System ausgelagert.

Blinder Aktionismus ist nicht zielführend. Man muss schon ein wenig vom System verstehen um eine Idee, oder zumindest ein Bauchgefühl zu entwickeln, welche Maßnahme etwas bringt und welche reine Zeitverschwendung ist. Dazu muss man aber auch wissen welche Eckdaten man zur Beurteilung benötigt, wie man an diese herankommt und natürlich muss man sie lesen können. Da hilft nur viel lesen, denn die Materie ist schon recht komplex.

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

Plesk ist doch eigentlich eine eigene Apache Instanz und frisst RAM(zumindest die ständig geladenen Dienste). Und durch die laufenden Crons von Plesk und Co können die Kiste schon ab und zu in die Knie zwingen(war bei mir so. hatte aber auch keine großen Ressourcen zur Verfügung. 128MB). Außerdem ist es eine zusätzliche Sicherheitslücke. (Brutforce, etc)

128 MB... das taugt bestenfalls für statische Seiten.. unter 4 GB miete ich nichts neues mehr an und auch die ältesten Möhren im Fuhrpark wurden auf 2 GB aufgerüstet.

Was man bei der Wahl des Hostings / (v)Servers liegen lässt, holt man durch Optimierung nicht mehr raus, schließlich muss für den Worst Case vorsorgen, braucht also im Normalbetrieb Reserven um Lastspitzen bedienen zu können. Wenn ich aber schon alle Register ziehen muss um überhaupt im Normalbetrieb ein halbwegs erträgliches System vorzufinden, muss (!) ich upgraden.

Ist zwei oder drei Wochen her, da nahm ich mal auf Anfrage den vServer von wem in Augenschein, wo Drupal mal gar nicht aus dem Quark kam. 1 Core, 2 GB RAM - daran lag es nicht. Aber in der Grundinstallation war der Query Cache in MySQL nicht aktiviert - bei ner teils dreistilligen Zahl Querys pro Seitenaufruf natürlich tödlich. Das brachte es dann letzen Endes aber auch nicht. Keine Ahnung wie die (ist ein großer bekannter deutscher Hoster) die vServer technisch realisieren, aber die Möhre wartete sich bei Zugriffen auf die Platten zu Tode. Die gleiche Installation auf einem meiner alten Server (Single Core, 2 GB RAM, also vergleichbare Specs, allerdings mit gewisser Grundlast vornehmlich durch Mail), der gar nicht speziell auf Apache / MySQL optimiert ist und schon fluppte das Ding halbwegs.

Etwa zur gleichen Zeit las ich bei den 2Bits einen Use Case, wo ein Kunde ankam, der bereits separate vServer für Web- und DB-Server angemietet hatte (seltsame Konstellation, aber naja) und sich über die Performance beklagte. Was kam raus? Die virtualisierte Netzwerkschnittstelle war vom Hoster auf 10 MBit/s gesetzt, um für die vServer auf einer physischen Maschine garatierte Bandbreiten zu haben (auch bei Vorhandensein von 1 GBit Netzwerkkarten wie sie mittlerweile Standard sind ist die INfrastruktur meist dennoch nur mit 100 MBit Technik bestückt). Nun stelle man sich lauter viele DB Abfragen vor (und sei es nur um den standardmäßigen DB Cache von Drupal auszulesen und zu setzen), die sich über ne 10 MBit Leitung quer durch eines dere mehrere Rechenzentren zum DB Server und zurück quälen - das laggt ohne Ende und das sogar ohne Last zu erzeugen (außer vielleicht im Frontend, weil die Leute aus Ungeduld ständig nen Reload machen).

Wenn ich mir natürlich nur nen C64 anmiete, kann ich auch mit noch so viel Tuning keine Klimasimulation drauf laufen lassen, deren Ergebnisse irgendwer von uns zu Lebzeiten noch zu Gesicht bekäme. Bei vServern kommt oft erschwerend hinzu, dass man nicht genau weiß was denn tatsächlich an Performance vom Host-System hängen bleibt (s.o.).

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

Die 128MB Gurke war damals auch extrem dumm, aber trotzdem ausreichend für das was lief. Wenn man da was laufen lassen will, muß man die Kiste halt nackt halten und alles unnötige killen um so viel wie möglich RAM frei zu bekommen. Die meisten mieten sich auch keinen eigenen Server an und holen sich einen VServer, da sie denken, das es vollkommen ausreichend ist, wenn sie die Eckdaten lesen. Das sie sich aber mit etlichen anderen die Leitung/Platten/RAM/Prof teilen realisieren sie zwar, aber nicht was es für Auswirkungen haben kann. Mittlerweile bin ich so blöd auch nicht mehr. Jetzt habe ich auch einen eig. Server mit 4GB RAM, halbwegs ordentlichen Prof + 2 Platten im Raid 1 Verbund und keiner gedrosselten Leitung. Verwaltungssoftware setze ich aber alleine aus Sicherheitsgründen(nicht nur.) auch nicht ein.

habe jetzt auch etliche der großen durch -und bin bedient.

gruß tom

also folgende module laufen bei mir momentan:

• ACL
• Advanced Forum
• AJAX Comments
• Author Pane
• Content Construction Kit
• Content Profile
• Custom Breadcrumbs
• FCKeditor
• Flatcomments
• Formfilter
• Forum Access
• Image
• IMCE
• jQuery plugins
• jQuery Update
• Javascript Tools
• Mollom - wird wahrscheinlich noch deaktiviert werden
• Panels
• Profile Complete Percent
• Privatemsg
• PROG Gallery
• Quote
• Shoutbox
• Smileys
• Subform Element
• Token
• User Points
• User points Nodes and Comments
• Views
• Views Slideshow
• Web File Manager - gerade am testen
• Web Links
• Workflow

da die seite bei einem shared host läuft hab ich 96MB RAM zur Verfügung und auch keinen Zugriff auf den Server.
die seite wird ein upgrade von d5 auf d6 und ist momentan grad im aufbau: *url gelöscht* (info: js und css aggregator sind noch nicht aktiviert da ich gelegentlich noch am theme arbeite)

jop. dat is sehr, sehr langsam. 96MB ist def. viel zu wenig. Da läuft Drupal vlt. mit Grundausstattung und ein par Modulen, aber def. nicht so mit der "Masse" von Modulen. Gerade mal einen Ping gesendet: 200ms. uh... Das Bild auf der Startseite hat 217BK. Das ist viel zu viel. Das kannst du auf 35-45 KB drücken. Denke mal, dass das bei deinen anderen Bildern auch so ist. Bei dem was du mit der Seite realisieren möchtest, bleibt nur ein Wechsel auf etwas größeres, schnellers.

Was zahlst du jetzt? Für 25 Euro im Monat bekommst du schon einen Root mit 1GB RAM und einer 100MBit Leitung. Schau mal hier. Sind nicht gerade die besten, aber für dein Projekt dicke ausreichend.

Wahrscheinlich liegt eher ein Missverständnis vor und gemeint sind nicht 96 MB RAM, sondern ein PHP Memory Limit von 96 MB.

Nicht eben sinnvoll ist es sich einen Hoster in Texas zu suchen, für eine Seite mit einem sehr starken lokalen Charakter irgendwo aus Österreich. Schließlich müssen die Anfragen über (von hier aus der BRD heraus) wenigstens 17 Hops erstmal ins Rechenzentrum gelangen und von dort über denselben Weg wieder zurück und noch dazu ohne GZip-Komprimierung.. Auf dem Server kommt übrigens auch ein Modul zur Bandbreitenlimitierung (wahrscheinlich in Zusammenhang mit cPanel als Admin-Frontend) zum Einsatz. Ob dieses hier auch mit reinspielt, kann man so ohne weiteres von außen aber nicht sagen.

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

Hallo

Ja da wundert ihr euch zu recht, warum ich einen server in amerika nehme, wenn hauptsächlich von österreich aus leute zugreifen. Der Grund ist schlicht und einfach der Preis: 6$ / Monat sind halt schwer zu schlagen. Und der Support ist 1A, kann nich empfehlen. (soll jetzt keine schleichwerbung sein, sry wenn's so rüberkommt^^)

ups... mein Fehler Alexander liegt richtig 96MB sind das PHP Memory Limit, wieviel RAM mir zur Verfügung stehen kann ich nicht sagen, und ich habs jetzt auf die schnelle auch nicht gefunden.

Die RAM Angabe wirst du bei Shared Hosting auch nicht finden..

Was den Preis angeht halte ich es mit "Man bekommt, was man bezahlt.".
Entweder willst du was was ordnetlich läuft, oder du willst das billigste was du bekommen kannst. Beides bekommt man nicht zusammen.

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

hallo leute

nachdem boost mich eigentlich überzeugt hat, es boost aber nur für annonyme user gibt, möchte ich mich jtzt doch ein bisschen mit authcache beschäftigen. hat hier jemand von euch einen link zu einer guten anleitung bzw. erklärung?
vllt. sogar auf deutsch?

Hallo,

ich habe einen Managed Server bei 1und1 mit 2GB Ram für 69,- EUR pro Monat
Ausserdem habe ich ein kleines Webhostingpaket bei Hetzner für 4.99 EUR pro Monat

Ich habe auf beiden Systemen exakt die gleiche Drupalseite installiert.

Wenn ich auf dem Hetznersystem den eAccelerator aktiviere (bei meinem 1und1 Server nicht möglich)ist das Hetzner System fast doppelt so schnell wie der Server von 1und1.

Da ich Drupal mit nur relativ wenigen Nicht-Core-Modulen (views, cck, imagecache) installiert habe, würde ich die Behauptung in den Raum stellen, dass der eAccelerator einen deutlichen Leistungsschub garantiert.

Gruss Klaus

Kannst du gern behaupten, aber nicht belegen. Vor allem nicht so allgemeingültig.

Auf nem eigenen Server ist man zunächst einmal unabhängig von der Last die andere erzeugen und die man vor allem nicht direkt messen kann. Meist ist auch nicht bekannt auf was für Hardware das Shared Hosting läuft. Konfigurationen beider Mühlen sind auch nicht bekannt, aber erfahrungsgemäß sind die Billig-Managed-Dinger von der Stange übele Karren (gilt oft auch für vServer) wo ein Admin beim Erstellen des Image nichtmal von 12 bis Mittag gedacht hat.

Mal abgesehen davon ist der eAccelerator ein mittlerweile gewissermaßen verlassenes Projekt mit kaum messbarer Entwicklung. Im Netz findest du auch reichlich Quellen, die Probleme (Segfaults des Apache) beim Einsatz des eAccelerators hatten. Das Drupalcenter selbst hatte auch das Vergnügen. Darum beten wir allerorten das APC Mantra, den mit APC ist sowas bis dato noch nicht vorgekommen und es wird aktiv weiterentwickelt.

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

@Alexander
APC habe ich auch laufen. Mich würde deine Meinung mal interessieren, was du von Zend hältst und ob du es schon getestet hast?

Ansonsten kann ich Alexander nur beipflichten. Die Hardware ist nicht zu unterschätzen. Ihr mietet euch "Server"(bewußt in Anführungsstrichchen) und bekommt den letzten Dreck(Stichpunkt VIA Chipsatz, etc...). Das ist aber noch nicht mal das schlimme. Das schlimme ist, das viele Hoster auf Grund des Preisdrucks nicht mal 24 Stunden Platten einsetzen(habe vor ein par Tagen mal einen etwas krasseren Kommentar bei einem recht bekannten Hoster abgelassen und dort konnte die Technikabteilung damit gar nichts anfangen. Da kriegstn Hals!)

Mit Zend sollte es ebenfalls keine Probleme geben. Wäre auch relativ peinlich für Andi und Zeev, wenn dem nicht so wäre.. ;-)

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

ich stör ja nur ungern... ;)
aber hat jemand von euch eine gute anleitung bzw. beschreibung zu authcache zur hand?

Außer der offiziellen Doku zum Modul ist mir nichts bekannt. Sollten darüber hinaus Fragen auftauchen, versuchs mal direkt beim Autor, bzw. hier: http://groups.drupal.org/node/19823

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

hallo tom,
die page.tpl.php so zu ändern (das

entweder die Javascript Datei des Editors in der Page.tpl.php extra im Header laden(hier müßte dann aber auch noch eine Anweisung erfolgen, dass die JS Datei regulär nicht nochmal geladen wird bei print $scripts. Habe aber jetzt keine Ahnung wie....) , oder du nutzt einen anderen Editor(z.b.: BUEditor).

gute idee mit dem extra laden, ich weiss aber leider auch nicht wie (bin überhaupt kein php crack). bueditor will ich gerne nehmen, aber der spinnt bei mir (siehe anderes forum). er löscht alle zeilenumbrüche. habe schon etliches mit den filtern versucht, aber der zeilenumbruchkonverter lässt sich nicht erweichen (egal, ob an erster stelle der filter oder alleine ohne andere oder wie auch immer) auch nur einen zeilenumbruch zu erstellen.

naja, danke für den tip.
gruß
stefan

Das im Header einfügen:
<script type="text/javascript" src="pfad zur .js des editors"></script>

Problem: Die .js wird nochmal bei print $scripts geladen. Man kann zur Not auch die .js über das Modul ausschließen, aber das ist nicht die schönste Lösung. Vielleicht kann da jemand anderes mit einer schöneren Lösung helfen...

das funzt bei mir irgendwie nicht.
dennoch danke für die hilfe.
fällt dir irgendwas zum bueditor ein? vielleicht ist meine config hinüber? aber ich habe ihn auch schon mal rausgeworfen, neu von drupal.org heruntergeladen und wieder installiert. hat auch nichts geholfen. die zeilenumbrüche sind alle weg.
gruß
stefan

Ich selbst nutze eaccelerator in Verbindung mit dem zend Optimizer. Daher nun die Frage:

Macht es dann überhaupt noch Sinn, die drupal-eigenen cache-Möglichkeiten einzuschalten oder ist das eher kontraproduktiv, weil sie sich die verschiedenen Tools in die Quere kommen können?

Oder gibt es spezielle drupal-Module, die eaccelerator bei der Arbeit unterstützen. Ich habe mir einige Performance-Übrsichten im Web angeschaut. Dort stand dann in den meisten Fällen, dass zend-Optimizer in Verbindung mit eaccelerator den grössten Speedschub geben. Nirgendwo stand aber etwas darüber, ob trotzdem weiterhin die drupaleigenen cache-Möglichkeiten quasi als Zusatz aktiviert werden sollen.

by the way: Ich kann wirklich jedem empfehlen, eaccelerator zu installieren. In den meisten Fällen wird es die Geschwindigkeit der kompletten Seite verdoppeln bis verdreifachen.

Grüße
monk77

Ja, macht Sinn, weil die Caches unterschiedliche Aufgabengebiete haben. Es würde auch keiner auf die Idee kommen keinen Cache mehr in Festplatten einzusetzen, weil der Hauptprozessor ja schon einen hat.

Vom eAccelerator rate ich übrigens ab. Zum einen wird er afaik nicht weiterentwickelt, zum anderen kommt es mit ihm gerne mal zu Abstürzen des Webservers. Stattdessen lieber den APC benutzen, der als PECL Extension für PHP daherkommt. Mit diesem gibt es keine solchen Probleme.

PHP Bytecode Caches wie eAccelerator, Zend Optimizer, APC und wie sie nicht alle heißen speichenr den beim Aufruf eines Skripts nach dessen letzer Änderung vom PHP Parser generierten Bytecode. Man spart fortan also das Parsen des Skripts. Performanceverbesserungen sind sehr unterschiedlich, je nach Art der Anwendung. Wenn das Parsen bislang nur 5% der Gesamtausführungszeit (inkl. Datenbankabfragen) ausmachte, macht sich der Wegfall entsprechend auch nur mit max 5% Performancegewinn bemerkbar.

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

Danke für Deine Antwort.

Da magst Du Recht haben. Aber die meisten Performance-Tests im Web sprechen eine deutlichen Sprache in Richtung eaccelerator. Ich hatte bisher noch keine Probleme mit ihm und die von mir getesteten Weblösungen (drupal, wordpress, buddypress, Simple Machine Forum usw) wurden speedtechnisch wirklich verdreifacht. Vor allem bei buddypress war der Zuwachs an Geschwindigkeit mehr als deutlich. Vorher war das System richtig träge. Als ich aber den eaccelerator eingeschaltet hatte, konnte ich die Seiten beim Testen quasi in Echtzeit über den Bildschirm fliegen lassen.

Grüße
monk77

Google nach "eaccelerator segfault" und schwupps hast du genug Leute mit Drupal und Problemen. Das DC hatte nach dem Umzug auf nen eigegen Rootie 2008 auch eine Weile strage Phänomene die darauf zurückzuführen waren.

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de

supi. Jetzt habe ich APC installiert, alles korrekt in die php.ini eingebunden, gleichzeitig eccelerator erstmal aus der php.ini rausgenommen, den apache neugestartet und erhalte zum Dank einen weissen Screen, der so leer ist wie die Wüste Gobi.

Und das Error-Log magste uns nicht vorlesen?

--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!

webseiter.de