The performance dashboard and mission control bar look amazing. Would be great if they could be open sourced. :)
You can also take a look at Rack MiniProfiler http://samsaffron.com/archive/2012/07/12/miniprofiler-ruby-e...
How we keep GitHub fast
71–80 of 124 posts
Re: How we keep GitHub fast
#72Earlier quoted context omitted.
That's easy: googleapis.com and facebook.com use 1024 bit RSA keys, github uses 2048 bit. So the initial handshake is slower and the performance on your end is probably the main bottleneck. (by the way, RSA labs deprecated the use of 1024 bit keys in 2003(!), so one could say that googleapis and fb use snake oil rather than ssl ...)
Good find! Didn't realize Github were using 2048 bit keys. I would be interested in knowing what the actual performance differences are between key sizes, given RSA is used in the initial negotiation before symmetric SSL takes over. >so one could say that googleapis and fb use snake oil rather than ssl ...) Given that Paypal, my bank, Google and Facebook use 1024 keys, I think labelling 1024 bit as "snake oil", might…
PayPal uses 2048 bit SSL keys
Re: How we keep GitHub fast
#73Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…
I work for an agency, and I always find myself thinking that if we're content to settle for 2nd-rate tools for our own use, are we really in a position to say that what we're offering clients is 1st-rate?
It's easy to go overboard with making something pretty when it's in-house, but at the same time I genuinely find that I'm more productive when using pretty software. It's probably the INFP in me, but when something is slightly off I find it incredibly distracting.
In the case of the github dashboard images in this blog post, they do look a little designed but nothing that would take an experienced interface designer more than an hour or so. Time well spent if it makes the idealists in your team happier.
Re: How we keep GitHub fast
#74Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…
It was done in-house. We really care about how our graphs look, because graphs represent information. It's like typography. Humans learned how to write 5000 years ago, and it took us a very long while until we mastered the art of transmitting information like that. Once we mastered it, however, we started caring about the way we present that information. For no specific reason, but we developed unique typefaces that…
I don't think its about pride and making it pretty - that is - maybe it's the reason, but it's not what brings success in that area.
I think it's because, when it looks good, it's easier to find the information, and it makes you want to look at it. It makes you want to work with it.
Now then again while I realize github has a huge, huge amount of things running at the same time, I do find github quite a bit slower than my "own" remote repos :P
Re: How we keep GitHub fast
#75Now that Github is fast and beautiful, I personally hope they make it fast in Japan.
Re: How we keep GitHub fast
#76Doesn't something have to be fast in order for it to be kept fast? My experience using the Github web frontend is one mostly of frustrating slowness, especially as of late.
Strange, Github is blazing fast in my experience.
Bitbucket on the other hand is insanely slow, especially in the source browser. That said, I gladly tolerate it due to unlimited free private repos and a decent feature set.
Re: How we keep GitHub fast
#77Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…
Code, design, backend design, it all matters. If your code is shitty, your product is shitty. If your internal tools are badly designed, you can feel it on the frontend. I'm amazed by how smart decisions Github make. They dare to focus on things that are not obvious important, but make a huge different for the employees. The employees in return make a world class product. I really enjoyed this post, and it keeps me e…
"I'm amazed by how smart decisions Github make. They dare to focus on things that are not obvious important, but make a huge different for the employees. The employees in return make a world class product."
It's run by great developers, that's why. They understand the psychology of a great developer.
Re: How we keep GitHub fast
#78Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…
For what it's worth, if you were working for me, you would be instantly fired. This is exactly the kind of opinion that perpetuates the mass of low quality crap in the world. It's an example of cutting corners, and long-term, it ends up costing so much more than it saves.
Wow, you would instantly fire somebody for raising the question?
My goodness.
Re: How we keep GitHub fast
#79Doesn't something have to be fast in order for it to be kept fast? My experience using the Github web frontend is one mostly of frustrating slowness, especially as of late.
Upon further investigation, it's not just the API, it's the entire site. A significant cause of the issue is their SSL implementation. Specifically it negotiates a new connection every time instead of resuming the session, eek! http://security.stackexchange.com/questions/5511/ssl-session... https://www.ssllabs.com/ssltest/analyze.html?d=github%2ecom&...
Is this a problem with the default setup of Nginx out of the box, or has GitHub intentionally disabled session resumption?
Re: How we keep GitHub fast
#80Earlier quoted context omitted.
EDIT: I did some spot checks with chrome developer tools on a project linked from their front page: https://github.com/rails/rails Chrome is reporting the code tab is taking 3.7 seconds to load. 22 HTTP requests. The Pull tab has over 100 HTTP requests. I don't consider anything over 1s to be fast. Even the initial HTML is taking more than 1.5 seconds on the Pull tab! I think you should aim for 200ms for the HTML, an…
Do you have an idea of a site that you consider fast? I just checked a few sites around the web, and 1.x seconds seems pretty average (I'm looking at the onload time, as that seems like a somewhat-maybe scientific way of looking at things.)
Most Google sites (less so lately since there is more Ajax), craigslist, reddit of 4 years ago, HN of 2 years ago. Basically all the bare-bones content-driven sites, since people tend to write JS and CSS in a way that makes the site at least 100% slower.
Amazon is pretty decent. Their full page loads are slow, but they concentrate on above-the-fold time which is OK. I don't use Facebook much, but I think they have pretty good latency.
I think Microsoft's new mail is pretty fast but I haven't used it much.
I would say 1.x seconds for initial HTML is average. And 3-4 seconds for the full page with all assets is average. Github is in the 3-4 seconds range for onload time.
So Github is not particularly bad -- it's just average. It's certainly not "fast".
I feel like Github's perceived latency is pretty bad. I think they end up showing spinners and redrawing various parts of page to try to hide latency, but it makes it seem janky to me.