Travis - A sebesség igénye

Valószínű, hogy már használod a Travis-t vagy egy másik klassz CI-t a tesztek futtatásához, és mindenki udvariasan vár a CI ellenőrzésekre, mielőtt egyáltalán gondolna a merge-re, ugye? Valószínűbb, hogy a várakozás fájdalmassá válik, és rákattintasz a merge-re: triviális változtatás és most kell. Ha ez gyakran megtörténik, akkor azok felelőssége, akik azon a szkripteken dolgoztak, amiket a Travis rág át, hogy változtatásokat hajtsanak végre. Van néhány triviális és nem annyira triviális lehetőség, hogy a csapat mindig hajlandó legyen várni a befejezésre.

Ez a blogbejegyzés neked szól, ha van egy Travis integrációval rendelkező projekted, és szeretnéd karbantartani és optimalizálni, vagy csak kíváncsi vagy, mi lehetséges. Más CI eszközök felhasználói, olvassatok tovább, sok terület vonatkozhat a ti eseteitekben is.

Más teljesítményoptimalizálási területekkel ellentétben az előtte-utána benchmark készítés nem annyira döntő fontosságú, mivel a Travis leginkább gyűjti az adatokat, csak annyit kell tenned, hogy elvégzed a számolást és büszkén bemutatod a számokat.

Gyorsítótárazás

Kezdésként, ha a .travis.yml-edből hiányzik a cache: direktíva, akkor a legkönnyebb helyen kezdhetsz: a függőségek gyorsítótárazása. Egy Drupal-alapú projekthez jó ötlet gondolni az összes modul és könyvtár gyorsítótárazására, amelyeket le kell tölteni a projekt felépítéséhez (használ buildsystem-et, ugye?). Tehát akár egy variánsa:

cache:
  directories:
    - $HOME/.composer/cache/files

vagy Drush-hoz

cache:
  directories:
    - $HOME/.drush/cache

Jól el van magyarázva a részletes dokumentációban a Travis-ci.com-on. Mielőtt a szkript végrehajtódik, a Travis automatikusan feltölti a cache könyvtárakat egy korábbi sikeres build-ből. Ha a projektednek csak néhány csomagja van, nem fog sokat segíteni, sőt, lassíthatja is a dolgokat. Ami kritikus, az az, hogy lassú generálású, könnyen letölthető anyagokat kell gyorsítótáraznunk. Egy nagy ZIP fájl gyorsítótárazása például nem lenne értelmes, sok kicsi gyorsítótárazása több eredeti szerverről viszont előnyösebb lenne.

Ettől a ponttól olvashatnád a standard dokumentációt e blogbejegyzés helyett, de van még hab a tortán számodra. Egy Drupal telepítés több percig is eltarthat, inicializálva az összes modult, végrehajtva az install profile logikáját és így tovább. A Travis elég kedves ahhoz, hogy madártávlati képet adjon arról, mi eszi a build időt:

Figyelj a szűk keresztmetszetre, amikor döntést hozol arról, mit és hogyan gyorsítótárazz.

Számunkra ez a telepített, inicializált Drupal adatbázis és a teljes document root gyorsítótárát jelenti. A cache invalidáció nehéz, ezen nem tudunk változtatni, de jó kompromisszumnak bizonyult a bonyolultság és a végrehajtási sebesség növekedés között, nézd meg a példáinkat:

• pre_cache.sh
• post_cache.sh

Végezd el a házi feladatot és gyorsítótárazd, ami a leginkább erőforrás-igényes generálni, SQL adatbázis, épített forráskód vagy fordított bináris, a Travis itt van, hogy segítsen ebben.

Szoftver verziók

Két ok van, amiért érdemes figyelni a szoftver verziókra.

Használj előre telepített verziókat

A Travis különböző disztribúciók konténereit használja, tegyük fel, hogy trusty-t használsz, ami manapság az alapértelmezett, akkor ha a PHP 7.0.7-et választod, az előre telepített, 7.1 esetén külön le kell tölteni, és ez minden egyes build-nél időbe telik. Amikor production korlátozásaid vannak, az szinte biztosan fontosabb az egyeztetéshez, de néhány esetben az előre telepített verzió használata felgyorsíthatja a dolgokat.

És ráadásul, tegyük fel, hogy MariaDB-t preferálod a MySQL helyett, akkor ne sudo-zz és kezdd el telepíteni a csomagkezelővel, mivel van az add-on rendszer, ami elérhetővé teszi. Ugyanez vonatkozik a Google Chrome-ra és így tovább. Maradj annál, ami már benne van az image-ben, ha tudsz. Használd ki a Travis YML definíción keresztül lekérhető lehetőségeit!

Használd a legújabbat és (vagy) legjobbat

Ha valaha olvastál egy cikket a PHP 7-re való átállás teljesítménynövekedéséről, érzed a verziók gondos kiválasztásának fontosságát. Ha a build-ed PHP-végrehajtás nehéz, a PHP 7.2 lekérése (ez egy újabb ugrás, de figyelj a visszamenőleges inkompatibilitásokra) teljesen értelmes lehet, és olyan egyszerű, amilyen csak lehet, miután a kódod kompatibilissé tetted:

language: php
php:
  - '7.2'

Majdnem biztosan hasonlót lehetne írni a Node.js-ről, vagy a relációs adatbázisokról stb. Ha tudod, mi a szűk keresztmetszet a build-edben és megtalálod a legjobban teljesítő verziókat – újabbakat vagy régebbieket – javítani fog a sebességeden. Ütközik ez az előző ponttal az előre telepített verziókról? Nem igazán, csak mérd meg, melyik segíti a build-edet a legjobban!

Tedd párhuzamossá

Amikor egy Travis job fut, 2 mag és 4 GByte RAM elérhető – erre lehet támaszkodni! A csomagok letöltésének párhuzamosan kell történnie. A drush make, gulp és más hasonló eszközök eleve használhatják: ellenőrizd a paramétereidet és konfigfájljaidat. Azonban magasabb szinten, tegyük fel, hogy szeretnél unit tesztet és böngésző-alapú tesztet is végrehajtani. Megkérheted a Travis-t, hogy két (vagy több) konténert indítson egyidejűleg. Az elsőben telepítheted a unit teszt függőségeket és végrehajthatod; a második csak a funkcionális tesztről gondoskodhat. Egy finomhangolt példánk van erre a megközelítésre a Drupal-Elm Starter-ünkben, ahol 7 konténert használunk különböző teszteléshez és linting-hez. A nagyszerű végrehajtási sebesség csökkenés mellett az előnye az, hogy az eredmény is finomabb, egyetlen boolean érték helyett, csak a build ellenőrzésével áttekintésed van arról, mi lehet elromolva.

Összességében jó érzés, hogy a Travis szívesen létrehoz ennyi konténert a szerény projektedhez:

Használd ki a RAM-ot

Az elérhető memória jelenleg 4 és 7.5 GByte között van, a konfigurációtól függően, és ezt a lehető legjobban ki kell használni. Egy példa lehet az adatbázis fő munkakönyvtárának memória-alapú fájlrendszerre helyezése. Sok egyszerűbb projektnél ez teljesen megvalósítható, és legalábbis Drupal esetén szilárd gyorsulás. Mondanom sem kell, van példánk, és ügyfél projekteken 15-30%-os javulást láttunk SimpleTest végrehajtásnál. Hagyományos RMDBS-ekhez kipróbálhatod. Ha az adatbázisod nem fér el a memóriában, még mindig kérheted az InnoDB-t, hogy töltse meg a memóriát.

Gondolkodj a felhasználási eseten – akár a teljes document root odahelyezése is legitim lehet. Ha forráskódot kell fordítanod, annak ott végzése is értelmes.

Építsd meg a saját Docker image-edet

Ha a projekted igazán egzotikus vagy legacy, potenciálisan értelmes lehet a saját Docker image-ed karbantartása, majd letöltése és végrehajtása a Travis-ben. A múltban csináltuk, majd átalakítottuk. A saját image-ed karbantartása visszatérő erőfeszítést jelent, harcot elavult verziókkal, elérhetetlen függőségekkel, erre számíts. Mégis, ez is lehet a teljesítményoptimalizálás egy típusa, ha sok szoftver függőséged van, amelyeket nehéz telepíteni a jelenlegi Travis konténer image-eken.

+1 - Hibakeresés könnyedén

A Travis integráció különböző fejlesztésein való munkához a projektjeidben kötelező a problémák gyors észlelése. Ami a localhost-on működött, lehet, hogy működik, lehet, hogy nem működik a Travis-en – és gyorsan tudnod kell a kiváltó okot.

A múltban videó rögzítést propagáltunk, most mást ajánlanék. Van egy webalkalmazásod, minden backend hibához van eszköz a logok eléréséhez, Drupal-nál használhatod a Drush-t. De mi van a frontend-del? A Headless Chrome klassz, beépített hibakeresési képességgel rendelkezik, amelyek közül a legjobb az, hogy kitörhetsz az Ngrok segítségével. X11 forwarding nélkül (ami nem elérhető) vagy helyi hack nélkül a Travis utánzásához, játszhatsz az alkalmazásoddal a Travis környezetben futva. Mindössze annyit kell tenned, hogy végrehajtasz egy Debug build-et, végrehajtod a telepítési részt (travis_run_before_install, travis_run_install, travis_run_before_script), elindítod a Headless Chrome-ot (google-chrome --headless --remote-debugging-port=9222), letöltöd az Ngrok-ot, elindítasz egy tunnelt (ngrok http 9222), meglátogatod a nyilvánossá tett URL-t a helyi Chrome-oddal és élvezed az inspektálást, debugger konzolt és mást.

Tanulság

Az ilyen fejlesztéseken való munka sokféle előnnyel jár. Az egész fejlesztői csapat élvezheti a rövidebb sorokat és gyorsabb merge-eket, és továbbléphetsz és a fejlesztések egy részét alkalmazhatod a helyi környezetedre, különösen ha mélyen beleásod magad az adatbázis teljesítményoptimalizálásba és párhuzamossá teszed a dolgokat. És még ennél is több, az ügyfelek szeretik hallani, hogy fel fogod gyorsítani az oldalaikat, mivel ezt a gondolkodásmódot a production-nél is használni kell.