<mnutt>
I'm curious what sort of davros-reported startup times people are seeing. When I did the profiling a few years ago I got it down to ~225ms. Last night I saw a few instances of up to 2-4s, but now I'm back to seeing right around 220ms.
<mnutt>
(when davros starts, it prints its startup time to stdout in the log)
<isd>
mnutt: I just tested with one of my grains, it reports 2904ms, but it definitely took much longer than that before anything actually showed up in the browser window -- more like 10 or 11 seconds (I didn't pull out a stopwatch, just counting 1 mississippi...)
<isd>
I don't think I've ever seen davros actually display a UI in anywhere near 200ms.
<mnutt>
is that via restarting an existing grain, or relaunching a new one?
<isd>
That's booting an existing grain
<mnutt>
how many files do you have in it?
<isd>
one. 648 bytes (I should probably just delete this grain).
<isd>
The Sandstorm UI reports the grain's storage is 47.4K
<mnutt>
any chance you could share a (non-sensitive) davros grain on your server?
<isd>
Do you want me to send you a backup, or a sharing link?
<mnutt>
a sharing link, ideally
<isd>
Sent.
<isd>
That's the same grain I was discussing. It's starting much faster now, which lends some credence to the idea that it's a disk IO thing; probably the cache is warmed up.
<isd>
The machine has a magnetic disk, so if you're developing on an SSD that could be relevant as well.
<mnutt>
yeah, I'm thinking the same thing. it performs about the same as my server does, now
<mnutt>
mine's an ssd, but still has a slowdown when the cache is cold
<mnutt>
I'm still looking at minifying/packaging to reduce the number of fs reads it has to do as it requires files
<mnutt>
node 15 does sometimes dozens of fs stats when using require(), between searching the path and looking for no extension, .js, .json, .node, /package.json, etc
<xet7>
When using Wekan Snap version, creating new board on normal harddisk takes 5 minutes, and on SSD 2 seconds. So that's the difference between HDD and SSD for me.
<xet7>
Well, I do have a lot of data at MongoDB, that could affect too.
<xet7>
Currently I'm porting Wekan to OpenPower ppc64le. I got ssh access to OpenPower server.
<xet7>
It's VM at OpenStack
<xet7>
I have not yet found RISC-V server yet for porting.
<isd>
Yeah, I think minifying will likely make a big difference.
<xet7>
isd: minifying how?
<xet7>
oh, that of mnutt
<xet7>
ok
<mnutt>
rollup against a node app using a bunch of legacy npm modules is turning out to be pretty painful
<xet7>
Well, I have done my part of meteor+npm package update dance, many times
<xet7>
I'm happy Wekan is running newest Meteor
<TimMc>
"Davros started in 1852ms" but some of the older messages in the debug log for that grain show 300 ms or so. Magnetic disk, old laptop.
digitalcircuit has quit [Quit: Signing off from Quassel - see ya!]
digitalcircuit has joined #sandstorm
ecloud has quit [Read error: Connection reset by peer]
ecloud has joined #sandstorm
aerth has joined #sandstorm
<aerth>
pretty stable once u get it going?
<aerth>
OK i must have done something wrong the first few times i installed it, but with enough mem/cpu , i got it working *really good* and with wildcard letsencrypt and behind caddy reverse proxy
<xet7>
I'm currently in progress of trying to build Percona MongoDB from source on ppc64le OpenPower, because for that CPU I did not find community packages of MongoDB. There seems to be Enterprise version of MongoDB for OpenPower, but I have not looked yet what it requires.
<xet7>
Hmm, maybe I'll look how friendly that MongoDB company is