Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2016-01-31

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:51 mattp joined #metacpan
02:00 mattp joined #metacpan
02:27 mattp joined #metacpan
04:31 dolmen joined #metacpan
06:21 mattp joined #metacpan
07:49 oiami joined #metacpan
09:04 kentnl haarg:  Yeah. I'm not entirely sure what's going on, all I have to go on is "Great, metacpan takes >5 seconds on most pages I try to load unless I loaded them recently" . I'll have to do some more sleuthing with curl and see if I can get closer to what the reference time should be
09:06 kentnl so far on just randomly chosen pages that aren't in cache, the base HTTP request with `curl` is only taking <1 second, and the headers to confirm that its a cache-miss , so its *some* external resource somehow making things slower
09:07 kentnl I'll try turning off HTTP/2.0 support in firefox and see if that changes anything.
09:11 kentnl http2.0 turned off, ipv6 turned off, neither seem to have any effect.
09:11 kentnl its the strangest thing, it its like every *second* uncached request is slow, but the ones in between are faster somehow
09:11 kentnl counting the load times is like 5 seconds, 1 second, 5 seconds, 1 second
09:12 kentnl hmm. metacpan.org has 2 ips.
09:17 kentnl disabling javascript entirely using the web console takes my average "slow" page from 5 seconds to 3
09:18 kentnl I'm really tempted to blame google analytics
09:19 kentnl It wouldn't be the first time I'd experienced a website turn to shit because google analytics is being loaded in <head>
09:20 kentnl Oh god. Yeah. That <script> in head is fetching google analytics and then performing document.write calls. That typically blocks dom render
09:22 kentnl though that shouldn't matter for me, ublock is supposed to inhibit that.
09:23 kentnl Lolol. Disable ublock, page load spikes to 9 seconds
09:27 kentnl wut. 6 seconds to load a cached page. FUUUUU
09:50 kentnl Curious. Problem was reproducable in luakit ( based on webkit-gtk ), but isn't reproducable in opera 36 ( based on chromium ). ( And I'm not 100% sure about that last one, but if the problem is there, I'm only seeing a difference so far between 1 and 2 seconds roughly )
10:06 kentnl I'm getting the sneaking suspicion chromium more eagerly begins the page render than FF
10:07 kentnl Because those timing graphs I give that have no activity other than things that you say "shouldn't block the page load" do indeed occur before the page renders in FF, while in chrome, the page seems to load, and then a few resources continue arriving
10:12 kentnl because with literally every single request that takes a long time, me mentally counting how long it takes and the amount of time it took for the external JSON resources to start arrving are the same
10:51 kentnl wow man. Google Analytics means I have to wait 30 seconds between clicks
10:52 dolmen joined #metacpan
11:01 * kentnl flips table and turns off the internet
12:02 kentnl Ok. I might be tripping, but it looks like the majority of CPU time on the `/recent` page is occupied in ....
12:02 kentnl syntax highlighting.
12:18 kentnl Uh. No. :(. minifiers-- , putting comments in the source code that says "this is where a syntax highlighter is" followed by a bunch of code that ain't syhi
12:42 bowtie_ joined #metacpan
13:02 kentnl haarg: sanity check request: does it seem like https://github.com/CPAN-API/metacpan-web/blame/2c72394c65858a85418607b2eb6f96bb0669248e/root/static/js/cpan.js#L298-L315   <-- this block of code can  be explained on a respectable perf bottleneck? Opera/Chromium seems to be saying that block is slow because each call to textWidth() is causing a css reflow, followed by a layout reflow, and that's not cheap
13:06 kentnl I'm just horrified how anyone can get around this :(
13:51 dolmen joined #metacpan
17:33 haarg kentnl: yeah that could definitely cause issues
17:37 haarg the google analytics code is also loaded async, so it shouldn't impact render times
18:03 neilb joined #metacpan
18:23 trs kentnl: using a smarter search algorithm in that loop rather than decreasing by 1 character every time is likely to be better.
18:25 trs kentnl: for example, Big, a minimal presentation-as-HTML tool, switched their layout loop (doing something conceptually similar) to speed it up: http://www.macwright.org/2016/01/25/big-2.html
18:53 neilb joined #metacpan
19:01 neilb_ joined #metacpan
20:34 metacpan joined #metacpan
20:34 metacpan [cpan-api] ranguard created leo/cache_3_api (+2 new commits): https://git.io/vgece
20:34 metacpan cpan-api/leo/cache_3_api 10649c3 Leo Lapworth: Add a copy of the MC::Web Fastly file and dependencies
20:34 metacpan cpan-api/leo/cache_3_api 27a15b9 Leo Lapworth: Intergrate purging on [re]indexing
20:34 metacpan left #metacpan
20:54 oiami joined #metacpan
20:57 metacpan joined #metacpan
20:57 metacpan [metacpan-web] ranguard created leo/small_speedups (+1 new commit): https://git.io/vgeC9
20:57 metacpan metacpan-web/leo/small_speedups d28bf08 Leo Lapworth: cache assets at fastly for a year #1640 - we can purge "assets" to clear
20:57 metacpan left #metacpan
21:26 neilb joined #metacpan
21:28 bowtie joined #metacpan
21:39 bowtie joined #metacpan
22:11 dolmen joined #metacpan
22:18 neilb joined #metacpan
22:45 vroom joined #metacpan
23:04 vroom joined #metacpan
23:18 punter joined #metacpan
23:21 neilb joined #metacpan
23:39 vroom joined #metacpan

| Channels | #metacpan index | Today | | Search | Google Search | Plain-Text | summary