Performance Vserver Host Europe

[ShopNix]

Mit dem MYSQLTuner bin ich schon einmal wegen fehlender Rechte gescheitert. Ich werde mich nochmal daran geben.

Ich bin fast sicher, dass Du Dir an der Stelle unnötig Arbeit machst.

Ich lese hier im Forum immer wieder, dass User Shops mit 2Tsd bis 10 Tsd Artikeln auf einem 5 bis 10€ Webspace zufriedenstelend laufen haben. Nachdem ich nun mal in den Eingeweiden von MYSQL gegraben habe kann ich mir das kaum vorstellen!

Die meisten Queries erledigt MySQL in Sekundenbruchteilen. Du kannst aber auch mal hier reinschauen, und Deine Indizes mit den Empfehlungen vergleichen.

Wie gesagt: Wichtig ist die Nachbarschaft, und die habe ich noch immer vorrangig in Verdacht. Zudem ist von der technischen Grundlage ein vServer generell ein wenig langsamer, als ein Hostingpaket, das direkt auf einer realen Maschine läuft. Und für beide gilt das gleiche Handikap: Die Nachbarschaft ist eher zufällig zusammengewürfelt, und Du hast keinen Einblick und schon gar keinen  Einfluß auf deren Treiben.

So schwierig ist es doch nicht, mal eine Kopie anzulegen oder ggfls den Hoster zu bitten, Deinen vServer auf eine andere Maschine zu legen.

[peter111]

Dank an alle für die Hinweise - ich habe dadurch mal wieder viel gelernt!
@Matt: Deine shopstat_functions klappt - allerdings bei mir mit wenig Performancegewinn. Vmtl., weil ich gerademal 42 Kategorien in 2 Ebenen habe. (Eine Kleinigkeit: die Links der manufactureres aus dem Hersteller-Dropdown werden nicht umgeschrieben) 
Nach dieser Testorgie (die sicher nicht unnötig war und doch die ein oder Erkenntnis gebracht hat) werde ich Shopnix Rat folgen und HE um eine Testumgebung bitten.

[peter111]

Der Support von HE hat die posts ebenfalls gelesen und hierzu angemerkt:

Die im Forum angesprochenen Nachbarn auf dem selben physischen Server, können wir wie bereits erwähnt ausschließen. Sie befinden sich hier in einer eigenen, abgeschotteten Umgebung.
Wir haben die Last der gesamten Maschine bereits überprüft und sind uns daher sicher, dass es dem "xHost" (so nennen wir die Physische Maschine auf dem Ihr Server läuft) gut geht und hier keine erhöhten Lasten durch andere Kunden zu erkennen sind.
Wir empfehlen weiterhin, einen Bytecode-Cache zu verwenden. Leider geht im Forum niemand darauf ein, welcher Cache sich hier empfehlen würde.

Weiterhin hat man mir, mit dem Hinweis das der Modified problemlos damit läuft,  empfohlen XCache zu aktivieren. Nach der Aktivierung liegt die parse_time nun unter 200ms bei Produktseiten und etwa bei 400ms bei Produktauflistungen/Kategorien. Leider sind die Aussetzer noch vorhanden  auch wenn die Zeiten nun etwas kürzer sind.
In dem Zusammenhang ist mir aufgefallen, dass die Aussetzer überwiegend bei Besuchen mit Android bzw. Ipads  entstehen. Wir nutzen noch ein "klassisches" html4-Template ... hat jemand Erkenntnisse ob html5 in dem Bereich Vorteile bringt?

[Matt]

Nein, der Doctype hat keinerlei Auswirkungen darauf. Und ich konnte die Hänger ja auch mit einem Desktop-Browser nachvollziehen.

[Bonsai]

Mal in einer root Konsole das aufgehabt?

Code: PHP  [Auswählen]

tail -f /var/log/messages

Und dann den Fehler reproduziert?

[peter111]

Mal in einer root Konsole das aufgehabt?

Darauf habe ich keinen Zugriff.
Zumindest gehe ich davon aus, da Putty mir /www als oberstes mit SSH-erreichbares Verzeichnis angibt.
Hinzukommt, dass ich kein "pinguinisch" kann 

[Bonsai]

Hast Du denn einen "ssh login" von Provider? Das wäre eine root Konsole. Geht z.B. mit dem Programm Putty

Mit dem "Pinguinisch" (=bash) kann ich ein wenig aushelfen. Hab meine Abschlussprüfung auf einem Pinguin gemacht.

EDIT: Hier hat jemand das gleiche Problem, also root Konsole für Plesk:
Where is the command line interface? Please help

[peter111]

Ich hatte es bereits mit Putty versucht aber ich kann mich nur auf der Ebene /www/ anmelden - /var/log/messages usw. dürfte darüber sein und da habe ich keinen Zugriff.
Außerdem gibt es keine Hinweise im ErrorLog und dort würden Ungereimtheiten sicher auch dokumentiert.
Der HE Support hat sich noch einmal ergebnislos auf Fehlersuche gemacht und schließt daraus, dass der Fehler im Script liegen muss  Spannende Sache! Ich werde jetzt noch mal den Modified installieren und testen.  

[Matt]

Ich hatte es bereits mit Putty versucht aber ich kann mich nur auf der Ebene /www/ anmelden - /var/log/messages usw. dürfte darüber sein und da habe ich keinen Zugriff.

Schon mal versucht? Was passiert wenn du

Code: [Auswählen]

cd ..eingibst? Und was passiert wenn du einen su auf den root-User machst? Laut deren Website sind das Server mit vollen root-Rechten, d.h. du kommst auch überall hin und überall dran. Oder hast du einen Managed Server?

[Bonsai]

Das su Kommando hätte ich auch mal versucht
http://de.wikipedia.org/wiki/Su_%28Unix%29

[peter111]

So - nun mal das Ergebnis und Siegerehrung  :
Ich habe den aktuellen modified mit dem Datenbestand meines Testshops installiert und beide im direkten Vergleich laufen lassen. Beide Shops bringen, auch dokumentiert in den parsetime.logs,  immer wieder Aussetzer (und beide sind gleich schnell). Somit sind die Scripte als Übeltäter auszuschließen.
Bei einem managed VServer hat man bei HE keinen Root-Zugriff!
Der Support hat freundlicherweise die var/log/messages usw. nochmals geprüft ... es sind kein Hinweise auf den Grund der Aussetzer feststellbar.
Da die Serverumgebung für unsere Belange definitiv überpowert ist und HE leider keine Testzugänge anbietet werde ich mir nun mal die Töchter anderer Mütter anschauen.
Vielen Dank für eure Unterstützung    

[ShopNix]

HE:
Wir empfehlen weiterhin, einen Bytecode-Cache zu verwenden. Leider geht im Forum niemand darauf ein, welcher Cache sich hier empfehlen würde.

Wozu sollte es gut sein, sporadisch auftretende Fehler zu cachen?

Nichts gegen Maßnahmen, die generell die Performance über alles verbessern. Das ist im Livebetrieb nützlich. Die Fehlersuche hingegen betreibt man besser auf einem Minimalsystem.