Grunt concurrent und time-grunt

Datum: 29. September 2016
Autor*in: Florian Müller


Gestern Abend bin ich auf einen Artikel gestoßen, welcher sich mit der Optimierung von Grunt Tasks beschäftigt hat. Vieles davon ist schon im Einsatz, aber eins hat dann doch noch gefehlt – die Parallelisierung. Dies habe ich heute morgen testweise bei einem Projekt integriert. Um vergleichbare Ergebnisse zu bekommen, welche unabhängig von anderen Build Tasks des Build Scripts sind, habe ich time-Grunt zum Einsatz gebracht.

Um Time-Grunt zu verwenden, muss der Task einmal via NPM installiert werden (npm install time-grunt --save-dev) und zum Gruntfile hinzugefügt werden (require('time-grunt')(grunt);). Das war es schon. Nun zeigt Grund nach allen Tasks eine Übersicht der Zeiten aller Tasks und die Gesamtzeit an.

Execution Time (2016-09-29 08:29:35 UTC+2)
loading tasks               2.1s  ▇▇▇ 9%
lesslint:src                5.9s  ▇▇▇▇▇▇▇▇▇ 24%
jshint:scripts              1.5s  ▇▇▇ 6%
jasmine:src                 1.4s  ▇▇ 6%
less:production             4.1s  ▇▇▇▇▇▇ 17%
uglify:production           5.3s  ▇▇▇▇▇▇▇▇ 22%
imagemin:dist               1.3s  ▇▇ 5%
filerev_replace:production  2.6s  ▇▇▇▇ 11%
Total 24.5s

Nun konnte ich mit der Parallelisierung der Grunt Tasks beginnen. Hierzu kam grunt-concurrent zum Einsatz. Um eine Vergleichbarkeit zu haben, habe ich den Grunt build Task mehrfach ausgeführt. Die Zeiten waren wie folgt:

  • 25.6s
  • 24.5s
  • 24.6s

Mittelwert: 24.9s

Nun habe ich Concurrent integriert. Die Syntax ist dabei denkbar einfach. Es werden einfach alle Tasks, die gleichzeitig lauten sollen, in ein Array geschrieben.

module.exports = {
  production: [
    'less:production',
    'uglify:production',
    'copy',
    'imagemin'
  ]
};

Nun wurde in der aliases.js der entsprechende Part durch concurrent ersetzt. Der Deployment Task sieht somit folgendermaßen aus:

...
  build: {
    ...
    tasks: [
      'test',
      'clean',
      'concurrent:production',
      'filerev',
      'filerev_replace',
      'filerev_assets',
      'usebanner'
    ]
  },
...

Hierbei war schon eine große Performance Optimierung von knapp 5 Sekunden zu bemerken. Klingt nicht viel, ist aber in Prozent ausgedrückt 20%.

  • 19.5s
  • 19.6s
  • 19.7s

Mittelwert: 19.6s

Nun ging es noch einen Schritt weiter. Ich habe zusammen mit Benni geschaut, welche Tasks man noch parallelisieren kann. Dabei kamen wir noch auf die Tests. Dazu habe ich die concurrent.js erweitert.

...
  test: [
    'lesslint',
    'jshint',
    'jasmine'
  ]
...

Dies wurde dann noch in die aliases.js eingetragen (concurrent:test).

Die Tests auf dem DEV ergaben folgende Ergebnisse:

  • 19.6s
  • 19.4s
  • 22.6s
  • 20.1s
  • 19.8s
  • 19.2s
  • 19.6s
  • 19.3s

Mittelwert: 19,95s

Auffällig hier sind die Ausreißer nach oben. Hier kann ich nur vermuten, dass diese durch zusätzliche Belastung des DEV kamen. Lässt man diese nun außen vor (19.8s-22.6s), so kommt man auf einen Mittelwert von 19.42 Sekunden. Wenn ein Test fehlschlägt, bricht sofort die ganze Abarbeitung an der Stelle ab und auch die anderen parallel laufenden Tasks werden gestoppt.

Insgesamt haben wir hiermit eine Performance Optimierung von 5,48 Sekunden.

Man muss Aufpassen, wenn man parallelisiert. Jeder Grunt Prozess lädt nochmals alle Tasks. Dies dauerte im Test jeweils 2.1s. Das muss man einrechnen, ob dann noch ein Performance Gewinn vorhanden ist. Auch kann nicht jeder Task parallel ablaufen, da sie aufeinander aufbauen oder beispielsweise nur durchgeführt werden dürfen, wenn der vorherige erfolgreich war (beispielsweise Löschen des dist Ordners darf nur passieren, wenn die Tests erfolgreich waren, damit immer gültiges JS und CSS vorhanden ist auf dem DEV).

Quelle: http://www.html5rocks.com/en/tutorials/tooling/supercharging-your-gruntfile/


Dieser Artikel wurde verschlagwortet unter:


Kommentare

Selber kommentieren:






Weitere Beiträge zum Thema Technologie


Browser Diet

Autor*in: Benjamin Hofmann


Technologie


Eben bin ich über t3n auf eine interessante Website gestoßen: Browser Diet. Hier geht es darum, wie der Name bereits vermuten lässt, wie man Websites im Browser beschleunigen kann. Einiges davon machen wir bereits seit einiger Zeit, einiges nicht. Ein paar Beispiele dafür sind folgende Punkte: http://browserdiet.com/#cache-array-lengths Ein viel gemachter Fehler, auch in PHP, da …


Beitrag lesen
27
MRZ
13

Marzipano – a 360° viewer for the modern web

Autor*in: Benjamin Hofmann


Projekte   //   Strategie & Konzeption   //   Technologie


Marzipano Alt
Beschreibungstext Beschreibungstext

Im Zuge einer Aufwandsschätzung für zur Einbindung von 360°-Panoramen, die vom Kunden selbst erstellt und eingebunden werden können, bin ich auf Marzipano gestoßen. Ein Skript, welches das mit Bravour erledigt und mit 55 KB Dateigröße (komprimiert) auch einen relativ kleinen Footprint hat. Das Tool wird übrigens von Mitarbeitern von Google entwickelt, ist aber kein offizielles …


Beitrag lesen
16
JAN
17

imx.ContentDelivery API meets Lechradweg

Autor*in: Christine Pfleger


Projekte   //   Technologie


Wer sich im Alltag nicht täglich mit Datenbanken und Schnittstellen beschäftigt, tut sich zugegebenermaßen schwer zu verstehen, warum unsere Entwickler bei der imx.ContentDelivery API ins Schwärmen kommen. Wir haben daher den Senior Entwickler Benjamin Hofmann und den Technischen Geschäftsführer Christian Heindl gebeten, am Beispiel des aktuellen Lechradweg-Projekts so praxisbezogen wie möglich die Vorteile der imx.ContentDelivery API aufzuzeigen.


Beitrag lesen
18
OKT
22

Probleme mit Hochkommas in Produktliniennamen

Autor*in: Darian Dragut


Projekte // Technologie


Nach dem Basis-Setup der imx.Platform Instanz für Chiemgau wurde ich mit einem merkwürdigen Fehler konfrontiert. Sowohl in den Suchen für Stämme und Angebote als auch in deren Pflegemasken wurde der Produktlinienbaum nicht angezeigt. Noch merkwürdiger erschien mir der Fehler, nachdem ich feststellte, dass die Produktlinien in der Produktlinien-Administration hingegen problemlos angezeigt werden. Da keinerlei Fehler …


Beitrag lesen
02
DEZ
15