Magento EE. die größten Herausforderungen

Transkript

1 Internationalisierung mit Magento EE die größten Herausforderungen und unsere Lösungsoptionen

2 Vorstellung der Sprecher Ulf Dammertz mytheresa.com: Head of IT 12 Jahre im ecommerce tätig Otto Group ITELLIUM (Quelle) mytheresa.com Michael Staroste mytheresa.com: Lead Engineer 10 Jahre Erfahrung in der Programmierung ITELLIUM (Quelle) mytheresa.com Stefan Bothner mzentrale: Entwickler und GF 1 3 J a h r e E r f a h r u n g i n d e r W e b p r o g r a m m i e r u n g M i t b e g r ü n d e r d e r m z e n t r a l e ( S t u t t g a r t )

3 Worum geht es in diesem Vortrag? Herausforderungen durch das Geschäftsmodell von mytheresa.com Hohe Komplexität bei relativ geringem Volumen Standardlösungen passen praktisch nie Kundenservice ist ein absoluter Fokus Jede (!) Bestellung zählt Herausforderungen bei der Umsetzung mit Magento EE Viele sehr gute Grundlagen aber auch einige Unvollkommenheiten Wir wollen unsere besonderen Problemstellungen und deren Lösung skizzieren

4 AGENDA 1. Was ist mytheresa.com Systemstruktur 2. Caching 3. Staging 4. Content-Pflege

5 Was ist mytheresa.com?

6 Shop

7 I n s p i ra t i o n

8 Luxus

9 International > 130 Mitarbeiter aus... Deutschland Frankreich Italien England Australien USA Ecuador

10 Technisch Aufwändig mytheresa.com MS Dynamics NAV (ERP) Magento EE Cores GB Storage 72 Webserver Cores 48 DB Cores GB Storage CDN (Akamai)

11 Caching

12 Anforderungen Typische Anfragen von Designern Nehmen Sie meine Artikel bitte aus dem Italienischen Geschäft. Sie können meine Artikel überall verkaufen. Bis auf die Schuhe, die bitte nicht in Japan. Mein Artikel kostet im Flagship-Store in New York X USD, bitte entsprechend anbieten. 11 Websites mit 20 Storeviews

13 Probleme des Standards Während den Indexierungen befindet sich die Website häufig in undefinierten Zuständen Diese werden dann gecached Configcache baut sich unter Last nicht auf Permanente Neugenerierung Besonders problematisch bei Clustersystemen

14 Lösungsansatz: Systemaufbau Mehrstufiges Caching Nutzung selbständig skalierender Dienste (CDN) Varnish-Caching im Loadbalancer Ziel: Reduzierung teurer DB Anfragen CDN Loadbalancer Redis Webserver Datenbank

15 Produktdetailseite Pro Sprache Global für alle Stores Pro Website

16 Technische Details Reorganisation von Catalog Blocks, logische Organisation nach Wiederverwendbarkeit Welche Identifier verursachen unterschiedliche Inhalte? Website / Sprache / URL Lokaler Redis auf jedem Webserver als Fast-Cache-Backend (Block-Cache) Laden dynamischer Inhalte innerhalb von Seiten via ESI:Include (Varnish) AJAX (Client) Applikation steuert die individuellen Cachelifetimes im Varnish

17 Ergebnis im globalen Durchschnitt Generierungszeiten um 500 ms Ladezeiten beim Client unter 4 Sekunden Titel der Präsentation

18 Staging

19 Anforderungen Staging Sehr viele Beteiligte am Produktionsprozess Fashion-Nerds Knappe Timelines Artikel Fotos Kurze Zyklen Content Kategorien Editorials Videos Erst auf dem Stager können alle Inhalte gemeinsam geprüft werden Allgemeine Komplexität 20 Storeviews Über Artikel mit mehr als Variationen

20 Probleme des Standards Keine echte Trennung von Staging und Live Buggy Z.B. Staging von Attributen Kein Monitoring Durchführung komplett manuell Vorhandene Automatisierung nicht praktikabel Langsam Lange Downtime

21 Pack Transfer Unpack Switch Live Staging Zwei getrennte Systeme Eigener Server Eigenes DB-Schema

22 Pack Transfer Unpack Switch CMS- Seiten Media- Daten DB Dump Reindex des Stagingsystems Dump der relevanten Daten aus der Staging-DB Packen der Media-Daten Packen der CMS-Seiten

23 Pack Transfer Unpack Switch Live Staging Transfer der Inhalte auf das Livesystem (Expect Script)

24 Pack Transfer Unpack Switch DB Files Import der DB Dumps in Schattentabellen Kopieren der Files in Schattenverzeichnisse

25 Pack Transfer Unpack Switch Switch der DB-Tabellen DB Files Switch der Verzeichnisse Flushen der Caches Downtime ca. 2 Minuten DB Files

26 Staging Backend

27 Content Management

28 Anforderungen Pflege direkt durch die Fachabteilungen Nicht durch eine Redaktion Technisch so flach wie möglich Dadurch flexibel Vererbung als Konzeptgrundlage Simple GUI, Übersichtlichkeit Workflow für Abnahme Zugriffsteuerung nach Bereichen

29 Probleme des Standards Verwendung von Tiny MCE Vererbung nur von ganzen Seiten Für Entwickler konzipiert Z.B. keine Strukturierung Keine differenzierte Zugriffssteuerung

30 KISS - Struktur Ein Template pro Seite Komplexer Seitenaufbau Simple Pflege Das Template enthält Formatierungen Skripte Platzhalter Die DB enthält Text Bildreferenzen Links Jeder Bestandteil wird einzeln gepflegt Texte Bilder Links Ein Template je Seite

31 Farbliche Kennzeichnung der Textherkunft Default Inhalt Spezifischer Inhalt Default Inhalt

32 Flache GUI mit wenig Fehlerpotential Formatierungen innerhalb der Elemente sind weitestgehend ausgeschlossen Textfeld zur Vermeidung versehentlich kopierter Formatierungen Parser entfernt jegliche html-tags

33 Inhalte und Vererbung Inhalte werden aus dem Default Channel geerbt Einzelne Teile können pro Website verändert werden Individuelle Inhalte und solche aus dem Default werden unterscheidbar dargestellt Default Website Store 1 Store 2 Store 3 Store 4 Website 1 Website 2 Store 1 Store 2 Store 1 Store

34 Logischer Ablauf: Shop und CMS Rendering eines Static Blocks / Page CMS- Content vorhanden? ja Externen Content rendern nein Eigenen Inhalt rendern

35 Fazit

36 Unser Fazit nach 2½ Jahren Magento-EE Mit etwas Tuning am Gesamtsystem ist die Performance sehr gut sind auch komplexe Sites gut abbildbar Was kann die Enterprise Edition besonders gut? Channels und Sites Eine Basis für interessante Projekte sein Was war für und nicht ausreichend? Stagen Cachen Supporten Optimales Entwicklungs-Setup Eigene Entwickler konsequent fördern Erfahrene Agentur als Unterstützung suchen

37 VIELEN DANK!

38 Backup

39 Bestand: Besonderheit bei mytheresa.com Neben besonderer Qualitätsansprüche lebt Luxus vom knappen Angebot Daher sind Stückzahlen von 1-3 Stück pro Größe der Normalfall Die meisten Systeme gehen eher großzügig mit den Beständen um, so auch Magento... Ein im Shop verkaufter Artikel, der später nicht ausgeliefert werden kann ist: Eine Katastrophe für den Service Ein Thema für die Geschäftsführung Zum Glück jetzt sehr selten geworden (<1 x Pro Monat)

40 Bestand: Probleme des Standards Das Magento-System wundert sich an vielen Stellen darüber, dass ein anderes System für Bestände verantwortlich ist Wackelige Bestandsimporte ohne relevantes Fehlerhandling Cancels aus jeglichem Status erhöhen die Bestände ohne vorgesehene Prüfung Keine vorgesehenen Methoden zum Bestandsabgleich abseits von Massentransfers Inkrementelle Updates aktualisieren den Artikel unsauber Während der Aktualisierung des Index sind die aktualisierten Artikel ausverkauft Hier wurde das Caching komplett außer acht gelassen

41 Bestand: Lösungsansatz Der Shop verwaltet die Bestände relativ Autark Bestandsreduzierungen innerhalb der ERP werden via Webservice gemeldet Alle 2 Min Getriggert von Magento Das inkrementelle Updaten wurde überarbeitet: Es werden nur die betroffenen Größen aktualisiert, nicht das gesamte Produkt wie im Standard Die Updates erfolgen direkt in Index und Bestandstabelle Raw SQL Die Cancels wurden überarbeitet Nur Cancels bestimmter Status erhöhen den Bestand Blocken von Bestandsimporten Befindet sich ein Artikel in einem Bestellvorgang (pending payment) werden keine inkrementellen Updates für diesen durchgeführt. Das Update erfolgt zu einem späteren Zeitpunkt getriggert durch die ERP