09:09 <crab> hi.

09:11 <crab> i love sandstorm, but i'm losing my mind because apps take so long to load. my SO is trying to send "get shareable link" links to a radicale calendar with someone, and most of the time those links take >3min to load, if they ever do.

09:11 <crab> and it's not just shareable links, often there's such a slowdown even when i'm opening the calendar grain myself. i'm hoping someone can help me try to debug this problem.

09:14 <crab> in the network console in firefox, i see that the browser issued a bunch of parallel requests, and one in particular, "compressed.js?9df…" took 221s to download, out of which the connect/tls negotiation was all over in a couple of seconds, and the rest was just reading the 2.6MB of response. and once that finished, all the other parallel requests were quickly completed. those ones were "blocked" for 220s and then completed very fast.

09:45 <crab> even if i try to open just that file in a separate browser tab, it takes 220s+

14:52 <hfrk> Hi

14:53 <hfrk> Is there a way to use client certificates with sandstorm to increase security?

16:13 <TimMc> hfrk: Per-user, as the Sandstorm auth method? not that I'm aware of.

16:14 <TimMc> crab: Oh yeah, I saw that go by on the list, but I didn't catch the details.

16:16 <TimMc> crab: What kind of server are you using?

16:28 <crab> TimMc: it's an i7-6700 (3.4GHz) box with 64GB of RAM.

16:28 <crab> if that's what you meant.

16:29 <TimMc> And is Sandstorm running directly on it, or in a VM?

16:30 <TimMc> (I've got Sandstorm running on a 10 year old HP laptop the neighbor threw out, so those specs should be plenty good enough!)

16:31 <crab> it's running directly.

16:33 <kentonv> no app should take 3 minutes to load. Something is definitely wrong.

16:34 <kentonv> crab, is it possibly a slow network or does it happen even on LAN?

16:39 <crab> i haven't tried it on a LAN.

16:40 <crab> my connection isn't great, but i copied the offending "compressed.js" to a directory served by nginx outside sandstorm, and i can consistently download it via wget in ~60s

16:40 <crab> whereas through sandsorm i often see >300s download times

16:42 <crab> the lowest time i've seen through sandstorm for that file to download in the browser is about 120s.

16:45 <TimMc> Your DNS lookup taking 6 seconds is kind of weird too.

16:47 <TimMc> OK, you say it takes you 60 seconds to download 2.6 MB from outside of Sandstorm -- is that expected, for your internet connection?

16:47 <crab> yes.

16:49 <TimMc> So that explains slowness overall, but not why Sandstorm is *slower* -- so it doesn't necessarily point out a network stack problem inside the machine.

16:50 <kentonv> whoa what is this 2.6MB JS file? Sandstorm's JS is 326k...

16:50 <crab> it's bundled with "infcloud", that's bundled with radicale.

16:52 <TimMc> kentonv: sounds webscale ;-)

16:58 <kentonv> Hmm. I wonder if Sandstorm has some sort of bug where in the presence of a relatively slow connection it actually applies too much backpressure making downloads even slower.

16:59 <kentonv> Though it could also be radicale that has the bug.

16:59 <kentonv> I guess the way to test would be to download a large file from Davros and see if it saturates the connection properly.

17:09 <ocdtr_web> I don't know if it's a Sandstorm bug, kentonv, because I downloaded compressed.js from crab's Radicale grain in 1.2 seconds.

17:09 <ocdtr_web> Which would also suggest it isn't a Radicale bug either, but a bug/issue with crab's client.

17:10 <kentonv> is crab's server in a datacenter or on a home internet connection?

17:10 <ocdtr_web> (That being said, I believe Radicale is LONG overdue for some app update love, given that people do use it.)

17:12 <kentonv> ocdtr_web, the fact that you downloaded it in 1.2 seconds doesn't mean there isn't a bug in sandstorm -- the bug I described would manifest when pushing to a slow end-to-end connection

17:13 <ocdtr_web> Ah

17:14 <kentonv> it could be, for example, that crab's internet connection has extremely long latency which means that lots of packets can be in-flight before the first packet is finally ack'd. And maybe Sandstorm is doing networking wrong such that it doesn't manage to put enough packets in-flight.

17:15 <kentonv> normally the OS should take care of that, though

19:07 <ocdtr_web> isd: bootstarp sounds like somewhere you'd put your boots so they don't ruin your floors.

19:08 <isd> "boots tarp"

19:08 <isd> :P

19:09 <isd> Didn't even think of that; knowing what it was supposed to be my brain insisted on parsing it as "boot starp" which makes even less sense.

19:09 <ocdtr_web> :D

19:10 <ocdtr_web> I didn't know a cluttered PR list was a thing/concern.

19:10 <ocdtr_web> I never looked at that tab until recently.

19:10 <ocdtr_web> I have two open for definitely-abandoned projects that will probably never see love or affection of any kind.

19:10 <ocdtr_web> One that adds a desperately needed feature to a project that refuses to accept it.

19:11 <isd> Yeah, the link at the top lists them, which I find useful to keep track of things when I've got several in-flight.

19:11 <ocdtr_web> And the rest are currently sandstorm-io PRs

19:11 <isd> At some point you either have to fork or just forget about it.

19:12 <ocdtr_web> I want the PR for marked there as a constant reminder of how they should totally just merge it.

19:14 <ocdtr_web> "It has merge conflicts now" -> "K, rebased on master"

19:14 <isd> :P

19:14 <ocdtr_web> "It doesn't have tests" -> "K, added tests"

19:15 <ocdtr_web> "We're not sure how it fits in with our eventual planned roadmap of nonsense"

19:18 <ocdtr_web> Oh, I almost forgot the "It's not part of the specification", which someone else pointed out that it fell outside of the type of thing the specification covered.