Hallo Gerhard,
bei reinem Webhosting kann man i.d.R. nicht allzu viel selber tun. Was man aber tun kann, ist ab un zu etwas "Datenpflege".
Dazu gehört allem voran:
Insgesamt wären sicher noch mehr Punkte zu nennen, die man auch ggf. im ACP optimieren könnte (und mir spontan nicht einfallen).
Auch Weiterleitungen via .htaccess können zu Verzögerungen im Seitenaufbau führen.
Unterm Srrich kann man selten pauschal sagen, was im Einzelfall wirklich zu Performance-Einbrüchen führt, dazu muss man sich die jeweilige Situation und Umgebungen näher ansehen.
Aber diese wenigen Punkte können schon mal Verbesserungen bewirken.
Das muss ich jetzt mal etwas für mich zerfleddern...
[...] bei reinem Webhosting kann man i.d.R. nicht allzu viel selber tun.
Wir verwenden einige allerdings bereits ältere Optimierungen.
<IfModule mod_headers.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/js
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE image/png
AddOutputFilterByType DEFLATE image/gif
AddOutputFilterByType DEFLATE image/jpg
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE\s7 !no-gzip !gzip-only-text/html
</IfModule>Auch Weiterleitungen via .htaccess können zu Verzögerungen im Seitenaufbau führen.
Gut, aber darauf kann man schlecht verzichten, möchte man halbwegs sauber konfigurierte Adressen. Da wird bei uns jede Menge umgeschrieben, HTTP auf HTTPS, die alte Linkstruktur auf die neue Linkstruktur, die einzelnen Apps, ...
- Datenbank-Tabellen, bei denen das (von der Engine her) möglich ist, ab und zu "optimieren". Der Vorgang entspricht etwa dem "Defrag" von Datenträgern und beseitigt unnötige Überhänge in Tabellen.
Könnte ich durchaus mal anstoßen. Aber bringt das bei der Suite wirklich etwas?
- Keine nicht wirklich erforderlichen Plugins verwenden, nur das Nötigste (auch aus anderen Gründen)
Wir verwenden keine Plugins.
- Werte für das Löschen des Papierkorbs (softgelöschte Einträge) nicht zu hoch setzen, als "ausreichend" würde ich ca. 30 Tage erachten
Wieso denn das?
- Zusätzlichen Code wie JS nur in dem Umfang einsetzen, der wirklich unbedingt benötigt wird. Jedes eingebundene Script "kann" Ladezeiten von Seiten verlängern. "Spielereien" wie z.B. die berühmten Schneeflocken zu Weihnachten sind zwar nett, gehen aber evtl auf die Performance.
Wir verwenden keine eigenen Scripte.
Interessant wäre halt, ob es etwas bringt, den Webhosting-Tarif zu wechseln, denn wir könnten von 1024 MB auf 2048 MB RAM und von 8 Kunden / CPU-Kern auf 4 Kunden / CPU-Kern aufrüsten, auch wenn das gerade was die Prozessorleistung angeht wenig aussagekräftige Werte sind.
Gut, aber darauf kann man schlecht verzichten, möchte man halbwegs sauber konfigurierte Adressen.
Völlig richtig. Es ist ein eigentlich leidiges Thema, aber man kommt nicht umhin.
Auf einem halbwegs leistungsstarken Server fällt das allerdings auch nicht sonderlich ins Gewicht.
Könnte ich durchaus mal anstoßen. Aber bringt das bei der Suite wirklich etwas?
"Ja und nein". Ein Jurist würde sagen "es kommt darauf an...", nämlich auf die Größe der Überhänge und wann man das zuletzt mal getan hat.
Vom Grundsatz hilft diese Pflege in allen Web-Anwendungen, die auf MySQL-Datenbanken basieren und daraus ihre Seiten generieren.
Ich habe mir angewöhnt, das halbwegs regelmäßig (sprich "wenn ich gerade dran denke und halbwegs Zeit dafür habe") durchzuführen und je nach Plattform kann ich tatsächlich auch Performance-Steigerungen im "spürbaren" Bereich feststellen.
Vor allem aber habe ich dadurch praktisch noch nie gecrashte Tabellen gehabt (von denen andere Admins/Betreiber ohne jegliche Pflege öfter mal berichten).
Ich erinnere mich nur an eine gecrashte "Post"-Tabelle vor vielen Jahren, und dort hatte ich die DB vorher nie gepflegt und nur selten mal geprüft. Bis sich die Betreiberin mit "einem Problem" bei mir meldete und der Crash auffiel.
Wir verwenden keine Plugins.
Umso besser. 
Wieso denn das?
Ist nicht gerade der wichtigste Punkt, aber dieser "Datenmüll" bläht ja u.U. die Datenbank nur unnötig auf. Allerdings erzeugt der Papierkorb auch keine eigenen Queries im Betrieb, von daher hast Du recht, das ist nicht so sonderlich relevant.
Es ist nur ein kleiner Punkt der "Datenpflege", um z.B. ein Forum nicht größer werden zu lassen, als nötig.
Im WoltLab sind ja auch einige Löschvorgänge (wie Benachnrichtigungen, verwaiste Links usw.) automatisiert, von daher kann man den Punkt am ehesten vernachlässigen.
Wir verwenden keine eigenen Scripte.
Umso besser.
Zum Server-Wechsel: Ob das im Einzelfall eine Verbesserung bringt, ist immer etwas akademischer Natur.
Es kommt ja maßgeblich auf die konkrete Hardware des Servers an. dann auf die Art und Größe der Webanwendung(en), erwartete durchschnittliche Last am Tag und ähnliche Dinge.
Mit anderen Worten_ Für ein Forum mit 100 Besuchern am Tag und 10.000 Beiträgen wird sehr wahrscheinlich locker das 7.99 EUR Paket auf dem Shared-Server reichen, während z.B. für dieses Forum hier eher ein eigener (Root-)Server oder mindestens sehr leistungsstarker vServer angesagt ist.
Letztlich basiert auch vieles immer auf Erfahrungswerten, "ausreichend" ist in dem Bereich sehr relativ. Man muss nicht mit Kanonen auf Spatzen schießen, aber noch kritischer ist umgekehrt meistens ein zu kleines Web-Paket auf einem lahmen Server.
Das "Fingerspitzengefühl", was da die richtige Entscheidung ist, bekommt man meist erst nach einigen Jahren und Erfahrung mit verschiedenen Umgebungen.
Entscheidend ist immer, WAS Deine User im Moment (gleichzeitig) tun, wie viele Queries Deine Software benutzt (lässt sich häufig in Debug-Modes einer Anwendung checken) und wie viele Gäste zusätzlich die Seite besuchen (und was diese dort dürfen und tun).
Daher ist es sehr schwer, einen "passenden" Server pauschal zu nennen oder nur an der Mitglieder-Anzahl zu bemessen.
Die Frage ist, von welchem werten reden wir hier?
Also, wie „langsam“ sind die Aufrufe?
Du hast außerdem geschrieben, das es nicht immer ist, von welchen Schwankungen reden wir da? Also was ist „normal“ und was nicht mehr?
Das sind bislang rein gefühlte Werte. Wenn ich einen Server selbst betreibe, dann monitore ich einfach dessen Auslastung, und dann weiß ich, ob ich ihn aufrüsten sollte, oder ob er sich mit meinen Anforderungen eher langweilt. Ich stelle halt hin und wieder fest, dass einzelne Inhalte etwas verzögert laden, so vergeht in der Galerie bspw. mitunter eine Sekunde bis das Bild geladen wird. Aber klar, WLAN, ein nicht so arg schneller Internetzugang, ... Das ist nicht sehr aussagekräftig. Die von Google PageSpeed Insights armittelten Werte sind erstmal nicht überragend aber auch nicht unterirdisch. Schwankungen lassen sich damit aber natürlich schlecht feststellen.
so vergeht in der Galerie bspw. mitunter eine Sekunde bis das Bild geladen wird.
Das würde ich jetzt noch nicht unbedingt als "kritisch" ansehen. Damit kann man ja leben.
Aber klar, WLAN, ein nicht so arg schneller Internetzugang, ... Das ist nicht sehr aussagekräftig. Die von Google PageSpeed Insights armittelten Werte sind erstmal nicht überragend aber auch nicht unterirdisch.
Ganz genau, das würde ich jetzt auch erst mal nicht überbewerten.
In der Summe spielen ja all diese Faktoren eine Rolle dabei, wie schnell eine Seite beim einzelnen User tatsächlich voll sichtbar ist.
Auch seine eigene Hardware ist noch maßgeblich daran beteiligt.
Bei mir macht es beispielsweise einen spürbaren Unterschied (im selben Netzwerk und WLAN), mit welchem Rechner oder gar per Handy ich eine Seite aufrufe. Mit einem aktuellen und leistungsstarken Handy ist nahezu jede Seite im Netz schlagartig aufgebaut, auch Foren-Threads mit sehr vielen Fotos.
Viele legen auch Wert auf die sog. TTFB (Zeit, bis das erste Byte einer Seite ausgeliefert und vom Client empfangen wird).
Auch das kann ein Indikator sein. Man kann das aber auch überbewerten.
Wie Du schon sagst, vieles davon ist ein rein subjektiver Eindruck. Solange sich nicht reihenweise die User über eine lahme Seite beschweren oder gar ein Server nahezu zusammen bricht, denke ich ist alles in Ordnung.
Hallo Geronimo, vielleicht hilft dir das weiter: https://gtmetrix.com/reports/meisterschuetzen.org/cQiOHchV
Also, ich hab jetzt mal die Seite selber aufgerufen, zum aktuellen Zeitpunkt kann ich nicht wirklich sagen das die Seite langsam ist.
Ich gehe da aktuell eher von aus, das zu den Stoßzeiten die Seite langsam wird, weil der Server dann natürlich mit anfragen zugehauen wird.
Was aber auch sein kann, ist das Peering zu dem jeweiligen Anbieter von deinem Internet-Anbieter nicht gut ausgebaut ist oder garnicht vorhanden ist und deswegen über einen dritten noch gehen muss. Dadran kannst du natürlich nichts ändern, außer zu einem anderen Hoster gehen 
Also, ich würde das ganze einfach mal über einen längeren Zeitraum beobachten und nicht über einen externen Dienst machen. Dort dann z.b. mit der Webconsole vom Browser gucken wie hoch ist die Zeit oder ggfs. einfach eine Screenshot vom Netzwerktab machen, dabei immer die Uhrzeit beobachten(mit aufschreiben) und dann nach etwa 7 Tagen oder 14 Tagen mal alle angucken und dann kann man denke ich genaueres sagen erst.
Die weißt leider nicht wirklich, was der Server für Auslastung hat, das wird dir der Hoster auch nicht geben
Nein, das weißt du nicht und kannst du auch nicht ermitteln für einen Webspace.
Es kommt drauf an wie viel Geld du natürlich für das Projekt ausgeben willst, und demnach ggfs. einen eigenen Server holen oder auf einen Professionelleren Webspace umsteigen.(Weiß nicht wo du aktuell bist )
Hallo,
zunächst einmal wäre zu klären „was genau“ überhaupt langsam ist. Denn …
bspw. Bilder der Galerie, deutlich verzögert geladen werden
… verstehe ich so, dass die Galerie-Bilder selbst (und nicht etwa die die Galerie-Bild-Infoseite) langsam lädt. Da kann man dann so viel CPU auf den Server werfen, wie man möchte, das ausliefern von statischen Dateien wird dadurch nicht (nennenswert) schneller (abgesehen vom Fall, dass die CPU sowieso schon auf > 100% Last läuft). Viel mehr ist die Anbindung zu klein dimensioniert oder die Festplatte ist extrem langsam.
Und noch einige andere Parameter mehr, richtig. 
Letztlich zählt zwar die Summe der Hardware, aber für einzelne "Aufgaben" sind auch immer ganz bestimmte Komponenten eines Rechners besonders interessant und es gibt überall auch mal "Flaschenhälse".
Ich vergleiche das immer etwas mit "Gamer-PCs" oder auch hochleistungsfähige Rechner für z.B. Video-Schnitt oder ähnliches:
Dabei sind neben CPU und (ausreichend) RAM auch besonders die Grafikkarten / GPU-Chips des Rechners maßgeblich von Bedeutung, die früher gerne mal vernachlässigt wurden.
Dann konnte ein Rechner noch so schnell sein und massig Arbeitsspeicher besitzen, der Flaschenhals war dabei dann halt die Grafikverabeitung.
Oder man hat seinen Schwerpunkt auf MIDI, Sound-Bearbeitung, Audio-Schnitt usw., aber eine miese Soundkarte im PC. Auch das wäre natürlich (buchstäblich) "nicht der Hit".
Mit anderen Worten: Neben den Kernkomponenten wie CPU, RAM und Festplatten sollte auch besonders die Hardware mitspielen und Beachtung finden, die man für seine spezielle Aufgabe besonders benötigt.
Bedeutet unterm Strich: Wenn man viele Daten regelmäßig in das (und vom) Internet auf Server und zurück schaufelt, sollte z.B. auch die Datenbandbreite der Netzanbindung mitspielen usw usw.
Hallo Geronimo, vielleicht hilft dir das weiter: https://gtmetrix.com/reports/meisterschuetzen.org/cQiOHchV
Vielen Dank für den Link. Ich habe das jetzt mal etwas optimiert. Besserer Score aber längere Zeit. 
Mit der kleinen Differenz kann man aber leben. Gefühlt baut die Seite ja schnell genug auf.
Die Werte weichen bei zu unterschiedlichen Zeiten natürlich auch immer etwas ab, je nach Auslastung.
Aufschluss darüber, wo es evtl. noch etwas hakt, geben auch die Detail-Informationen (etwas tiefer), wenn man die jeweilige Rubrik aufklappt.
Aber ich denke, mit diesen Werten stehst Du schon ganz gut da.
Die verbleibenden zwei Punkte kann ich leider nicht beheben.
Das kommt beides von der Suite.
In der Theorie ließe sich das auch beheben. Aber in der Praxis führt das an anderen Stellen zu Einbußen und evtl. Problemen. Zumindest der letzte Punkt.
Man muss/sollte so oder so nie alle Punkte erfüllen.
Weil einige Punkte die auf diesen Seiten angezeigt werden, sind sehr Anwendungsspezifisch und bringen meistens keinen Mehrwert für den normalen Anwender.
Daher habe ich mich bei uns auch dagegen entscheiden, obwohl ich auch kurz überlegt hatte, diese Punkte noch etwas zu optimieren.
Da aber auch bei uns alles schnell genug lädt und Alle mehr als zufrieden sind, sehe ich auch keinerlei Veranlassung, etwas daran zu ändern.
Handlungsbedarf sehe ich eigentlich immer nur, wenn etwas auffällig schleppend läuft oder gar fehleranfällig wird.
Ansonsten gilt immer: Never change a running system! (or "winning team")
Ansonsten gilt immer: Never change a running system!
Auch das System braucht aufsetzen und das Team zusammenstellen. Du scheinst aber beides nicht gemacht zu haben. Zufallsergebnis.
Don’t have an account yet? Register yourself now and be a part of our community!
