Show HN: JavaScript Cache Size Measurement | Hacker News Reader

Show HN: JavaScript Cache Size Measurement

fromwhenceitca.me

42 pointsawirth22 comments

Open articleView on HN

For those hitting errors, the code is on GitHub [0]

And here's my own results: [1]

EDIT: I've also mirrored the repo, and turned it into a site using GitLab CI: [2]

[0] https://github.com/allanlw/cache_size

[1] http://i.imgur.com/LKIvyCt.png

[2] http://shakna-israel.gitlab.io/cache_size/cache_size.html

Thank you! My VPS got overloaded and I put it behind a CDN but I don't know where the DNS SERVFAILs came from.

No idea. Putting stuff on HN is a great way to watch it all break. Happy to help.

Before my VPS folded it was mostly bot traffic, which I hadn't been expecting. Evidently many follow the HN RSS feeds and hit new posts (repeatedly..) when they show up.

I've also noticed something in my logs that is stupidly requesting these 'apple-touch.png' icons over and over thousands of times. It seems to discover links from HN. Even if you create a file with that name, it will just keep requesting it over and over.

iOS seems to be the only thing that uses that particular favicon.

Lots of iPhone users? Or all from the same address? Cos that'd be odd.

I saw something like this once where a shitty app was using some of the iPhone icons, but it was proxying them all without any caching.

So if 10 people would load the app, their backend would make 10 requests to the icon on my server and then would relay those images to each user.

I could see something like this happening with a "push" system so when something new is posted on HN some overly clever dev decided to push the icon and title to each device to be read later but forgot to cache the icon so they end up slamming the server.

Are there distinct lines at 32k, 256k, 4M because of different levels of caches? I feel like 32k is the L1 cache and so on.

On a less powerful machine, I got 32k, 1M, and 8M.

Just where the caching is happening inside the JS engine would be interesting but probably take me weeks to dig down. Any ideas?

I get an error trying to visit the site on ssl on win 10 chrome: "This site can’t provide a secure connection

fromwhenceitca.me sent an invalid response. Try running Windows Network Diagnostics. ERR_SSL_PROTOCOL_ERROR"

Edit: not ssl works, so go to http://www.fromwhenceitca.me/cache_size/cache_size.html

Got the same on Android Chrome.

E: Obviously without the Windows Network Diagnostics part

You'd know it was really borked if you also got the windows diagnostic bit.

Looks like they've fixed it now.

Running behind a Cloudflare SSL Certificate, valid from 11AM December 11, 2016 GMT (today), expires in a year.

Lets just say I had some infra problems... I think everything should be better now?

Looks good! You might consider leaving padding between rows so that the table doesn't adjust when adding the red, it's a bit annoying as is.

Results on a 15" Touchbar MBP [0]

Curious about why there's a big jump from 4MB to 8MB — I know my L3 cache size is 8M [1]

[0] http://imgur.com/a/8QNKO [1] http://www.apple.com/macbook-pro/specs/

I have the same effect on my machine. My guess is that since the L3 cache is shared between cores space used by processes running on other cores is causing a bit of 'blurring' of the performance on the boundary based on how much will data will fit.

I think it's this too. The L3 cache seems to be consistently harder to measure than the L1 or L2 caches. I suspect it's just noise from other cores, but I have no strong evidence to support that.

$nslookup www.fromwhenceitca.me Server: 192.168.0.1 Address: 192.168.0.1#53

server can't find www.fromwhenceitca.me: SERVFAIL

$ dig www.fromwhenceitca.me

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.fromwhenceitca.me ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23762 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.fromwhenceitca.me. IN A

;; Query time: 209 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Sat Dec 10 20:37:22 EST 2016 ;; MSG SIZE rcvd: 50

From Waterloo Canada

I'd try flushing your DNS, as the whois host points to a IP in Cloudflare's range.

I can see some pretty strong effects (and false positives) from what seem to be TLB misses. On my system, on Firefox, the L2 size is not detected correctly if transparent huge pages are enabled, but on Chromium it is. I'd like to take a closer at what's going on, but the tooling for performance-related debugging in browsers seem to be more or less missing. I've opened a pull request for some fixes to the C implementation though.

Thanks for the PR!

It's certainly possible that there are some TLB issues with transparent huge pages that mess up the results. I've had a terrible time debugging the performance across different machines, browsers and OSes, and there seem to be an uncountable number of things that can go wrong, especially with the JITs in play. I'll try to track this one down later today, but I can't make any promises.

Reply on news.ycombinator.com