Module für Produktiv Einsatz deaktivieren oder deinstallieren aus Performance sicht?

[BluTiGeS]

Hallo zusammen,

 

ich bin gerade ja dabei ein Shop Live zu schalten, jedoch komme ich gerade an eine kleien Gedanken frage.

 

 

Ich habe einige Module deaktiviert, nun stell ich mir die Frage ob es nicht besser wäre diese gleich zu deinstallieren.

 

Dies sollte ja rein vom Gedanken her mehr Performance bringen, da er diese nicht auf Aktiviert, Deaktiviert prüfen muss, oder ist das nicht der Fall?

 

 

Wie handhabt ihr das mit den modulen?

 

 

Grüße

BluTiGeS

[guest*]

Sind sie deinstalliert, dann greifen Sie auch nicht mehr in die Performance ein. Wenn du auf löschen gehst, dann werden sie aus vom FTP gelöscht. Od sie dort stehen oder nicht. hat keinen Einfluß auf die Performance mehr.

 

Benötigst du keine Statistiken oder Auswertungen, dann schalte alle Module die mit Statistiken zu tun haben ab, bzw. deinstalliere sie. Sie füllen die DB mit Daten.

 

Hast du jetzt schon Probleme bei einem nackten Shop mit Performance, dann sind diese ernst zu nehmen und zu beheben. Sie werden mit einer wachsenden Datenbank nicht besser.

[BluTiGeS]

Okay also alles was nicht benötigt wird deinstallieren anstatt deaktivieren .

 

Naja Performance ist nicht das Problem vom Gefühl her.

Jedoch ich würde schon alles soweit optimieren wie möglich , egal wie viel Power man hat,

 

Ich check mal die Ladezeit ab und poste das gleich mal noch

 

EDIT:

Laut http://tools.pingdom.com/fpt

habe ich eine Performance von 87/100 Page size 440.2kB Load time 2.41s Requests 52 also gar ned sooo schlecht

[guest*]

deaktivieren = sie bleiben aktiv, schreiben aber nichts in DB. für die Performance neutral

deinstallieren = wenn sie richtig gecodet sind, dann werden alle DB-Einträge gelöscht, Modul ist nicht mehr aktiv und somit auch Performance neutral

 

löschen= du löscht sie vom FTP. ACHTUNG aber: vorher unbedingt, um die DB zu säubern den Weg von deaktivieren gehen, damit die DB auch gesäubert wird und keine Restbestände bleiben, die nie wieder gebraucht werden.

[guest*]

Performance: das habe ich auch (zw. 2-3 Sek.), aber bei 19.000 Produkte, 300 Kunden, 300 Kategorien und 200 Produktfilteroptionen. Wenn dein Shop leer ist, dann ist das eher nicht gut...

 

e-accelerator installiert ? memcache aktiviert ?

 

Hier einmal einen Auszug aus einer Mail an mich von einen der beiden Big Boss an mich (Bruno Leveque):

 

Performance Tuning :

 

1. You should install mcrypt on your hosting and switch on Ridjnael

2. You should use media servers, I can have a very good price for you on MaxCDN for instance

3. You should use the cache system at least the "Filesystem" cache mode

4. You should empty ps_connections_page, ps_connections_source and ps_guest frequently

5. You should install eAccelerator or APC on the server (15-20% of additional performance)

[guest*]

Ein neuer User hat einen Provider genannt. Habe mir die Seite mal angesehen. SSD-Träger sagen ja nicht wirklich etwas über die Technik die dahinter steckt aus. Ich habe mal die Testinstallation des aktuellen Presta angesehen. Also der Speed ist dort mit den Standardprodukten ein Bruchteil von einer Sekunde. Du kannst mal selbst vergleichen. Genau das meine ich auch, dass wenn du schon bei einem leeren Shop Probleme hast mit Speed, wirst du immer Probleme damit haben. Vergleiche einmal den Speed. Den Speed den du nennst, sollte herauskommen bei einem Shop meiner Größenordnung. Da ist eine Parse von 2-3 erlaubt.

[BluTiGeS]

Hi,

 

Vielen Dank für deine Betiräge, also ich habe bei dem Anbieter leider kein Memcache und diese wollen es auch nicht möglcih machen.

 

 

1. You should install mcrypt on your hosting and switch on Ridjnael --> mcrpyt ist installiert und Ridjneal bereits aktiv

2. You should use media servers, I can have a very good price for you on MaxCDN for instance --> habe ich keine

3. You should use the cache system at least the "Filesystem" cache mode --> Memchae leider nciht möglich und CacheFS soll Probleme machen

4. You should empty ps_connections_page, ps_connections_source and ps_guest frequently --> Soll das direkt in der DB gelöscht werden`?

5. You should install eAccelerator or APC on the server (15-20% of additional performance)

--> APC bietet mein Hoster an jedoch kommen da 70€ mehr im Monat auf den Shop zu, und ich bin mir noch nicht sicher wie die Nutzerrate sein wird zum normalen Handelsgeschäft. Das eAccelerator muss ich mal nachforschen.

 

 

 

Ich habe auch schon überlegt den Dateisystem cache zu aktivieren, aber iwie liest man hier im forum nur von Problemenen und 7-8 GB an Cache Files. (was nicht das Problemn ist haben 25GB Space) aber iwie komisch.

 

 

Der Shop wo ich getestet habe ist nicht leer, er hat 70 Artikel und insgesamt ca. 700 Kombinationen.

 

 

PS: SSD Webhosting ist schon ratz fatz , was natürlich an den hohen IOPS liegt, faktor 1000 -10000 zu einer normalen HDD.

 

Mit dem Pagespeed tool komme ich hier auf 500 ms, was 5 mal schneller ist wie mein webspace und Preise sehen auch günsitg aus, mal überlegen, wenn der Shop gut anläuft ,)

 

 

EDIT: Habe mal Filecache aktiviert und heute scheint der Pagespeed bei 1.4 sekunden zu liegen.

 

 

Grüße

BluTiGeS

[sickz]

2. You should use media servers, I can have a very good price for you on MaxCDN for instance --> habe ich keine

Am besten Subdomains eintragen falls keine zweite Domain besteht. Die Subdomain dementsprechend dann den Ordner zuweisen. Der Browser spricht von einer Domain "nur" 4-xxx Datein an (je nachdem wie es eingestellt ist, bei den meisten wird es allerdings standart sein) die Subdomain gilt dabei als eigene Domain und das Laden von Datein wird fast verdoppelt da der Browser mehr abfragen auf einmal machen kann.

 

 

4. You should empty ps_connections_page, ps_connections_source and ps_guest frequently --> Soll das direkt in der DB gelöscht werden`?

 

 

Die Einträge nur leeren, d.h quasi auf urpsrungszustand nach der Installation zurücksetzen.

 

5. You should install eAccelerator or APC on the server (15-20% of additional performance)

--> APC bietet mein Hoster an jedoch kommen da 70€ mehr im Monat auf den Shop zu, und ich bin mir noch nicht sicher wie die Nutzerrate sein wird zum normalen Handelsgeschäft. Das eAccelerator muss ich mal nachforschen.

 

Das sind alles Apache Module, die installation dauert für den Webhoster nur paar Minuten und es bringt alles nutzern was. Frechheit dafür 70€ zu verlangen

 

Ich habe auch schon überlegt den Dateisystem cache zu aktivieren, aber iwie liest man hier im forum nur von Problemenen und 7-8 GB an Cache Files. (was nicht das Problemn ist haben 25GB Space) aber iwie komisch.

 

Soll wohl nur passieren falls man das Modul "Kategorie Block" Block benutzt, ich find eine Navi Leiste eh deutlich ansprechender.

 

Ich bin gestern auch auf SSD-Hosting aufmerksam geworden, als vergleich habe ich testspace beantragt und von 1.5s~ zu 500ms~ bin auch beeindruckt, wobei cachefs das wahrscheinlich noch steigert, da auch die MYSQL Abfragen in der Datei gespeichert werden und dank SSD extrem schnell aufgerufen werden.

Das einzige Problem was ich bisher bei CacheFS hatte ist das ich nach einiger Zeit keine Einstellungen speichern oder bestellung bearbeiten konnte.

 

Ich werde diesen Monat jedenfalls wechseln, da die 1.5s mir schon sehr lange vorkommen.

[guest*]

Soll wohl nur passieren falls man das Modul "Kategorie Block" Block benutzt, ich find eine Navi Leiste eh deutlich ansprechender.

 

 

Nicht mehr, das war einmal vor langer Zeit... Mittlerweile lauft ein JS dahinter. Ich habe mir ein Mega-Menu bauen lassen, weil ich deep-level4-5 habe und die alle nur bis 3 gehen. Problem daran ist, dass es trotzdem die Kategorien alle lädt (für den load nicht relevant, ABER für SEO-Zwecke...). Damit mache ich mir dann wieder das SEO kaputt. Ich verwende nun wieder Prestas original blockcategories aus der Version 1.4.6.2, also Original und habe es auf max. deep-level 2 konfiguriert. Durch die Unterkategorien muss sich der Kunde dann trotzdem klicken. Geht leider nicht anders, weil es sonst mit dem mobileTheme kolidiert. Dies ist leider nur wie Presta es ja original hat max. deep-level 3 Standard...

 

Habe auch Probleme mit meinem Server. Seit 2 Monaten ist der total langsam... Habe parallel einen clone unter einer unsichtbaren Serverdomain (Root) am gleichen Server liegen. Die eine Domain hat fast-cgi+cache eingeschaltet und die andere Domain suPHP. Beide sind zur Zeit gleich schlecht... suPHP ist manchmal sogar schneller als das fast-cgi, was eigentlich viel schneller laufen soll. Habe des öfteren meinen Provider angeschrieben... Immer wieder die Ausrede, es liegt am Presta... Bis vorgestern, wo ich eben den Beweis erbrachte, dass es nicht am Shop liegt, sondern am Server oder am Skript... fast-cgi war einmal irre schnell, jetzt nicht mehr...

Heute kam die Mail: sie können nichts feststellen mit ihren Messtools, die Angelegenheit wurde an Spezialisten weitergeleitet...

Tja, man muss wohl mit einem Gegenargument kommen, dass man ernst genommen wird.

 

Ich werde mir auch mal ein Testaccount dort nehmen. Bei meinem großen Shop zahlt es sich auf jeden Fall aus... Die andern kleinen, bei denen ist es die Rede nicht Wert, die haben sowieso eine Parse von 1-2 Sek. Es hängt eben viel auch an der Größe des Shops... Was mir aber auch aufgefallen ist, ist dass Prestashop die DB-Tabellen bereits verdoppelt hat inm Vergleich zu einer 1.3.-Version. Bei der 1.5. sind es mehr als doppelt, für mich der Testshop mit Standard-Musterartikel eine einzige Katastrophe, obwohl der Webspace groß genug ist und eben schnell... Ein Umstieg ist für mich noch nicht in Sicht... Habe das aber auch schon mehrmals auf Entwicklerseite deponiert... Sie arbeiten dran. Einen zweiten Magento möchte ich nicht, genau aus dem Grund bin ich bei Presta gelandet...