Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Small things add up: 4chan's migration to a cookieless domain

chrishateswriting.com

Post reply on HN
Print view View original

131–139 of 139 posts

Re: Small things add up: 4chan's migration to a cookieless domain

#131

Post by pbhjpbhj »

coldtea wrote: post #123
darkmighty wrote: post #113

Earlier quoted context omitted.

You could do that and gzip though; it would probably yield some savings. An obfuscator generating code à la iocc efficiency would be quite neat (e.g. http://www.ioccc.org/2012/endoh1/endoh1.c )

> You could do that and gzip though; it would probably yield some savings. Nope. That's classic non-engineer thinking. The same kind of thinking that does "optimization" without profiling. Let me introduce you to my friend: http://en.wikipedia.org/wiki/Diminishing_returns

"some savings" says the parent. A diminishing return is still a return.

Re: Small things add up: 4chan's migration to a cookieless domain

#132

Post by chrisweekly »

cheald wrote: post #98
moot wrote: post #37

Earlier quoted context omitted.

Correct, but only if you don't set any *.domain.com cookies, which as it turns out most do.

Right -- if you're serving your website off of the root, then you're going to have this problem. If you serve it off of www (which, as it turns out, is how domains were originally intended to be used!) then you don't. It's not an inherent flaw of the tech. It's a flaw in how we use it.

+1 Use of a subdomain prefix is absolutely the right thing to do, trendy root-domain-only sites notwithstanding.

CNAMEs are inherently more flexible and more resilient in the face of various load challenges or DoS attacks:

"Root domains are aesthetically pleasing, but the nature of DNS prevents them from being a robust solution for web apps. Root domains don't allow CNAMEs, which requires hardcoding IP addresses, which in turn prevents flexibility on updates to IPs which may need to change over time to handle new load or divert denial-of-service attacks. We strongly recommend against using root domains. Use a subdomain that can be CNAME aliased... " - Heroku [https://status.heroku.com/incident/156]

Re: Small things add up: 4chan's migration to a cookieless domain

#133

Post by epo »

quchen wrote: post #2

> 50 bytes may not seem like a lot, but when you’re serving 500 million pageviews per month, it adds up. That's a void argument in the article. If they were serving pages with 500 bytes each this would indeed be a huge improvement, but no page is 500 bytes. I just opened 4chan.org, and the markup before is already 1,836 bytes. The entire frontpage of /b/ is 114,428 bytes, and saving 50 is absolutely negligible. On th…

> 50 bytes may not seem like a lot, but when you’re serving 500 million pageviews per month, it adds up.

This is rubbish. What matters is how many packets of data go through the network. It is packets which are the unit of transfer and which are handled by intermediate nodes. The difference between say 2340 and 2290 bytes is of no material consequence whatsoever, it may cause one less packet to be sent but probably won't. To think it does have a consequence is to demonstrate a complete lack of understanding of what happens in the network and in endpoints. None of these '50 byte savings' accumulate anywhere in any meaningful or measurable sense whatsoever. So no, it doesn't "add up" to anything.

And if you're going to downvote me explain why I am wrong and how the benefit of these mythical 'savings' can be demonstrated.

Re: Small things add up: 4chan's migration to a cookieless domain

#134

Post by coldtea »

pbhjpbhj wrote: post #131
coldtea wrote: post #123

Earlier quoted context omitted.

> You could do that and gzip though; it would probably yield some savings. Nope. That's classic non-engineer thinking. The same kind of thinking that does "optimization" without profiling. Let me introduce you to my friend: http://en.wikipedia.org/wiki/Diminishing_returns

"some savings" says the parent. A diminishing return is still a return.

And 0.0000000000001 of a dollar is still money. Yet it's meaningless to do anything about getting it...

Re: Small things add up: 4chan's migration to a cookieless domain

#135

Post by Zoomla »

gambler wrote: post #32

Maybe it's just me, but I hate how current web technologies force people to register separate domains for static content. This is not how domains are supposed to work.

and I hate how Google (and others) force websites to serve small files from *.googleapis.com (and other domains)... some websites end up loading files from 10-15 different domain names... I wish this would stop, but I am sarcastic at the same time because I know that they could easily host them locally.

Re: Small things add up: 4chan's migration to a cookieless domain

#136

Post by darkmighty »

coldtea wrote: post #134
pbhjpbhj wrote: post #131

Earlier quoted context omitted.

"some savings" says the parent. A diminishing return is still a return.

And 0.0000000000001 of a dollar is still money. Yet it's meaningless to do anything about getting it...

I can say the savings would probably be greater than the 50 bytes he saved on the domain name. Compressing is not magical, if you compress class names you're still storing at least one instance of each name plus overhead.

Re: Small things add up: 4chan's migration to a cookieless domain

#137

Post by lennel »

Kudos wrote: post #130
lennel wrote: post #126

Earlier quoted context omitted.

closure kicks uglify for size when compiling with advanced optimisations.

I found that the advanced optimisations broke our Javascript when I compared the two a couple of years back. We weren't interested in rewriting our Javascript to make it compatible with the Closure.

The thing that will break your code is this type of notation this['function'] since the compiler can have no idea what renaming should apply. There are aspects of the library that lets you expose public apis.

I can really recommend the compiler in AO mode, the type saving is insane (75% reduction in file size) and type checking is sweet

Re: Small things add up: 4chan's migration to a cookieless domain

#138

Post by prodigal_erik »

epo wrote: post #133
quchen wrote: post #2

> 50 bytes may not seem like a lot, but when you’re serving 500 million pageviews per month, it adds up. That's a void argument in the article. If they were serving pages with 500 bytes each this would indeed be a huge improvement, but no page is 500 bytes. I just opened 4chan.org, and the markup before is already 1,836 bytes. The entire frontpage of /b/ is 114,428 bytes, and saving 50 is absolutely negligible. On th…

> 50 bytes may not seem like a lot, but when you’re serving 500 million pageviews per month, it adds up. This is rubbish. What matters is how many packets of data go through the network. It is packets which are the unit of transfer and which are handled by intermediate nodes. The difference between say 2340 and 2290 bytes is of no material consequence whatsoever, it may cause one less packet to be sent but probably w…

Packets are not padded to the MTU, so a link literally needs more time to send a longer packet. If you make a response 50 bytes shorter, the last packet will always clear a 1 Gbps link 0.37 ms sooner, even before you shave a packet off 3% of your responses. How much you care depends on what you're doing and how bursty it is, but it's certainly measurable at scale.

Re: Small things add up: 4chan's migration to a cookieless domain

#139

Post by psykovsky »

icebraining wrote: post #42
psykovsky wrote: post #23

Earlier quoted context omitted.

Kind of off-topic, but how do you feel about doing a conscious MITM to your users(by using Cloudflare), being 4chan home of Anonymous and all that?

4chan logs IPs and provides them to the cops if the ask, so it's not like users who want to remain completely anonymous can do so without being behind seven proxies anyway.

Providing IP's to law enforcement is not the same as allowing a third-party to do a MITM. Cloudflare can inject whatever content they want to the pages they serve.
Post reply on HN