urMQTT po VPS-ju: SQLite v uporabniškem načinu, primerjava z Mosquittom, konfiguracija kot podatek in graditelj v brskalniku

Drugo besedilo, urMQTT na pravem VPS-ju, se je končalo s seznamom »Kaj sledi«: H6 (SQLite zunaj jedra), H7 (varnost časa), X11 (primerjava z Mosquittom na istem VPS-ju) in prva izdaja. To besedilo sledi temu seznamu v istem vrstnem redu in nato doda dve stvari, ki ju na seznamu ni bilo, ker sta se pojavili vmes: konfiguracijo kot podatek s spletnim graditeljem ISO ter neobvezen navaden MQTT brez TLS. Kot prej: kaj smo načrtovali, kaj smo zgradili, kaj nas je presenetilo in kaj je odprto. V tem besedilu je tudi nekaj rezultatov, ki ne govorijo v prid urMQTT; pustili smo jih, ker so del resnice.

Opomba vnaprej ostaja enaka: projekt je v predalfa fazi, prva izdaja je samo za VPS-je s KVM-jem, številke pa merijo kodo, teste in določene poskuse, ne zrelosti v produkciji.

Kako je to izgledalo skozi čas

Od prejšnjega besedila (31.10. ob 23:00) do danes (1.11. ob 20:41) je v repozitoriju 59 novih commitov, skupaj 178. Vsi so nastali v enem koledarskem dnevu, zato velja enako opozorilo kot prej: projekt gradimo s Claude Code (commiti nosijo Co-Authored-By: Claude), načrt, koda, testi in ADR-ji nastajajo v kratkih, zaprtih zankah, spodnje številke pa govorijo o količini kode in preverjanj, ne o tem, koliko človeškega dela je v njih.

Številke so izračunane z isto metodo kot v prejšnjem besedilu: vse datoteke .rs zunaj vendor/ in fuzz/, funkcije #[test], naslovi ## ADR- v docs/DECISIONS.md.

Trenutek	Commit	Čas	Vrstic Rusta	Testov	ADR-jev
prejšnje besedilo	794f607	31.10. 23:00	89 790	739	104
H6 končan	a0423cc	1.11. 03:59	95 078	754	107
X11	a29f49b	1.11. 07:56	95 579	754	108
spletni graditelj in zrcalo izdaj	582783f	1.11. 16:49	105 645	848	122
navaden MQTT, dokumentacija	8f959f1	1.11. 19:05	112 408	926	125
danes	d21e3ec	1.11. 20:41	112 408	926	126

Delo je potekalo vzporedno na več vejah, zato vrstni red commitov ni strogo vrstni red dela. ADR-ji so oštevilčeni do 232, vendar ima oštevilčenje vrzeli (del jih je bil ob združevanju vej preimenovan); štejemo naslove, ne najvišje številke. Izdaji: v0.2.0 (1.11., 18:45 UTC) in v0.2.1 (1.11., 20:22 UTC), obe označeni kot pre-release.

H6: SQLite v uporabniškem načinu

Kaj smo načrtovali. SQLite je 254 268 vrstic C-ja, ki razčlenjuje bazo, WAL in dnevnik z diska, disk pa je lahko izdelan ali spremenjen. Dotlej je deloval v jedru, s pravicami jedra. Kaj smo zgradili (ADR-210 do ADR-212): SQLite, njegovi deli libc in kopica so bili premaknjeni v ločen program, dbworker, ki teče na EL0 (aarch64) oziroma v ring 3 (x86_64), v lastnem naslovnem prostoru. Jedro SQLite-a ne povezuje več vase. Delavec z jedrom komunicira prek skupnega pomnilniškega okna in dvanajstih sistemskih klicev, vsaka vrnjena dolžina in odmik pa se pred uporabo preverita. Napaka v delavcu (nedovoljen dostop, nedefiniran ukaz, preseženi časovni proračun 30 s) konča klic, delavec se znova zažene in baza se odpre iz WAL-a kot ob zagonu; po 5 ponovnih zagonih na minuto se shramba razglasi za neustrezno in se ne zaganja v nedogled.

Cena, izmerjena na aarch64 pod HVF-jem, ista VM, jedro z vgrajenim SQLite-om proti jedru z delavcem, šest izmeničnih zagonov vsakega:

Meritev	Prej (v jedru)	Potem (delavec)	Razlika
vstop in izstop iz uporabniškega načina	-	1,1 us na krog
db-bench, 5 000 vstavljanj v 50 transakcijah, najboljši / mediana	61,9k / 58,4k op/s	54,7k / 53,3k op/s	-11,6 % / -8,7 %
eno vstavljanje na transakcijo, najboljši / mediana	2 319 / 2 148 op/s	2 307 / 2 126 op/s	-0,5 % / -1 %
celotna varnostna kopija z enim klicem (23 MiB)	514 ms	635 ms	+23 %

Zapisi na disk (1 572) in flushi (319) so enaki, kot mora biti. Tole ni izolirano: jedro še vedno zaupa temu, kar delavec vrne, po preverjanju oblike. Ogrožen delavec lahko laže (na primer vrne prazen seznam preklicanih potrdil in jih tako »prekliče preklic«), ne more pa brati pomnilnika jedra, ključev TLS ali ključev vstopnic. KPTI-ja ni, zato uhajanja tipa Spectre/Meltdown niso preprečena in o njih ne trdimo ničesar; ključ PAC si delita EL0 in EL1. Na x86_64 cene preklopa na KVM-ju nismo izmerili (pod TCG-jem bi bila številka brez pomena), fuzziranje delavca in protokola pa še ni končano. Nabor testov za shrambo (79 scenarijev, vsak vrti SQLite v delavcu) uspešno teče na aarch64 HVF in x86_64 TCG, na aarch64 TCG jih teče 76 (eden se preskoči, ker TCG nima MSI-X).

H7 je zaprt, vendar ne tako, kot smo napovedali. Spodnja meja časa (ADR-050) in SNTP s konsenzom (T1) pokrivata obseg H7; NTS (RFC 8915) ostaja zunaj obsega in je zapisan kot preostalo tveganje, ne kot nekaj, kar deluje. Ne menimo, da je varnost časa »rešena«, ampak da je njen dokazljivi del končan.

Nova omrežna možnost. Contabo ne daje DHCP-ja prilagojenemu ISO-ju, zato je VPS doslej potreboval drugo sliko kot laboratorijska VM. Zdaj network.mode = "auto" (ADR-214) najprej vpraša DHCP, če zakupa v danem roku (dhcp_timeout_s, privzeto 15 s) ni ali ga izgubi, pa uporabi privzeti statični naslov. Ročno preizkušeno na QEMU-ju (z DHCP-jem uporabi zakup, brez omrežja se po 5 s vrne na statični naslov); smoke scenarija za to še ni.

X11: primerjava z Mosquittom na istem VPS-ju

Ista vrsta stroja kot v prejšnjem besedilu (Contabo, 4 vCPU AMD EPYC, 8 GiB), obremenitev z gostitelja Linux, oddaljenega 15 ms, vzajemni TLS 1.3 z istimi potrdili na obeh straneh, Mosquitto 2.0.21 na Debianu 13 brez trajnosti. Metoda in odločitve so v ADR-213, surovi podatki v docs/perf-results/. Mediana treh zagonov.

	urMQTT	Mosquitto 2.0.21
rokovanj/s, 32 / 64 / 128 odjemalcev (profil bench)	169 / 278 / 413	82 / 140 / 184
isto, z omejitvami, kakršne se dobavljajo	185 / 262 / 333 (pri 128: 202 do 286 napak, ponastavitve rokovanja)	-
pomnilnik na nedejavno povezavo (20 000 povezav)	0,50 KB kopice jedra (0,66 KB pri 5 000)	26,8 KB rasti procesa
zakasnitev p50, QoS 0 / QoS 1, 800 sporočil/s, 64 B	14,0 / 14,8 ms	21,4 / 39,5 ms
QoS 1, 4 800 sporočil/s, dostavljeno/s (p50)	4 209 (77 ms)	4 235 (197 ms)
100 naročnikov, 50 sporočil/s: p50	16,6 ms	99 ms
en tok, QoS 0, 64 B, objavljeno/s	2 962 (0 do 7 733)	22 749

Kaj to pomeni in česa ne. Rokovanja so spodnje meje za oba strežnika: generator obremenitve je deljena VM z 60 do 70 % ukradenega procesorskega časa in je bil pri 128 nitih blizu lastne omejitve, delovna jedra urMQTT pa so bila zasedena le 12 do 13 %. Razmerje pri 128 odjemalcih (okoli 2,2-krat) je najsmiselnejše; pri 32 in 64 večinoma meri čakanje odjemalcev. Številke pomnilnika ne štejejo enakega (kopica jedra proti RSS procesa), zato je »okoli 50-krat manj« velikostni red, ne natančno razmerje. Zakasnitev 14 ms je en krog omrežja (okoli 15 ms), torej »ni merljivega časa posrednika«; repi (p99 okoli 100 do 200 ms) so pri obeh posrednikih pod prevlado deljenih gostiteljev. Razlik pod okoli 20 % ne zatrjujemo.

Kaj ni šlo v našo korist in je ostalo v tabelah: en tok TCP prek urMQTT je prenesel 2 do 8-krat manj kot prek Mosquitta, z nihanji od nič do 7,7 tisoč sporočil na sekundo med zagoni, 20 ms watchdog upravljalnika pa je prekinjal žive povezave, ko je hipervizor ustavil vCPU (v produkcijski nastavitvi action = "drop", 6 do 8 povezav na zagon pri preplavljanju QoS 0). Obe stvari sta opisani v naslednjem razdelku, ker sta imeli vzroka v naši kodi.

Zakaj je bil en tok počasen: vzroki, ne izgovori

Najlažje bi bilo reči »deljeni VPS«. Nismo, ampak smo pri istem VPS-ju in isti metodi iskali vzroke. Najdenih je bilo pet vzrokov, štirje v poti podatkov in eden v watchdogu (ADR-221 do ADR-224):

Simptom v X11	Vzrok v urMQTT	Sprememba
en tok 1,9k sporočil/s, pogosto 0 dostavljenih	Izgubljeno prebujanje: zanka izhoda je vrnila seznam pripravljenih povezav čez tisto, kar je bilo pravkar izpisano; naročnik, katerega izhodni medpomnilnik se je enkrat napolnil, ni bil nikoli več postrežen, dokler ga ni prebudil PINGRESP	popravljeno (ADR-223)
nekaj odstotkov izgube spremeni 48k v 14k sporočil/s	vsak segment za izgubljenim je bil zavržen (sprejem samo po vrsti), zato je okrevanje stalo krog omrežja na segment	vrsta segmentov zunaj zaporedja, SACK (ADR-222)
zgornja meja 4,4 MB/s pri 15 ms	16-bitno okno, čakalna vrsta pošiljanja 64 KiB in počasen začetek, ki je štel ACK-je, ne bajtov	skaliranje okna, časovni žigi, štetje bajtov (ADR-222)
vsak krog toka, ki ustreza, čaka 0 do 10 ms	razpošiljalnik je spal do naslednjega utripa po 10 ms (virtio-net nima prekinitve za sprejem)	povpraševanje po NIC vsakih 200 us, dokler povezave obstajajo (ADR-224)
1 do 8 prekinjenih povezav na zagon	watchdog je upravljalniku zaračunaval pretekli čas, VPS pa vCPU-je ustavlja pogosto in dolgo	proračun je čas, ki ga je jedro dejansko delalo (ADR-221)

Ustavitve so resnične: na tem VPS-ju so imela jedra 0 do 2 mediano 36 do 80 zamujenih utripov na 5 sekund, najhujša ustavitev v oknu pa je bila po mediani okoli 70 ms in do 0,9 s (jedro 3, baza in dnevnik: do 1,55 s), medtem ko gostitelj ne sporoča ukradenega časa (host steal 0 us). Zato je watchdog potreboval drugo uro, ne večjega proračuna.

	koda X11 (7f9517e)	zdaj (86a71ff)	Mosquitto
en tok, QoS 0, 64 B, objavljeno / dostavljeno na s	1,9k / 0	23,7k / 12,6k	29,3k / 29,2k
en tok, QoS 0, 1 KiB	0 / 0	3,9k / 2,3k	5,4k / 5,4k
16 parov, preplavljanje, QoS 0, 64 B	24,7k / 20,0k	43,2k / 37,4k	31,4k / 30,7k
16 parov, preplavljanje, QoS 0, 1 KiB	3,7k / 2,9k	5,0k / 4,5k	5,9k / 5,7k
izgubljene povezave na zagon (16 parov, 64 B)	13 (7 do 16)	0 (0 do 0)	0

Watchdog: 148 prekinjenih povezav v 30 obremenjenih zagonih prej, 0 v 24 zagonih potem; na lokalni napravi, ki zakasnjuje in izgublja okvire, ima pri izgubi 0,1 % en tok 64 B s 14,3k sporočil/s (jedro X11) zdaj 41,0k, pri 0,5 % pa s 5,0k na 17,7k.

Kaj to ne pove. urMQTT na enem toku še vedno ni hitrejši od Mosquitta: pri 64 B objavlja okoli 80 % njegove hitrosti, dostavlja pa okoli 40 %, ker zavrže QoS 0, ko je tok naročnika počasnejši od izdajateljevega (Mosquitto brez omejitve postavlja v vrsto). Pri 1 KiB je pri preplavljanju s 16 pari Mosquitto spredaj za okoli 15 %, kar je znotraj šuma. Generator je bil spet deljena VM z 58 do 77 % ukradenega časa. Drugi krog (zaklepanje kopice zunaj poti podatkov, SACK na strani pošiljanja in drugo) je na neintegrirani veji perf-single-flow-wip; njegove številke še niso trditve in jih tu ne navajamo.

Obljuba, ki je nismo dali, a smo jo izpolnili: konfiguracija je podatek

Doslej je bila vsaka konfiguracija nova gradnja: ključi in omejitve so bili vgrajeni v sliko. C1 to obrne (ADR-215 do ADR-219): jedro se zgradi enkrat, konfiguracija pa je podatek.

• Blob urmqtt-cfg (C1a): verzioniran, kanoničen zapis (polja po naraščajočih oznakah, prstni odtis SHA-256, neobvezen ločen podpis Ed25519), 70 polj s privzetimi vrednostmi in mejami, dekoder, ki zavrne vse neustrezno.
• Jedro ga prebere kot modul Limine (C1b), pred vsem drugim, na aarch64 in x86_64. Obstaja eno izdano jedro za vsak ENV razen dev (ELF-i aarch64 za release, prod in bench imajo isti SHA-256; preverjeno samo na aarch64). Izdano jedro zavrne razvojno konfiguracijo, brez konfiguracije pa izpiše »refusing to serve« in ne streže ničesar.
• Nameščeni disk nosi konfiguracijo in posodobitev jo ohrani (C1c).
• urmqtt-config in predloga ISO (C1d): pack, show, verify, pack --iso pa zamenja oba izvoda mesta za konfiguracijo in 24 povzetkov modulov v končnem ISO-ju. Rezultat je bajt za bajtom enak ISO-ju, ki ga zgradi mkiso.sh --config. Predloga izdaje v0.2.0 ima 63 111 168 bajtov.
• Izjava o zaupanju (ADR-219): konfigurirana slika ob zagonu izpiše prstni odtis konfiguracije (config: fingerprint ...), podpis pa je neobvezen in privzeto izključen. Spremenjen ISO nima uradnega povzetka; odtis je način, da se vidi, kaj je v njem.

Graditelj na aldo.tech

Isto, kar dela urmqtt-config pack --iso, dela tudi spletna stran, z isto kodo: knjižnica orodja, prevedena v WebAssembly (1,06 MB, brez uvozov in brez bloka unsafe). Stran je na aldo.tech/sl/izdelki/urmqtt-builder/ in obstaja v vseh 15 jezikih strani (na primer hr).

• Nič ne zapusti brskalnika. Potrdila, zasebni ključi in končni ISO ostanejo na računalniku; stran prenese samo datoteke izdaje s tega mesta, brez sledenja in skript tretjih strani. V testu v živo nobena zahteva ni nosila ključnega gradiva.
• Zrcalo izdaj (ADR-227): ura za uro (časovnik systemd, nizka prioriteta) kopira izdaje z GitHuba, vsako preveri pred objavo, stran v brskalniku pa preveri podpis SHA256SUMS s ključem, vgrajenim v stran, in šele nato vpiše konfiguracijo v predlogo. Neuspešno preverjanje blokira prenos.
• Enostavno privzeto, napredno po potrebi (ADR-232): prvi zaslon so trije koraki (kje deluje, vaša potrdila, ime slike). Eno polje za povlečenje datotek razvrsti potrdilo, ključ in CA po vsebini. Napredni pogled odpre vsako od 70 polj, iskanje, uvoz in izvoz TOML; oba pogleda urejata isto stanje. Predloga (63 MB) se prenaša, medtem ko uporabnik izpolnjuje obrazec. V preizkusu v živo, s preizkusnim zrcalom in preizkusnim ključem, je gradnja ISO-ja v brskalniku trajala 5 do 18 s.

Emulator, neobvezno. Ob »Prenesi ISO« stoji »Preizkusi v emulatorju«: QEMU, preveden v WebAssembly, zažene ravnokar zgrajeno sliko v zavihku brskalnika. Nič od njega se ne prenese pred klikom (okoli 3 MB prvič). Emulator je samo BIOS, brez omrežja (da promet uporabnika ne bi šel prek kakšnega posrednika in omajal »nič ne zapusti brskalnika«), potrebuje okoli 1,5 GB pomnilnika in namizni brskalnik (preizkušen Chrome; Firefox in Safari nista). V njem urMQTT doseže URMQTT READY v okoli 8 s (s preskočenim odštevanjem) in izpiše isti prstni odtis konfiguracije kot stran, kar je dokaz, da je bila zagnana prav ta konfiguracija. Zagon je okoli 2-krat počasnejši od izvirnega QEMU-ja na istem Macu (0,82 s proti 1,9 s), kriptografija pa okoli 58-krat počasnejša, ker so strojni ukazi emulirani. Zato iz emulatorja ne izpeljujemo nobenih trditev o hitrosti, stran pa to pove pred zagonom. Pri gradnji je bilo treba v .wasm zakrpati štiri bajte zaradi napake pri prevodu ukaza POPCNT v izvirnem emulatorju (še je nismo prijavili); sam emulator je pod GPL, s ponudbo izvorne kode.

Navaden MQTT, samo za omrežja, ki jim zaupate

Navaden MQTT (TCP 1883, brez TLS) je v IoT zelo pogost: je privzet v Mosquittu, v večini strojne programske opreme za Arduino in ESP, v Tasmoti, Zigbee2MQTT in Home Assistantu, uporablja pa se tudi znotraj segmentiranih industrijskih omrežij, za VPN-ji in v zasebnih omrežjih LAN, pa tudi na napravah brez ure (potrdila zahtevajo datum), brez dovolj flasha ali procesorja za TLS. Prek nezanesljivega omrežja ni sprejemljiv: kdor je na poti, bere in spreminja promet. Zato je P1 (ADR-229 do ADR-231) izrecna, omejena izbira, privzeto izključena, vrata TLS pa ostanejo; TLS se s tem ne izklopi, navadna vrata pridejo zraven.

• Seznam dovoljenih omrežij je obvezen (allow_from, CIDR-ji) in se preveri ob SYN: zunaj seznama ni SYN-ACK-a ne stanja. Cel internet (0.0.0.0/0) zahteva ločeno izrecno možnost.
• Trije načini prijave: geslo (privzeto, ko je vklopljeno; PBKDF2-HMAC-SHA-256, sol, 10 000 iteracij, primerjava v stalnem času, zaklepanje po naslovu), anonimno (ena konfigurirana identiteta z lastnim ACL) in po naslovu (ip). Graditelj geslo razprši v brskalniku, v pomnilniku pa hrani samo povzetek.
• Manj pravic kot mTLS: navaden odjemalec nikoli nima storitvenih, operaterskih ali upravljalskih pravic, nima $SYS ne konzole, ima lastne seje ($plain/<identiteta>/<id odjemalca>, samo čiste), lastne omejitve in register dovoljenih ga še vedno zavezuje.
• Kaj se izgubi, piše v SECURITY.md: zaupnost, celovitost, pristnost posrednika in ponavljanje posnete prijave. To se s konfiguracijo ne da popraviti; tako je, kadar ni TLS.

Izmerjeno na prenosniku (Apple silicon, HVF, uporabniško omrežje QEMU), 16 parov, 64 B, trije zagoni po 10 s: pri 8 000 sporočilih na sekundo TLS in navadna pot dostavita vsa sporočila z isto zakasnitvijo (p50 0,17 ms proti 0,13 do 0,18 ms), nove povezave na sekundo: TLS okoli 2 600 do 2 750, anonimni navaden okoli 4 900 do 7 800, prijava z geslom pa je drag del: en PBKDF2 stane okoli 2,5 ms, zato je število novih prijav omejeno na okoli 200 na podatkovno jedro na sekundo (izmerjeno 308 do 342 na dveh jedrih). Preplavljanje na tem stroju ni stabilen instrument (20k do 440k dostavljenih na sekundo med zagoni) in iz njega ne izpeljujemo zaključka. Primerjava navadne poti z Mosquittom na VPS-ju še ni narejena. Testi: smoke skupina plaintext 7 od 7 na aarch64 HVF in na x86_64 TCG, nov fuzz cilj plain_input (2,3 milijona zagonov brez najdb).

Napake, ki jih je našlo delo v živo

Dveh stvari niso ujeli testi, ampak prva vključitev na pravem mestu:

• Stran je datoteke izdaje iskala en imenik previsoko, zato je vsako preverjanje podpisa odgovorilo 404 (popravek 13af301). Test je uporabljal preizkusno zrcalo na drugi poti.
• Tipkovnica emulatorja nikoli ni prišla do gosta: vzrok ni bil slab prevod tipk, ampak to, da pogovorno okno sploh ni poslušalo tipk (popravek v ADR-232, z vnosom za zagon brez tipk).

Lekcije

• Iščite vzrok, ne obtožujte okolja. Večina slabosti enega toka in vse prekinjene povezave so bile naše; hipervizor je resničen, vendar ga je bilo treba meriti, ne predpostavljati.
• Primerjava z drugim izdelkom mora vključevati tudi izgube. Tabela, v kateri so samo naše zmage, ne bi bila primerjava.
• Merilni instrument ima meje. Deljen generator z 60 do 70 % ukradenega časa spremeni, kaj številke pomenijo; zato pišemo »spodnja meja« in ne zatrjujemo razlik pod 20 %.
• Izolacija ni dokaz. SQLite v EL0 zmanjša, kaj lahko stori napaka v njem, ne tega, o čemer lahko laže.
• Resnična namestitev najde tisto, česar testi ne iščejo: pot, ki je bila narobe sestavljena, in tipke, ki jih nihče ne posluša.

Kaj še ni dokazano

• Podpisni ključ izdaje je za zdaj preizkusni ključ; v0.2.0 in v0.2.1 sta pre-release, slike zraven njiju pa razvojne s preizkusnimi potrdili (razen predloge, ki je brez konfiguracije).
• 13 prevodov strani graditelja (in tega besedila) je napisala umetna inteligenca, preverili pa so jih testi in vzorci, ne materni govorci.
• Primerjava z Mosquittom je ena seja, ena pot in en deljen generator, na deljenem VPS-ju; razlike pod 20 % niso trditve.
• Navadna pot ni bila merjena na VPS-ju ne proti Mosquittu.
• Lighthouse na novem enostavnem pogledu ni potrjen (stari pogled: dostopnost 95 ali več).
• Bare metal, cena delavca x86_64 na KVM-ju, Firefox in Safari za emulator: ni merjeno.

Kaj sledi

• D1: javni demo posrednik. Emulatorja iz brskalnika ne moremo narediti javnega: živi v zavihku enega obiskovalca, je 20 do 100-krat počasnejši od KVM-ja, nima dohodnega omrežja in izgine z zaprtjem zavihka; preusmerjanje interneta v tuj brskalnik bi bilo tudi zloraba. Mogoč je pravi demo posrednik: urMQTT na VPS-ju za imenom na aldo.tech, z objavljenim preizkusnim CA, strogim ACL in majhnimi omejitvami. To je zaenkrat samo zamisel, ne gradnja, in potrebuje izrecno soglasje za javno izpostavitev.
• Drugi krog za en tok (veja perf-single-flow-wip): šele ko je izmerjen na VPS-ju in združen.
• Navadna pot proti Mosquittu na VPS-ju, prijava in preklic računa za navaden MQTT prek podpisanega upravljalskega kanala.
• Po izdaji: bare metal (X12 do X16), IOMMU in Secure Boot, šifriranje diska.

Koda je na github.com/zeljan-alduk/urMQTT, docs/PROGRESS.md pa je še vedno edini vir resnice o tem, kaj dejansko deluje, docs/PERFORMANCE.md o tem, kaj je izmerjeno. Predalfa, kot prej; prijave napak in varnostne prijave po navodilih v SECURITY.md so dobrodošle.