.Pirátská strana » Technické oddělení

jak dlouho trval ten problem? mozna opravdu narazime na problemy rychlosti rsync - index.html uz je na produkcnim serveru, tiskovka jeste neni.

Nevím,zaznamenala jsem ho náhodou byly to max jednotky minut.

proti (predpokladanemu) pomalemu rsyncu jsem pripojil datovy oddil s webama pres NFS (misto nativniho glusterfs). jako filesystem s velkym mnozstvim malych souboru je glusterfs hrozne pomaly.

dalsi potencialni problem, o kterem vim, muze vznikat pri dvou za sebou jdoucich commitech v malem casovem rozmezi. pracuji na nem. jako docasnou prevenci bych striktne doporucil se vzdrzet commitu drive nez uvidite na webu predeslou zmenu.

Dík že se tomu věnujes. Ty dva commity po sobě jsou možná příčina v té době jsme na webu pracovali dva a z hlavy nevím přesně časovou odestup. Pokusim se to hlidat.

Po komplexni analyze byly provedene nasledujici upravy deploy systemu

1. Pridana (kratka) fronta pozadavku na build, takze v pripade vestiho mnoztvi pozadavku vzdy bude zpracovan ten posledni
2. Process deploymentu uz neridi cron, ale timer systemd, coz umoznilo zkratit maximalni dobu mezi webhookem a spoustem buildu z 60 na 10s (a budu uvazovat o prechodu na systemd path monitoring, a bude to nula)
3. Dalsim problemem se ukazal glusterfs, na kterem process synchronizace (rsync z deploy server na webserver) webu pirati.cz trval az 20s, a to je ta inconsystentni doba. Presun dat na lokalni filesystem umoznil je zkratit do 2-3s

po komplexu opatreni kompletni deploy hlavniho webu trva cca 2 minuty, ze kterych opravdu problemovymi muzou byt jsou ty 2 az 3 vteriny (ve skutecnosti mene, protoze samotny presun aktualizivanych souboru trva jen desitky milivterin z celkoveho casu synchronizace)