Im September 2019 rief mich ein langjähriger Kunde an. Wir haben für Ihn schon den Magento Shop sowie zuletzt eine Eigenentwicklung seines Entwicklerteams gehostet. HHVM, PHP-FPM und auch Docker Container waren Techniken, die wir hierfür zur Verfügung gestellt haben.

Bei seinem Anruf teilte er mir jedoch mit, dass er mit seinem Shop auf Shopware umsteigt und die Agentur bereits kurz vor der Fertigstellung steht. Üblicherweise hat die Agentur ihm geraten, das Hosting auf einen empfohlenen Provider der Agentur umzustellen. Es handelte sich dabei um einen bekannten niedersächsischen Provider der sich mit NGinx Hosting auf Shopware spezialisiert hat. Der Kunde teilte mir mit, dass er diesem Umzug nur sehr ungern zugestimmt hat. Jedoch möchte er als Shopbetreiber sicherstellen, dass die Agentur mit dem Hoster gut zusammenarbeitet. Die Agentur meinte, dass es nur bei dem einen Hoster, den Sie empfehlen, möglich wäre.

Selbstverständlich haben wir das akzeptiert und soweit alles in die Wege geleitet.

Am Tag des Umzug des Shops auf das neue Serversystem sah soweit alles gut aus. Durch die Verwendung von Cloudflare konnte die Domain augenblicklich auf den neuen Server umgestellt werden.

Gegen Mittag klingelte erneut das Telefon. Es war der Kunde. Er war sehr erregt weil der neue Shop erhebliche Probleme bei der Erreichbarkeit zeigte. Er bat unsere Technik eine Analyse des Problems bei dem anderen Hoster zu erstellen da sowohl die Agentur als auch der Hoster unzureichende Informationen lieferten. Am Ende gab es von Seiten der Agentur und auch vom neuen Hoster keine wirklichen Lösungen.

Wir stiegen also in die Analyse des Systems ein.

Folgende Eckdaten wurden gesammelt:

• Der Shop verwendet Shopware 5
• Der Shop lief bei dem neuen Anbieter auf einen Server (DB Server und Webserver zusammen)
• Der Shop hat zu Spitzenzeiten 100 gleichzeitige Besucher (> 1.3 Millionen Seitenanfragen pro Tag)
• Der Shop verwendet Redis als Cache Backend
• Der Shop läuft auf einem dedizierten Server mit Nginx als Webserver
• Der Shop läuft auf einem dedizierten Server mit 32 CPU Kernen und 128GB RAM

Als wir die Infos zu dem Server erhalten haben, hat uns gewundert wieso ein so wichtiger und umsatzkräftiger Shop nicht auf einem redundanten System läuft. Ein einfacher Hardwareausfall wie ein defekter RAM Speicher, CPU oder Mainboard würden für einen Stillstand des kompletten Shops für längere Zeit sorgen.
Da der Shop des Kunden bei uns bis dato immer auf einem hochverfügbaren Cloudsystem lief, hat uns diese Eintscheidung des Kunden doch sehr gewundert.

Als erstes haben wir eine Bestandsaufnahme der Performance gemacht.

Bei dem ersten Test haben wir die Geschwindigkeit der Startseite des Shop gemessen. Wir verwenden dazu https://loader.io .
Loader.io kann viele verschiedene Zugriffe mit unterschiedlichen IP Adressen auf eine Zielseite simulieren und die Ergebnisse darstellen:

Der Test war ernüchternt. Zugriffzeiten von über 1.5 Sekunden und bereits bei wenigen Zugriffen war es dem Server nicht mehr möglich zu antworten. Es kam zu Timeouts.

Wir haben eine Testinstanz des Shopware Shops auf unserem Shopware Hosting Demoserver installiert um zu sehen, ob der Shop selbst ggf. ein Problem aufweist. Nach einigen Konfigurationen wie z.B. MySQL Optimierungen, Redis Konfigurationen, PHP-FPM Anpassungen etc. lief der Shop auf unserer Hardware sehr performant:

Durchschnittliche Ladezeiten von unter 500ms lagen in dem Bereich, den wir für diesen Shop erwartet haben.

Uns war schleierhaft, warum das Ergebnis bei dem neuen Hoster nicht erzielt werden konnte und auch offenbar niemend dort bereit war, das Problem weiter zu verfolgen.

Trotzdem war das Ziel der Analyse zu dem Zeitpunkt noch, herauszufinden warum es auf dem Shopware spezialisiertem Hoster nicht in zufriedenstellender Performance funktionierte.

Zu den Eckdaten unseres Systems:

• VMWare Enterprise Cloudsystem mit voller redundanz und einer Verfügbarkeit von 99,99%
• 10GBit Netzwerkverbindungen für die Cloudplattform intern und extern
• 16 Kerne, 16GB RAM
• DB Server und Webserver auf einem System (wegen der Vergleichbarkeit)
• Redis Server als Cache
• NGinx als Reverse Proxy und Apache 2.4 als Backend Server mit PHP-FPM
• Shopware optimierter Cloudserver

Normalerweise würden wir einen Shop dieser Größenordnung auf einem System mit getrennten DB- und Webserver installieren, jedoch wollten wir eine Vergleichbarkeit von unserem System und dem System vom neuen Hoster erreichen. Daher haben wir es so installiert, wie der andere Anbieter.

Nach einigen weiteren Tests konnten wir das System des NGinx Hosting Spezialisten nicht auf unsere Performance anheben. Vom Anbieter und der Agentur kamen leider auch keine brauchbaren Informationen. Der Support war anscheinend auch sehr schwierig. Etwas was aus unserer Sicht im Bereich Shophosting nicht sein darf.

Um den Shopware Shop und ggf. irgendwelche besonderheiten mal komplett auszuschließen, haben wir einfach eine phpinfo auf unserem Server und den des neuen Hosters abgelegt und einen Performancetest durchgeführt:

Hurra, dies war tatsächlich der erste Test, den der Server des anderen Anbieters ohne Fehlermeldung beantworten konnte. Die durchschnittliche Zeit von 624ms war nicht begeisternd.

Wir haben den Test auf unserem System durchgeführt:

Die durchschnittliche Ladezeit einer phpinfo Seite war auf unserem System bereits über 40% schneller als auf dem System des NGinx Spezialisten.

An der Stelle haben wir aufgehörrt nach Problem im Shop oder in den Einstellungen zu suchen. Das andere System hat offenbar ein Leistungsproblem da es bereits unserem System mit 16 Kernen und 16GB RAM bei sowas einfachem wie einer phpinfo Seite weit unterlegen war.

Da wir im ständigem Kontakt mit dem Kunden waren, haben wir diese neue Info an ihn kommuniziert. Wir sind somit dazu übergegangen, das Shopware System auf unserem Servern mit größtmöglicher Performance zur Verfügung zu stellen und haben aufgehört die Problem des anderen Anbieter zu suchen da sich dieser offenbar wenig lösungsorintiert gezeigt hat.

Auch Tests ohne Redis Cache zeigten, dass unser System mit einer durchschnittlichen Ladezeit von weit unter einer Sekunde theoretisch auch ohne Cache in der Lage wäre, eine große Anzahl von Kunden zu bedienen. Dies wird ggf. notwendig wenn aufgrund einen Produktupdates ein löschen des Caches im Betrieb notwendig ist. In dem Fall müssen die Seiten schnell aufgebaut werden können um den Cache schnell zu erneuern.

Im weiteren Verlauf wurde bei unseren Tests langsam die Anzahl der Benutzer pro Minute erhöht. 250 Benutzer pro Minute sollten eigentlich noch keine große Herausforderung für ein vernünftig konfiguriertes Shop Hosting System sein.

Bei 400 Benutzer pro Minute mit aktiviertem Redis Cache sieht noch alles gut aus:

Bei 600 Clients pro Minute und deaktiviertem Cache sieht die Sache schon anders aus:

Hier zeigt sich, dass ein System mit DB- und Webserver sich gegenseitig behindert. Ohne Cache wird der DB Server intensiv genutzt. Die Performance, die hier benötigt wird, fehlt dem Webserver, Am Ende steht das System. Dies ist auch nur bedingt durch mehr Kerne oder mehr RAM aufzufangen. Am Besten trennt man die beiden Systeme und verwendet zwei Server. So ist eine gegenseitige Behinderung ausgeschlossen. Da unsere Cloudserver sowohl intern als auch extern hochperformante 10GBit Verbindungen verwenden ist sichergestellt, dass die Daten der Datenbank mit bestmöglicher Geschwindigkeit zum Webserver geliefert werden. Ebenfalls hilft die Trennung von Web-und DB Server bei späteren Skalierungen, weitere Webserver über einen Loadbalancer zu installieren.

Nach der Installation des dedizierten DB Servers lief auch der Test mit 600 Clients / Minute ohne Cache problemlos durch. So stellen wir uns das bei einem Hosting Spezialisten und Shopware Hosting Paket vor. Auch der Kunde war begeistert.

Nach der Aktivierung des Caches ergaben sich wirklich sehr gute Ladezeiten:

Nach dem bis jetzt alles super lief, wollten wir unser Glück herausfordern und versuchten eine Test mit 1000 Clients / Minute:

Hier liegen offenbar die Grenzen des Systems. Ab 1000 Clients / Minute muss über ein Lastenausgleich nachgedacht werden d.h. es werden mehrere Webserver installiert, die im Backend auf den DB Server zugreifen.

Dies entspricht auch der heutigen Philosophie. Man versucht seine Systeme nicht mehr in die Höhe wachsen zu lassen sondern in die Breite. Lieber 2 Webserver mit je 12 Kernen statt ein Webserver mit 32 Kernen. Es gibt Komponenten im System, die können mit zusätzliche CPUs und RAM nicht hoch skaliert werden (Controller, Bussystem etc.).

Wenn der Kunde diese Zugriffszahlen erreicht sind wir gerüstet das System schnell auf ein Loadbalancing aufzurüsten.

Wir freuen uns, dass wir den Kunden auf diese Weise wieder in unser Rechenzentrum zurückholen und mit unserem Service und System zeigen konnten, dass wir in einer höheren Liga spielen als selbsternannte norddeutsche Spezialisten für NGinx Hosting.

Wenn auch Sie unzufrieden mit Ihren Shopware Hosting sind oder Fragen zu professionellen und performanten Shop Hosting Servern haben, kommen Sie gerne auf uns zu. Wir freuen uns über Ihre Anfrage und stellen Ihnen gerne ein Demosystem zum Testen zur Verfügung.

The post Shopware Hosting Performance appeared first on LCube - Professional Hosting Blog.

Wir gehen hier von einem NGinx frontend Server und einem Apache2 backend Server aus.

1.
Im NGinx zusätzlich zu der Varnish Proxy konfiguration der Parameter Ssl-Offloaded „1“ gesetzt werden:

proxy_set_header Ssl-Offloaded "1";

2.
In der .htaccess Datei von magento wird der Header abgefragt:

SetEnvIf Ssl-Offloaded 1 HTTPS=on

3.
Im Magento unter System-> Configuration -> Web -> Secure muss der Offloader header Wert auf HTTP_SSL_OFFLOADED gesetzt werden. Die Base URL muss das https Protocoll verwenden.

The post Magento mit SSL und Varnish appeared first on LCube - Professional Hosting Blog.

Der Konfigurationsparameter recipient_bcc_maps wird dazu verwendet.

Szenario:

Alle Mails von Benutzer1 sollen automatisch per BCC an Benutzer Archiv geschickt werden.

Es wird eine Datei /etc/postfix/recipient_bcc angelegt:

benutzer1@meinedomain.de archiv@meinedomain.de

Mit postmap wurd eine Hash Datei erzeugt

postmap /etc/postfix/recipient_bcc

Damit Postfix diese Datei liest und berücksichtigt muss sie noch in der main.cf eingebunden werden:

recipient_bcc_maps = hash:/etc/postfix/recipient_bcc

The post BCC automatisch setzen mit Postfix appeared first on LCube - Professional Hosting Blog.

Es ist opensource und erfreut sich allgemeiner Beliebtheit.

Da Redmine sehr intensiv weiterentwickelt wird kommt es häufig vor, dass Updates eingespeilt werden müssen.

Um ein Upgrade von Redmine durchzuführne geht man wie folgt vor:

1. Sourcecode auf den aktuellen Stad bringen
   Wer den Quellcode per svn ausgecheckt hat kann sich glücklick schätzen denn hier ist das Upgrade sehr einfach:
   

   cd /ihr_redmine_ordner
   svn update

   Damit wird Redmine auf den aktuellen Stand Ihrer Vollversion aktualisiert z.B. von 3.1.1 auf 3.1.2
   Wenn Sie auf eine aktuelle Vollversion aktualisieren möchten verwenden Sie den switch Befehl:
   

   cd /ihr_redmine_ordner
   svn switch https://svn.redmine.org/redmine/branches/3.1-stable ./

   Hiermit werden alle Dateien auf den Stand der derzeit aktuellen 3.1 Version aktualisiert. Ihre settings werden dabei nicht überschrieben.
   Wer kein Subversion verwendet hat, kann z.B. fertige Pakete herunterladen und die in einen neuen Ordner entpacken. Danach /files, /plugins und Konfigurationdateien aus dem alten Ordner kopieren.
2. Nun müssen die notwendigen Gems nachinstalleirt bzw. aktualisiert werden
   

   bundle update

   Das Bundle Script aktualisiert bzw. installiert
3. Aktualisieren der Redmine Datenbank
   

   bundle exec rake db:migrate RAILS_ENV=production

   Führt das Script zum Migrieren der Datenbank aus
4. Aktualisieren der Redmine Plugin Datenbanken
   

   bundle exec rake redmine:plugins:migrate RAILS_ENV=production

   Migriert die Datenbanken der Plugins
5. Temporäre Dateien löschen
   

   bundle exec rake tmp:cache:clear tmp:sessions:clear RAILS_ENV=production

   Dadurch werden temporäre Sessions gelöscht.
6. Redmine Instanz neu starten

The post Upgrade von Redmine appeared first on LCube - Professional Hosting Blog.

Der schnelle Einstieg in die Programmiersprache sorgt für eine große Beliebtheit bei den Programmierern. Ob quick&dirty oder sauber objektorientiert. Alles ist möglich.

Große CMS oder Shopsysteme nutzen PHP. Module für verschiedene Datenbanksysteme stehen zur Verfügung um Daten aus PHP heraus zu verwalten.

Mit fast jedem PHP Update wurde die Programmiersprache schneller aber um gruße Shop mit tausenden von einzelnen PHP Dateien zu betreiben fehlt es teilweise doch noch an der nötigen Performance. Denn im Netz gilt: Je schneller eine Seite desto geringer die Absprungrate der Besucher.

Also wird um jede Millisekunde gefeilscht.

Es gibt verschiedene Ansätze um die Geschwindigkeit von PHP Anwendungen zu steigern:

1. Optimieren von Code
2. Caching von Daten
3. Caching von Code

Wir gehen davon aus, dass der Code optimal läuft da wir uns nur mit 1 und 2 beschäftigen wollen.

Caching von Daten

Um Daten zu cachen gibt es verschiedene Möglichkeiten. Anwendungen legen Daten im Dateisystem oder Speicher ab und greifen auf diese zu um sie nicht erneut berechnen zu müssen. Memcached wird dazu gerne verwendet. PHP kann über Memcached Daten im RAM Speicher ablegen und sehr schnell darauf zugreifen.

Varnish ist ebenfalls ein beliebter Seitencache. Damit brauchen Webseiten nicht bei jedem Aufruf neu berechnet zu werden sondern werden aus einem Cache heraus ausgeliefert.

Caching von Code

Eien PHP Datei wird vor jedem Ausführen in einen Bytecode übersetzt. Wenn man nun eine PHP Datei häufig benötigt könnte man diesen Bytecode auch in einen Cache ablegen um die Zeit des Übersetzens zu sparen (OpCode Cache).

Die PHP Beschleuniger können neben dem Cachen des Bytescodes auch noch Optimierungen vornehmen und die Geschwindigkeit nochmals zu steigern. Es gibt verschiedene OpCode Caches (eAccelerator, APC, Zend OpCache).

Was ist nun HHVM?

HHVM (HipHopVirtualMachine) ist ein eigenständiges Programm welches PHP Dateien zunächst in einen ByteCode übersetzt (HHBC). Dieser ByteCode wird dynamisch zur Laufzeit durch eienn  Jit Compiler in Maschinencode compiliert. Da HHVM hierzu eine eigene PHP Implementation hat werden ggf. nicht alle Funktionen der normalen PHP Version unterstützt.

Auf diese Weise kann eine PHP Anwendung innerhalb von HHVM um ein vielfaches schneller und ressourcensparender laufen als innerhalb eines normalen PHP Interpreters.

Möchten Sie einen HHVM Server nutzen? Kein Problem. Auf unseren Root-, Managed, SVN- und Git sowie Shophosting Servern können wir Ihnen gerne einen HHVM einrichten.

Wenn Sie Fragen haben schreiben Sie uns

The post HHVM schickt PHP Webseiten auf die Überholspur appeared first on LCube - Professional Hosting Blog.

Redundante Infrastruktur

Das wichtigste Konzept der Ausfallsicherheit von IT-Systemen ist und bleibt die Redundanz. Sämtliche Hardwarekomponenten sind mehrfach vorhanden, um defekte Teile sofort überbrücken zu können. Dazu wird zunächst eine leistungsfähige Enterprise Plattform benötigt, die ausreichende Hardwareressourcen zur Verfügung stellt, um einzelne Ausfälle ohne Einbußen bei der Performance kompensieren zu können. Eine redundante Infrastruktur ist jedoch deutlich mehr als nur ein Ersatzteillager. Redundanz bedeutet in der IT, dass defekte Komponenten ohne Betriebsunterbrechung automatisch überbrückt werden. Dazu muss nicht nur die Hardware redundant ausgelegt sein, sondern auch alle Daten und laufenden Prozesse müssen dupliziert werden. Ein angenehmer Nebeneffekt der Redundanz besteht darin, dass sämtliche Daten auch zwischen den Datensicherungen mehrfach vorhanden sind. Somit sind im Ernstfall auch neue Kundendaten, die seit der letzten Sicherung gespeichert wurden, nicht verloren. Natürlich ist die alte Regel, dass redundante Datenträger kein Backup ersetzen, weiterhin uneingeschränkt richtig. Aber redundante Datenträger können so manches Rollback ersparen, das immer mit Datenverlusten verbunden ist. Magento verfügt zwar über eine sehr gute Rollback-Funktion – aber nutzen möchte man sie doch lieber nicht!

Cloudhosting ist den Alternativen überlegen

Über welche Alternativen müssen wir hier überhaupt sprechen? Sicher nicht über den selbst betriebenen Server. Dieser Weg kommt allenfalls für große Unternehmen mit eigenem Rechenzentrum in Betracht. Für die Mehrzahl der Shopbetreiber kommt jedoch der interne Serverbetrieb ohnehin nicht infrage, weswegen die einzige wirkliche Alternative in der Anmietung eines realen Servers statt eines virtuellen Servers besteht. Das Rechnen in der Cloud kann in diesem Vergleich auf zahlreiche Vorteile verweisen. Hardwareressourcen unserer Enterprise Plattform können jederzeit bedarfsgerecht zugewiesen werden, außerdem garantieren wir in unserem Paket VMWare Gold eine extrem hohe Verfügbarkeit von 99,99 Prozent, die durch die Redundanz der Plattform ermöglicht wird. Der Unterschied zwischen 99,9 Prozent und 99,99 Prozent Verfügbarkeit ist übrigens keine reine Zahlenspielerei, an der nur Nerds ihren Spaß haben. Dieser Unterschied bedeutet knapp acht Stunden weniger Ausfallzeit pro Jahr – wie viele Kundenkontakte sind das bei Ihnen? Diesen zahlreichen Vorteilen steht als einzige Einschränkung gegenüber, dass das managed Cloudhosting keinen Root Zugriff erlaubt. Für Softwareentwickler kann das ein Problem sein, aber kaum für einen Shopbetreiber. Dafür werden Sicherheitsupdates im Betriebssystem automatisch eingespielt.

Einige Worte zur Datensicherheit

Nicht zuletzt durch eine indifferente Berichterstattung der Medien wird allein schon der Begriff „Cloud“ oft mit Datenschutzproblemen assoziiert. Bei genauerem Hinsehen wird schnell klar, dass die meisten der bekannt gewordenen Probleme nicht technischer Natur sind. Problematisch ist eher, dass viele große Anbieter amerikanischem Recht unterliegen und daher den US-Behörden Hintereingänge öffnen müssen. Aus technischer Sicht bieten professionelle Rechenzentren zweifelsohne einen besseren Schutz gegen externe Angriffe, als ein normales Unternehmen selbst gewährleisten könnte. Mit Cloud oder Nicht-Cloud hat das Ganze wenig zu tun, sondern nur mit können und wollen!

The post Vorteile einer Cloudumgebung für Magento appeared first on LCube - Professional Hosting Blog.

Die Domains werden von einer zentralen Registrierungsstelle verwaltet. Bei .de Domain macht dies z.B. die Denic. Möchte jemand nun eine Domain haben z.B. meinname.de kann deise Domain gegen eine jährliche Gebühr von der Denic gemietet werden. Dies geschieht in der Regel bei dem Hoster, der auch das Webpaket vermietet. Der Hoster verbindet dann die Domain mit dem Speicherplatz damit ein Aufruf der Domain im Webbrowser dann auch zu Ihren Speicherplatz führt.

Eine Domain wird nur vermietet und nicht gekauft d.h. im Falle von Problemen (z.B. Markenrechtsverletzungen) kann die Registrierungsstelle die Domain wieder von Ihnen zurückholen.

Wenn Sie mit den Leistungen Ihres Hosters nicht mehr zufrieden ist, die Domain jedoch behalten möchten, können Sie die Domain auch zu einem anderen Hoster umziehen. Für diesen Umzug sind einige Dinge zu beachten um einen schnellen und Reibungslosen Transfer zu garantieren.

Checkliste für einen erfolgreichen Domainumzug

Damit Sie keine Probleme beim Umzug haben, haben wir Ihnen hier eine Checkliste zusammen gestellt:

1. Sorgen Sie immer dafür, dass Ihre Daten, die bei der Registrierungsstelle der Domain hinterlegt sind, aktuell sind (E-Mail Adresse, Adresse, Telefon)
   Manche Registrierungsstellen senden Ihnen bei einem Umzug eine Bestätigungsmail. Wenn diese nicht Bearbeitet wird, ist kein automatischer Umzug möglich und es ist ggf. notwendig, dass Sie das Vorhaben per Fax authorisieren.
2. Besorgen Sie sich von Ihrem alten Webhoster den AuthCode Ihrer Domain.
   Viele Registrierungsstellen bieten eine automatischen Domaintransfer per AuthCodes. Sie authorisieren sich gegenüber der Registrierungsstelle über diesen AuthCode.
3. Nachdem Punkt 1 und 2 abgearbeitet sind, kann das neue Paket bestellt werden.
4. E-Mail Adressen im neuen Paket sowie Webseiten auf den neuen Speicherplatz umziehen
5. Domainumzug durch den neuen Hoster starten.
   Ein Domainumzug dauert ja nach Registrerungsstelle wenige Stunden bis einige Tage. Da mehrere Stellen bei einem Domaintransfer kooperieren müssen kann es leider immer wieder zu Wartezeiten kommen.

Nachdem der Domainumzug gestartet wurde, werden die Daten des alten Webhosters aus der Domain gelöscht und der neue Anbeiter Ihres Webpaketes trägt sich in die Domain ein damit der neue Speicherplatz bei dem Aufruf im Browser aufegrufen wird.

Dieser Vorgang (Änderung der DNS Daten) kann mehrere Stunden dauern. Die Registrierungsstelle ändert die DNS Daten und die verschiedenen Internetanbieter holen sich diese Daten in regelmäßigen Abständen ab. Es kann also sein, das einige die Webseite ebreits auf den neuen Server erreichen  und andere noch auf dem alten Server landen. I.d.R. ist der Vorgang jedoch innerhalb von 24 Stunden abgeschlossen und alle sollten die Seite bei dem neuen Anbieter erreichen.

Mögliche Probleme bei Domainumzügen

1. Die Adressdaten der Domain sind nicht korrekt. Bestätigungsmails konnten daher nicht empfangen und abgearbeitet werden.
   Setzen Sei sich mit Ihrem neuen Anbieter für Ihr Webpaket in Verbindung. Er kann Ihnen in dem Fall ggf. Faxformulare zur Verfügung stellen um den Domaintransfer manuell zu authorisieren.
2. Der alte Hoster gibt den AuthCode nicht raus.
   Es kann passieren, dass der alte Webhoster nicht mehr erreichbar ist und Sie deswegen nicht an den AuthCode kommen. In dem Fall bieten einige Registrierungsstellen die Möglichkeit über Ihren neuen Webhoster an den AuthCode zu kommen. Ggf. fallen dafür extra Kosten an.
3. Der AuthCode ist nicht korrekt
   Die AuthCodes sind in der Regel nur einge Wochen gültig.

The post Checkliste Domainumzug appeared first on LCube - Professional Hosting Blog.

Um dies zu bewerkstelligen gibt es zwei Möglichkeiten.

1. Der MySQL Server wird nach extern freigeschaltet der Benutzer bekommt externe Zurgiffsrechte
2. Man baut einen SSH Tunel zum MySQL Server auf

Punkt 1 muss vom Provider bzw. vom Verwalter der Webhosting Umgebung durchgeführt werden.

Punkt 2 können Sie selbst realisieren sofern Sie SSH Zugriff auf Ihr Paket haben. Bei unseren SVN Hosting, Shop Hosting und Server Angeboten ist das Standardmäßig inklusive.

Herstellen eines SSH Tunnels um sich mit einer Datenbank auf einem Root Server oder Managed Server zu verbinden

Per Linux:

Am einfachsten ist es über Linux

ssh [USERNAME]@[SERVERNAME] -L [LOKALER_PORT]:[HOST]:[REMOTE_PORT] 
ssh benutzer@mein-server.de -L 3306:dbserver.mein-server.de:3306

ssh logt sich also mit dem Benutezrnamen „benutzer“ auf dem Server mein-server.de ein. Lokal wird der Port 3306 geöffnet.

Alles was an den lokalen Port 3306 geschickt wird, leitet ssh über den Tunnel an dbserver.mein-server.de:3306 weiter.

Man kann sich also lokal per mysql -h 127.0.0.1 mit der Datenbank verbinden.

Per Windows (Putty)

Hier muss unter Connections->SSH->Tunnels lediglich der Port eingestellt werden.

Nach dem Klick auf open wird die gewählte SSH Verbindugn geöffnet und ein Tunnel hergestellt.

Eine Verbindung an Port 3306 würde also über den Tunnal an den dbsrv.mein-server.de Port 3306 weitergeleitet werden.

Man muss lediglich darauf achten, dass der lokale Port nicht bereits vergeben ist z.B. durch eine eigene lokale MySQL Installtion.

The post MySQL per SSH Tunnel zu einem Root- oder Managed-Server appeared first on LCube - Professional Hosting Blog.

Da dies eien sehr allgemeine Aussage ist, klärte der zuständige Mitarbeiter erstmal mit dem Kunden ab, wie sich das Geschwinigkeitsproblem äussert.

Trotz Varnish Cache, Memcached, APC kam es zu gelegentlichen hängern, die teilweise sogar die Datenbank lahm legten.

Bei einem Magento Hosting kommt es auf das Zusammenspiel aller Komponenten an

Die Analyse ergab, dass das Problem regelmäßig auftrat. Nach einiger Zeit kam es zu einem Stillstand des MySQL Servers da dieser mit Anfragen auf die Tabelle category_catalog_flat_store so beschäftigt war, dass er keine anderen Anfragen beantworten konnte. Die Laufzeiten für die Abfrage steigerte sich von 1,5 Sekunden auf teilweise über 100 Sekunden.

Der Varnish Cache hat zwar einiges puffern können jedoch ist auch der Cache irgendwann abgelaufen. In dem Fall wird dann die Seite neu berechnet. Wenn die Trägheit z.B. durch ein aufwändiges Menü erzeugt wird, muss das Menü für alle Benutzer, die in dem Augenblick online sind, neu berechnet werden. So kann es auf einen Schlag zu 20, 30 oder mehr aufwenigen Abfragen kommen. Wenn diese Abfragen dann lange dauern potenziert sich das Problem. Während der DB Server damit beschäftigt ist, laufen neu Abfragen auf, die dann in der Queue landen. So läuft innerhalb von wenigen Sekunden die Datenbank voll, bis nichts mehr geht.

Es wurden dann falsche Indexfelder in der category_catalog_store_flat Tabelle sowie der core_url_rewrites ausgemacht, die Abfragezeiten von mehreren Sekunden erzeugten. Nach dem Zurücksetzen der Indexfelder war die Laufzeit wieder bei wenigen Millisekunden.

Der Kunde bemerkte zwar die Verbesserung bemängelte jedoch weiterhin eine Trägheit, die zwar nicht mehr so schlimm war aber trotzdem nicht in Ordnung.

Oftmals befinden sich im Magento Store mehrere Fehler

Nachdem das Laufzeitverhalten mit NewRelic weiter analysiert wurde konnten am Quellcode und ind er Datenbank keine Probleme gefunden werden.

Das finden mehrere Fehler macht die Analyse immer sehr schwierig. Man hat einen Fehler gefunden und kommt nicht zum erwünschten Ziel. Es erfordert dann viel Erfahrung um trotzdem Fehler für Fehler zu finden.

Nachdem als zusätzliche Fehlerquelle der Memcached identifiziert wurde, und dieser neu gestartet wurde war das Problem jedoch behoben. Magento hat offensichtlich etwas im Memcached abgelegt was zu langen Laufzeuten geführt hat.

The post Magento Hosting ist sehr langsam appeared first on LCube - Professional Hosting Blog.

Nach einiger Analyse wurde klar, dass das Plugin SEO Auto Link & Related Posts (SEO-ALRP) dafür verantwortlich war.

Nachdem das Plugin deaktiviert wurde, war das pstarttag verschwunden.

Im Quelltext sah man, dass # pstarttag# eigentlich durch <p> ersetzt werden sollte. Warum passiert das nicht?

Nachdem ich mir den Seitenquelltext angesehen habe war es klar. Im # pstarttatg# hat sich ein Link eingeschmuggelt statt # pstarttag# stand dort dann #<a href=““></a>pstarttag#. Somit funktionierte das str_replace nicht mehr.

Nach der Analyse der Konfigurationseinstellungen vom SEO-ALRP kam ich auf die Liste der manuellen Links im Menupunkt Auto Links. Hier kann man Keywords angeben, die im Post automatisch verlinkt werden. Diese Links werden Zeile für Zeile in eine Textarea angegeben. Wenn man jedoch nach der letzten Zeile Enter drückt und somit eine leere Zeile vorhanden ist, kommt es zu dem oben beschriebenen Phänomen.

Also einfach die leere Zeile im Texteld für die manuellen Links löschen und das # pstarttag# ist verschwunden.

The post Am Anfang jedes Posts steht #pstarttag# appeared first on LCube - Professional Hosting Blog.