Hallo Holger, habe jetzt den httpCache deaktiviert, wahrscheinlich verträgt sich das mit apc nicht. Werde die Performance jetzt mal beobachten, für einen 99€/Monat Server erwarte ich eigentlich mehr. Unsere Datenbanken liegen schon auf einer SSD. Wir haben kaum Variantenartikel, finde die Seite dafür einfach zu langsam. Bilder habe ich die letzten Tage auch schon zum Großteil verkleinert. Evtl. hast du ja noch ein paar Tips, finde das super wie du hier hilfst!!!
[quote=„taaucher“]Hallo Holger, habe jetzt den httpCache deaktiviert, wahrscheinlich verträgt sich das mit apc nicht. Werde die Performance jetzt mal beobachten, für einen 99€/Monat Server erwarte ich eigentlich mehr. Unsere Datenbanken liegen schon auf einer SSD. Wir haben kaum Variantenartikel, finde die Seite dafür einfach zu langsam. Bilder habe ich die letzten Tage auch schon zum Großteil verkleinert. Evtl. hast du ja noch ein paar Tips, finde das super wie du hier hilfst!!![/quote] Soeben habe ich 3.6s auf „first byte“ warten müssen. Zwischendruch lief es zwar auch besser, aber irgendwas läuft da grundsätzlich schief. Was kann ich dir anhand der Daten wirklich nicht sagen. Ist der Server managed oder nimmst Du selber Einstellungen bei den Konfigurationen vor. Was sagen denn die Access-Logs über die Requestzahlen heute ~10:35 ? Sind da viele Request? Könnte eines der Plug-Ins sein, wenn Du nicht den Server „kaputt“ konfiguriert hast. Die Datenbank kannst Du ja mal in ein Testsystem einspielen und die Zeiten messen. Ich fürchte nur, die Premium-Plugins bekommst Du dort nicht gestartet, weil die Lizenz an die Domain gekoppelt ist. So, gerade noch schnell in den Dev-Tools mit meinem GoogleChrome zusätzlich geschaut: Da ist es mit 1 Sekunde für die PHP-Ausführung ok. Hier ergeben sich aber ziemliche Probleme durch die Anordnung und Anzahl der jQuery und CSS-Dateien. Ganz guter Test wäre mal die Datenbank auf ein anderes System einzuspielen und zu schauen, wie es läuft. Ich kann dabei kurz (!) mithelfen, wenn Du dir ein Testsystem besorgst. Wird Probleme mit den Plugins geben, weil die an die Domain gebunden sind, aber dann siehst Du zumindest, ob die Plugins Probleme bereiten und weißt, dass es ein „vernünftig“ konfiguriertes System ist. Abgesehen von first-byte müssen die Optimierungen aber nicht in Shopware laufen, sondern die Laderequests und die Parser-Strategie des Browser müssen unterstützt werden. Das wird für dich nur in begrenztem Umfang möglich sein, weil es aufwändige Handarbeit ist. Pack zuerst die Datenbank plus die Bilder auf ein Testsystem, dass ich mir anschauen kann. Dann kann ich dir da vielleicht mehr sagen.
Das ist ein Managed Server, ich habe da leider (oder aber besser?) selbst keinen Einfluß drauf. Dürfte also nix verkonfiguriert sein. Eine access Log von heute habe ich noch nicht, aber ich habe mal in die von gestern reingesehen und kann damit nicht wirklich viel anfangen.
Die schieben es auf Shopware.
So, jetzt habe ich ein neues Problem. Bis eben funktionierte der Shop, dann gabs folgende Fehlermeldung: Die nachfolgenden Hinweise sollten Ihnen weiterhelfen. Class Shopware\Models\Blog\Media is not a valid entity or mapped super class. in Doctrine/ORM/Mapping/MappingException.php on line 147 Stack trace: #0 Doctrine/ORM/Mapping/Driver/AnnotationDriver.php(166): Doctrine\ORM\Mapping\MappingException::classIsNotAValidEntityOrMappedSuperClass('Shopware\Models...') #1 Doctrine/ORM/Mapping/Driver/DriverChain.php(75): Doctrine\ORM\Mapping\Driver\AnnotationDriver-\>loadMetadataForClass('Shopware\Models...', Object(Doctrine\ORM\Mapping\ClassMetadata)) #2 Doctrine/ORM/Mapping/ClassMetadataFactory.php(293): Doctrine\ORM\Mapping\Driver\DriverChain-\>loadMetadataForClass('Shopware\Models...', Object(Doctrine\ORM\Mapping\ClassMetadata)) #3 Doctrine/ORM/Mapping/ClassMetadataFactory.php(178): Doctrine\ORM\Mapping\ClassMetadataFactory-\>loadMetadata('Shopware\Models...') #4 Doctrine/ORM/EntityManager.php(269): Doctrine\ORM\Mapping\ClassMetadataFactory-\>getMetadataFor('Shopware\Models...') #5 Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(202): Doctrine\ORM\EntityManager-\>getClassMetadata('Shopware\Models...') #6 Doctrine/ORM/Internal/Hydration/ArrayHydrator.php(83): Doctrine\ORM\Internal\Hydration\AbstractHydrator-\>gatherRowData(Array, Array, Array, Array) #7 Doctrine/ORM/Internal/Hydration/ArrayHydrator.php(69): Doctrine\ORM\Internal\Hydration\ArrayHydrator-\>hydrateRowData(Array, Array, Array) #8 Doctrine/ORM/Internal/Hydration/AbstractHydrator.php(106): Doctrine\ORM\Internal\Hydration\ArrayHydrator-\>hydrateAllData() #9 Doctrine/ORM/AbstractQuery.php(603): Doctrine\ORM\Internal\Hydration\AbstractHydrator-\>hydrateAll(Object(PDOStatement), Object(Doctrine\ORM\Query\ResultSetMapping), Array) #10 Doctrine/ORM/AbstractQuery.php(432): Doctrine\ORM\AbstractQuery-\>execute(Array, 2) #11 Shopware/Controllers/Widgets/Emotion.php(224): Doctrine\ORM\AbstractQuery-\>getArrayResult() #12 Shopware/Controllers/Widgets/Emotion.php(147): Shopware\_Controllers\_Widgets\_Emotion-\>getBlogEntry(Array, 3, Array) #13 Enlight/Controller/Action.php(135): Shopware\_Controllers\_Widgets\_Emotion-\>indexAction() #14 Enlight/Controller/Dispatcher/Default.php(521): Enlight\_Controller\_Action-\>dispatch('indexAction') #15 Enlight/Template/Plugins/function.action.php(94): Enlight\_Controller\_Dispatcher\_Default-\>dispatch(Object(Enlight\_Controller\_Request\_RequestHttp), Object(Enlight\_Controller\_Response\_ResponseHttp)) #16 cache/templates/compile/frontend\_emotion\_chsb\_de\_DE\_1/03/06/de/0306de955cf02dbb1953218f5ae15132083d0902.snippet.index.tpl.php(570): smarty\_function\_action(Array, Object(Enlight\_Template\_Default)) #17 Smarty/sysplugins/smarty\_internal\_templatebase.php(180): content\_51ba06afa43360\_28858084(Object(Enlight\_Template\_Default)) #18 Enlight/View/Default.php(273): Smarty\_Internal\_TemplateBase-\>fetch() #19 Enlight/Controller/Plugins/ViewRenderer/Bootstrap.php(212): Enlight\_View\_Default-\>render(Object(Enlight\_Template\_Default)) #20 Enlight/Controller/Plugins/ViewRenderer/Bootstrap.php(238): Enlight\_Controller\_Plugins\_ViewRenderer\_Bootstrap-\>renderTemplate(Object(Enlight\_Template\_Default)) #21 Enlight/Controller/Plugins/ViewRenderer/Bootstrap.php(136): Enlight\_Controller\_Plugins\_ViewRenderer\_Bootstrap-\>render() #22 [internal function]: Enlight\_Controller\_Plugins\_ViewRenderer\_Bootstrap-\>onPostDispatch(Object(Enlight\_Event\_EventArgs)) #23 Enlight/Event/Handler/Default.php(91): call\_user\_func(Array, Object(Enlight\_Event\_EventArgs)) #24 Enlight/Event/EventManager.php(156): Enlight\_Event\_Handler\_Default-\>execute(Object(Enlight\_Event\_EventArgs)) #25 Enlight/Controller/Action.php(147): Enlight\_Event\_EventManager-\>notify('Enlight\_Control...', Array) #26 Enlight/Controller/Dispatcher/Default.php(521): Enlight\_Controller\_Action-\>dispatch('indexAction') #27 Enlight/Controller/Front.php(214): Enlight\_Controller\_Dispatcher\_Default-\>dispatch(Object(Enlight\_Controller\_Request\_RequestHttp), Object(Enlight\_Controller\_Response\_ResponseHttp)) #28 Shopware/Bootstrap.php(79): Enlight\_Controller\_Front-\>dispatch() #29 Enlight/Application.php(192): Shopware\_Bootstrap-\>run() #30 shopware.php(74): Enlight\_Application-\>run() #31 {main} Ins Backend kam ich auch nicht mehr. Dann habe ich aus den config.php <?php return array (
'db' => array ( 'username' =\> 'pass', 'password' =\> 'pass', 'host' =\> 'localhost', 'port' =\> '3306', 'dbname' =\> 'pass', ), // Backend-Cache 'cache' =\> array( 'backend' =\> 'apc', 'backendOptions' =\> array(), 'frontendOptions' =\> array(), ), // Model-Cache 'model' =\> array( 'cacheProvider' =\> 'Apc' // supports Apc, Array, Wincache and Xcache ), ); Den Bereich: // Backend-Cache 'cache' =\> array( 'backend' =\> 'apc', 'backendOptions' =\> array(), 'frontendOptions' =\> array(), ), // Model-Cache 'model' =\> array( 'cacheProvider' =\> 'Apc' // supports Apc, Array, Wincache and Xcache ), gelöscht, damit funktioniert der Shop wieder. Was ist da passiert? ACP scheint jetzt das Problem zu verursachen, oder?
Also meine config sieht so aus <?php return array(
'db' => array( 'username' =\> 'xxxxxx', 'password' =\> 'xxxxxxxxxxxx', 'dbname' =\> 'xxxxxxx', 'host' =\> 'kuscheldir.at', 'port' =\> '3306', 'charset' =\> 'utf8' ), 'mail' =\> array('type' =\> 'sendmail') ); Hast du schon gefragt was sie für eine APC Version installiert haben. Auf der http://wiki.shopware.de/_detail_964.html steht nämlich was von 3.1.13. APCu gibts auch.
Wir haben 3.1.9, aber das funktionierte ja damit.
Hallo, die gelöschten Bereiche der config.php sind der APC-Cache, das ist richtig. In der Fehlermeldung steht auch, dass er eine „Model“-Zuordnung nicht richtig erzeugen konnte. Ich weiß aber nicht, ob dies nicht noch eine Folge der Test mit httpcache und anschließender Deaktivierung ist. Das ist jetzt aber reine Spekulation. An deiner Stelle würde ich die ganzen Ordner mit Cache-Dateien und Proxies per Shell auf dem Server löschen, anschließend APC wieder aktivieren und beobachten, was passiert. httpcache war immerhin nur Beta-Stadium und da dürfen Fehler passieren. @Server: Wahrscheinlich läuft der bei managed server unter apache und Du darfst davon ausgehen, dass der korrekt konfiguriert ist. All-inkl. muss die schließlich verwalten. Es kann natürlich immer Spezialfälle geben, in denen Einzelanpassungen, die dir verwehrt sind, nützlich wären. Das ist aber bei Shopware nicht der Fall und man sollte auch unbedingt die Finger davon lassen. Wenn man sich nicht intensiv mit dem Thema beschäftigt, kann man leicht Schaden anrichten. Ohne die Access und Error-Logs kann ich Dir aber zu möglichen Engpässen überhaupt nichts sagen. Generell ist das hier ein Stochern im Nebel und du solltest auf einem neu aufgesetzten System einmal durchteste, welches Plugin deinen Server ausbremst oder eine der anderen Maßnahmen Abhilfe schafft. Einfach mal hier und dort an der Config rumfrickeln bringt dich jetzt nicht weiter. Selbst wenn ich annehme, dass Du alles so tust, wie du es beschreibst. Nimm dir ein Paket bei Timmehosting, im Zweifel für 1-2 Monate und teste es mit den zusätzlichen Optionen dort durch. Alternativ machst Du einen zweiten Server (die Software) auf deinem jetzigen Computer auf. Ist nur zusätzliche Arbeit. All-inkl. hat nicht Unrecht mit der Aussage, es sei deine Software, die Probleme verursacht und nicht ihr Server. Klar, dass sie sich den Schuh nicht anziehen, wenn Du sie dafür nicht extra bezahlst. Dein horizontales Menü ist immer noch kaputt (Felge nicht mehr in blauer Reihe).
1 „Gefällt mir“
So, habe jetzt mal alle caches gelöscht, jetzt scheint apc wieder zu funktionieren. Die Seite ist auch relativ fix, eine Sachen hält sie nur auf: https://www.carhifi-store-buende.de/wid … 1194975009 Was ist das für eine Statistik und könnte man das entfernen (sofern nicht benötigt) Bringt es was auf php 5.4 oder 5.5 upzudaten? Das Menü oben passt bei mir auf allen Rechnern und Browsern, auch auf dem ipad.
zuerst würde es mal was bringen die mysql anzupassen. wenn es so ist wie ich vermute ist sie null an innodbs angepasst. standard ist nur myisam und mit viel zu geringen tabellencache u.s.w. hast du ssh zugriff? dann lade dir mal mysqltuner runter hau es drauf und lass es laufen. und wenn du 99€ zahlst und es nicht klappt frag doch mal wo anders an, es gibt da andere anbieter die können da mehr.
Ich habe einen ssh Zugang, aber nicht als root, kann ich den mysqltuner dann auch nutzen? was macht das Programm?
es checkt deine mysql db und fragt ab was sie kann wieviel sie benutzt und gibt groben überblick wo es hängt. als nicht-root wird es schwer 
Ich muss zugeben, deine Seite wäre mir für 99€ auch etwas zu langsam. Wir hatten im Vorfeld einige Hoster getestet - darunter ein Shared Tarif bei all-inkl. und das P/L Verhältnis hatte uns nicht zugesagt. Shopware lief relativ langsam und ab 25 parallelen Zugriffen war Schluss (all-inkl. beschränkt im Shared Tarif wohl die DB-Zugriffe auf 25 gleichzeitig) Wie hth aber treffend gesagt hat, kann man echt nicht nach dem Tarif gehen und ich füge hinzu auch nicht nach dem Preis. Bei Hosteurope waren die Virtual Server deutlich langsamer, als die Shared Tariffe bei domainfactory zum Beispiel. Wir zahlen aktionsbedingt für einen sehr kleinen Shop aktuell 10€ bei Domainfactory und die Performance ist ganz gut - dafür, dass wir keine Optimierungen vorgenommen haben (APC, Varnish, etc gehen im Shared Bereich leider nicht) ist es wirklich gut. Und auch der Support ist weit besser, als alles, was wir bei den anderen Hostern erlebt haben. Nicht, dass es dort schlecht war - all-inkl. war durchaus gut im Support. Aber df ist einfach noch einmal ein Stück besser. Also gerade für 99€ sollte mehr drin sein.
Ich bin mit dem Support dort wirklich sehr zufrieden, habe noch 2 andere Seiten auf dem Server, wobei dort nicht so viel los ist. Aber ich erwarte da auch mehr Performance. Aktuell hält mich dieses refreshStatistics aber auch mit fast einer Sekunde auf, weiß jemand was das ist? Bei webpagetest ist es das vorletzte was geladen wird.
Hallo, @refresh-statistic: Die tut da, was der Name sagt und hält die Ladezeit der Seite nicht auf. Sie läuft im Hintergrund. Die Seite/Server hat grundsätzliche Probleme, die sich in den Fehlermeldungen zeigen und den immer wieder zwischenzeitlich langsamen “First-Byte”-Zeiten. Dazu kommen die Ladezeiten und Rendering-Blockaden durch die jQuery- und CSS-Dateien. Letzteres macht sich je nach Anbindung und Rechner des Kunden unterschiedlich bemerkbar, ist aber nicht durch APC/Varnish/httpCache beeinflussbar. Das eigentliche Problem ist die Instabilität des First-Byte-Wertes. Mit allen Informationen, die hier mittlerweile online stehen, lässt sich das aber nicht weiter ergründen. Es ist z. B. auch wichtig zu wissen, wieviele gleichzeite Zugriffe es bei einem Test gibt. Die First-Byte sind im Vergleich zu einer Shopware-Installation auf dem billigsten Shared Hosting Paket von all-inkl. oft sehr langsam. Das zeigt eigentlich, dass man die Geschwindigkeit nicht all-inkl. als systemisches Problem anhängen kann. Könnten ja auch die beiden anderen Installationen sein. Die managed Hosting Pakete von domainfactory bieten schon eine gute Leistung für das Geld. Ich habe dort selber große Webseiten betreut, wenn auch nicht auf dem 10 Euro Tarif. Trotzdem ist die RAM-Ausstattung niedriger als die Mindestvoraussetzung von Shopware. Viele Shops werden damit ohne Probleme auskommen, wenn man aber plant, viele Kategorien und/oder sehr viele Varianten zu installieren, dann kommt es zu Problemen.
Wie gesagt: nach unserer Erfahrung bisher ist der Preis nicht allzu aussagekräftig. Stabilität und Ladezeiten sind selbst beim kleinsten df Paket gut. Wobei ich nur für Größen von ein paar 100 Artikeln und 2-3 dutzend Kategorien spreche. Ich will auch all-inkl in keinster Weise schlecht reden. Die haben etliche gute Bewertungen bekommen. Das wird schon seinen Grund haben. Im Direktvergleich hosteurope - df - all-inkl schnitt nach unserem subjektiven Test df vom P/L und Support am Besten ab. Ich hab mal ein paar unserer Tests rausgekramt: all-inkl - PrivatPlus 7,95€ http://loadimpact.com/load-test/test759 … a1fc010917 http://tools.pingdom.com/fpt/#!/CsEgTT6 … /shopware/ df - kleinster ManagedHostingPro 9,95€: http://loadimpact.com/load-test/testser … 7d061932eb http://tools.pingdom.com/fpt/#!/wE38Cj9 … f-kunde.de Beides günstige Shared Tarife mit SW3.5 Demoinstallation. Man sieht aber selbst hier, dass im Sharedtarif bei all-inkl die Seite in 1,6sec geladen war. Das spricht ganz klar dafür, dass es nicht grundsätzlich an all-inkl liegt, sondern speziell in eurem Server / eurer Konfiguration.