Wir haben durchaus ein Paket bei All.Inkl. - hätte mir nur etwas Zeit gespart 
Werde dann bei Zeit mal einen Shop aufsetzen und das dort mal versuchen nach zu vollziehen. Generell brauchst du den Shop ja ohnehin nur über ein Protokoll erreichbar - ist ja gängige Praxis, dass man direkt auf SSL umleitet. Das wird an der Stelle aber ohnehin noch verfeinert/ausgebaut
Haben es mal in ein Ticket gegossen, da es auf unserem Hosting-Paket auch so ist.
Danke [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”) für’s kümmern und nachstellen!
Bin gespannt, woran es am Ende liegt - wenigstens ist es bei all-inkl so erst einmal reproduzierbar.
Im Frontend war der Erstaufruf via SSL langsam, wie im Ticken, kamen Produkte und Startseite gut erst 2 Minuten später. Hatte man das einmal “ausgesessen”, kamen bei späteren Aufrufen die Produkte (im Listing) sofort (Frontend) - bis man was an der Shop-Config geändert hat. Scheint also so, dass das Ausliefern “aus dem (twig)-Cache” eher weniger das Problem hat.
Im Frontend war der Erstaufruf via SSL langsam, wie im Ticken, kamen Produkte und Startseite gut erst 2 Minuten später. Hatte man das einmal „ausgesessen“, kamen bei späteren Aufrufen die Produkte (im Listing) sofort (Frontend) - bis man was an der Shop-Config geändert hat. Scheint also so, dass das Ausliefern „aus dem (twig)-Cache“ eher weniger das Problem hat.
Das würde auch erklären, wieso bei meinem shop es nicht so frapannt ist. Ich leere den cache und mache einen warmup nach dem stagen und nach dem import
Ich habe jetzt einmal Feedback aus unserer Entwicklung bekommen:
HTTPS ist dann langsam, wenn man in die Administration geht. Dort wird ein Request auf die Route /api/v1/_action/message-queue/consume gesendet welcher standardmäßig 30 Sekunden dauert. Das ist auch so gewollt, diese Route gehört zur Message Queue und dient der abarbeitung von scheduled tasks.
Sobald der Request abgeschlossen ist bzw. man die Administration schließt und 30sek wartet, ist alles wieder schnell. Der scheduled request kann in der Datei: vendor/shopware/Core/Framework/Resources/config/packages/shopware.yaml via enable_admin_worker deaktiviert werden.
Vermutung: Die Anzahl der PHP Prozesse begrenzt und alle anderen PHP Prozesse werden zurückgestellt solange der consume call läuft. Was uns hier wundert, ist die Tatsache, dass diese Limitierung bei HTTP nicht greift.
Wenn ich das deaktiviere und danach den Cache lösche (var/cache per FTP), dann läuft der Admin auch unter HTTPs schnell.
Ich werde mal schauen, ob ich bei All-inkl rausbekomme, ob es da ein Limit gibt.
Fyi, die Message Queue ist sowas wie Cronjobs, die Tasks können später auch auf dem Server direkt ausgeführt werden. Quasi das pendend zur SW5 Live-Abarbeitung der anfallenden Tasks.
Ein “Tasklimit” kann ich mir nicht wirklich vorstellen. Dann wäre der Shop - und auch jegliche andere Anwendung - nicht brauchbar, wenn mehr als ein Request gleichzeitig auf dem Paket läuft. Mal abgesehen davon halte ich es für sehr kurios, einen “worker” für feste 30 Sekunden auf einem Webserver laufen zu lassen - womöglich mit 100% CPU Auslastung, dann klemmt wirklich alles Andere auf dem System. Möglich, dass der “Worker” einfach den SSL-Encoder blockiert und andere Prozesse auf dem “Verschlüsseler” warten müssen? Also so eine Art “SingleThread” im Apache 
Letztlich hat All-inkl. auch nur mehr oder weniger 0815 Ubuntu - könnte also auch bei jedem anderen Hoster auftreten. NOCH dürfte ja die Anzahl der Tester überschaubar sein, drum so wenige “Betroffene” 
Wie auch immer. wird sicherlich einer eine echte Lösung finden 
Der Support möchte Testweise unser System auf Ubuntu 18 umziehen um Probleme die es wohl mit HTTP2 unter Ubuntu 16 gibt, auszuschließen.
Ich gebe das mal nächste Woche in Auftrag und werde dann berichten!
Feedback wäre echt toll. „Privat“ habe ich z.b. MySQL 5.7.26 - aber auf dem Business haben wir noch MySQL 5.6 - müssten also eh für SW 5.6 mal wieder umziehen. Wäre natürlich passend, gleich bei einem Umzug auf so ein Problem hinzuweisen. THX Moritz 
Habe den Umzug nun beantragt, denke der ist morgen abgeschlossen (zumindest lt. Planung von All-Inkl.). Schaue mir das dann morgen nochmal an.
Bin auch auf die Rückmeldung gespannt. Wir müssen auch noch auf MySQL 5.7 umziehen, damit ich SW5.6 in Angriff nehmen kann. Dann würde ales auf einmal gehen und ich kann parallel mit SW6 starten im Testshop.
Auf Anfrage haben die Kollegen von All-Inkl. den Umzug auch bereits heute vormittag durchgeführt. Da das ohnehin ein Testsystem ist, war die Urzeit hier egal. Ich kann definitiv bestätigen, dass das System jetzt deutlich schneller läuft: Shopware Administration (c) shopware AG
Es wird also daran gelegen haben und sollte mit einem Server-Umzug auf einen neueren geklärt sein!
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”) Bedeutet, dass die Lösung ein Umzug auf Ubuntu 18 ist, und wir (all-inkl Nutzer) das so gelöst bekommen, richtig?
Das wäre ja alles dann cool - freut mich, dass mein Post hier eine Lösung gefunden hat 
@TeichDatensysteme
Ja, lt. dem Support von All-inkl. liegt es wohl am HTTP2-Modul, was wohl in neueren Ubuntu-Versionen besser funktioniert.
Werd mich zum Thema All-Inkl. auch noch äussern, geplanter Umzug kommende Nacht.
Meine Laune bezüglich Neue Medien Münnich hält sich derzeit in Grenzen, weise ich beim Umzugsantrag extra auf Ubuntu 18 und diesem Thread hier per Link hin, und was bestätigen mir diese Supporter: Einen Umzug auf Ubuntu 16. Da nochmal per Telefon nachgehakt, und nun _mündlich_ eine Umzugsbestätigung auf 18… warten wir es mal ab.
Also an die Folgenden, die auch umziehen möchten / müssen: Lest Euch genau die Bestätigung durch, die Ihr bekommt.
Umzug mit kleinen Problemen vollzogen.
Testdomain mit SSL eingerichtet, Shopware (mit All-Inkl Patch “70”) installiert und Demodaten geladen.
Keine Probleme mehr mit dem “worker” - Admin läuft rund.
Für All-Inkl-Kunden wäre ein Serverumzug also eine Lösung. Es wäre dennoch ggf. auch für Shopware interessant zu wissen, warum es mit der 16er Version klemmt.
Ich würde wetten, dass dieses Problem in naher Zukunft auch bei anderen Hostern mit Ubuntu auftreten wird, und ob da “Kunde” so leicht einen Umzug beantragen kann?
Wie auch immer: Für mich ist das Problem Dank [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”) gelöst.
Auf Anfrage haben die Kollegen von All-Inkl. den Umzug auch bereits heute vormittag durchgeführt. Da das ohnehin ein Testsystem ist, war die Urzeit hier egal. Ich kann definitiv bestätigen, dass das System jetzt deutlich schneller läuft: https://ssltest.shopwareupdatetest.de/admin
Es wird also daran gelegen haben und sollte mit einem Server-Umzug auf einen neueren geklärt sein!
Hallo Moritz,
Ich hatte das Problem auch, nach einer kostenlosen Migration meines Pakets auf Ubuntu 18 läuft auch https sauber / mit normaler Geschwindigkeit.
Bei der Fehlersuche bin ich vor allem auf das Ticket gestoßen und erst nach vielem Suchen und Wühlen auf die eigentliche Lösung hier.
https://issues.shopware.com/issues/NEXT-4476
Könnte man dort noch einen Kommentar mit dem Hinweis den man hier findet unterbringen? (Umzug auf Ubuntu 18 beantragen wegen fehlerhaftem http2-Modul)
Würde sicher einigen helfen.
Ich möchte Eure Arbeit hier im Forum loben, hilft gerade bei so EA-Themen doch enorm.
Hallo, wie ging es denn hier weiter? Wir haben hier mit der 6.1.1 das gleiche Problem - der Shop ist quasi nicht zu bedienen, wenn SSL aktiviert ist (SW 6.1.1).
Ich wäre auch an einer Lösung interessiert, die auf nicht Ubunto >= 18 Servern funktioniert.
Wurde von mir und anderen auch nochmal bei Gitter thematisiert - sind ein paar mit den Problemen, dass der admin mit SSL nicht benutzbar ist.
Eine Migration von Ubunto 18 ist bisher leider nicht möglich, weil viele Projekte existieren, die hier nicht lauffähig waren - ein “Schnellmuss” via Update also nicht einfach machbar.
Wir hätten also auch großes Interesse das Problem ohne einen Serverwechsel zu lösen!
Naja, die alternative wäre ja HTTP2 zu deaktivieren. Es lag ja lt. Support an diesem Modul.