chefkoch goes drupal8
TRANSCRIPT
Insert company logo
PHP
Chefkoch goes Drupal8Per Bernhardt
Per Bernhardt 30.09.2016
Ich bin Per.@perprogramming
Ich arbeite bei Chefkoch.
• Das „CMS-Projekt“ • Drupal8
• Ökosystem • Kernfeatures • Konfiguration • Software-Architektur & Code
• Herausforderungen • Migration • SEO • QA • Integration in die nativen Apps • Performance & Deployments
• Fazit • Q & A
Das „CMS-Projekt“
Unser Magazin.ca. 6000 Artikel
ca. 40.000 Bilder 15 RedakteurInnen
ca. 2 Mio. monatliche Leser
• Wir wollen ein neues CMS, am liebsten von der Stange!
• Wir wollen ein neues CMS, am liebsten von der Stange!
• Wir wollen ein responsives Design!
• Wir wollen ein neues CMS, am liebsten von der Stange!
• Wir wollen ein responsives Design!
• Wir wollen den gesamten Magazin-Content in den nativen Apps!
• Wir wollen ein neues CMS, am liebsten von der Stange!
• Wir wollen ein responsives Design!
• Wir wollen den gesamten Magazin-Content in den nativen Apps!
• Wir wollen tolle neue Features und Widgets!
• Wir wollen ein neues CMS, am liebsten von der Stange!
• Wir wollen ein responsives Design!
• Wir wollen den gesamten Magazin-Content in den nativen Apps!
• Wir wollen tolle neue Features und Widgets!
• Es darf nichts kaputt oder verloren gehen…
Drupal 8
Ökosystem
• Open Source
• Open Source
• PHP
• Open Source
• PHP
• Version 8 basiert auf Symfony Components
• Open Source
• PHP
• Version 8 basiert auf Symfony Components
• 8.0 Release Ende 2015
• Open Source
• PHP
• Version 8 basiert auf Symfony Components
• 8.0 Release Ende 2015
• Community > 1.000.000, Entwickler > 36.000
• Open Source
• PHP
• Version 8 basiert auf Symfony Components
• 8.0 Release Ende 2015
• Community > 1.000.000, Entwickler > 36.000
• Modules Version 7 > 10.000, Version 8 > 2.000
Kernfeatures
Nodes
Nodes Terms
Nodes Terms Files/Media
Konfiguration
./drush config-export
./drush config-import
Software Architektur & Code
Herausforderungen
Migration
SEO
QA
Integration in die nativen Apps
X-Chefkoch-Native-App: 1
X-Chefkoch-Native-App: 1
Performance & Deployments
• ca. 2 Millionen Unique Visitor pro Monat
• ca. 2 Millionen Unique Visitor pro Monat
• ca. 50 Millionen PageImpressions pro Monat
• ca. 2 Millionen Unique Visitor pro Monat
• ca. 50 Millionen PageImpressions pro Monat
• ~ 20 Requests / Sekunde
• 300 - 400 SQL Queries pro Seite (ungecached)
• 300 - 400 SQL Queries pro Seite (ungecached)
• Content + Config in DB
• 300 - 400 SQL Queries pro Seite (ungecached)
• Content + Config in DB
• Unbedingt APCu, sonst Config jedes mal aus DB
• 300 - 400 SQL Queries pro Seite (ungecached)
• Content + Config in DB
• Unbedingt APCu, sonst Config jedes mal aus DB
• Dynamic Cache
• 300 - 400 SQL Queries pro Seite (ungecached)
• Content + Config in DB
• Unbedingt APCu, sonst Config jedes mal aus DB
• Dynamic Cache
• Und dann?
• Hohe TTL (> 24h)
• Varnish Grace Mode (Stale-While-Revalidate + Stale-While-Error)
• Hohe TTL (> 24h)
• Varnish Grace Mode (Stale-While-Revalidate + Stale-While-Error)
• Modules „purge“ + „varnish-purge“
• Hohe TTL (> 24h)
• Varnish Grace Mode (Stale-While-Revalidate + Stale-While-Error)
• Modules „purge“ + „varnish-purge“
• https://www.drupal.org/project/varnish
Drupal Response Header:
X-Drupal-Cache-Tags: node:123 term:456 media:789 …
BAN-Requests von Varnish-Purge
X-Drupal-Cache-Tags: node:123X-Drupal-Cache-Tags: term:456X-Drupal-Cache-Tags: media:789
Fazit
• Projektumfang nicht optimal
• Projektumfang nicht optimal
• Software-Architektur & Code-Qualität ausbaufähig
• Projektumfang nicht optimal
• Software-Architektur & Code-Qualität ausbaufähig
• Die ersten 80% sind schnell gemacht, aber dann…
• Projektumfang nicht optimal
• Software-Architektur & Code-Qualität ausbaufähig
• Die ersten 80% sind schnell gemacht, aber dann…
• Performance ist schwierig
• Projektumfang nicht optimal
• Software-Architektur & Code-Qualität ausbaufähig
• Die ersten 80% sind schnell gemacht, aber dann…
• Performance ist schwierig
• Unsicher, wohin unsere Reise geht…
