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

How we keep GitHub fast

github.com

Post reply on HN
Print view View original

51–60 of 124 posts

Re: How we keep GitHub fast

#51

Post by pestaa »

kneath wrote: post #45
pestaa wrote: post #39

A couple of questions: - What does the top chart represent that blends into the background? - What is so costly about rendering pages for Googlebot that it takes almost twice as long as the average rendering time for public views? The throughput is especially interesting as it is less than 30% of its public equivalent. - What does 1 cpu unit equal to? - Also interesting to me is the fact that API requests require the…

The top chart is the throughput for the whole stack over the time period listed in the dropdown. Googlebot tends toward the opposite of the pages we optimize for. For example, Googlebot is really interested in the 38,291th page of your history. I think 1 CPU unit is a core, but I'm not sure. It's mostly interesting in terms of relative numbers. And yes, both api and the web live in the same application servers.

Thanks for your answers, nice insight. Great job on the dashboard, its interface is really inspiring.

I still don't grasp how API can be so efficient while doing basically the same thing as the public-facing site minus probably the HTML rendering, which leads me to believe that rendering is damn resource-heavy in Rails.

Re: How we keep GitHub fast

#52

Post by notJim »

chubot wrote: post #47
chubot wrote: post #46

Earlier quoted context omitted.

Yeah I don't understand this at all. The main reason I don't use Github is because of the high latency. I really dislike their source browser -- it has really low information density and the animation clumsily hides latency.

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.)

Re: How we keep GitHub fast

#53

Post by jbigelow76 »

tanoku wrote: post #12
aggronn wrote: post #2

Should 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…

Don't mind the haters that think twitter bootstrap is a good enough UI wrapper, those are some pretty sexy graphs.

As a developer I'm totally jealous of the ability to create simultaneously elegant and usable UI/UX, even when I used to try and just copy the CSS and structure right from the HTML source (I've since stopped) it was always missing that "je ne sais quois".

Re: How we keep GitHub fast

#54

Post by chimeracoder »

bkbleikamp wrote: post #33
stephengillie wrote: post #24

Earlier quoted context omitted.

That's not actually true. You'll use the plywood because it's stronger and because it's not seen. You get both the cost savings and increased structural stability, which will get you more customers.

That's the difference between Ikea and a company like http://www.urbancase.com/ . Craftsmen don't think that way.

I'm not sure which way you meant that point. Ikea's furniture is notorious for being low-quality and easily broken, despite looking attractive.

Re: How we keep GitHub fast

#55

Post by kneath »

pestaa wrote: post #51
kneath wrote: post #45

Earlier quoted context omitted.

The top chart is the throughput for the whole stack over the time period listed in the dropdown. Googlebot tends toward the opposite of the pages we optimize for. For example, Googlebot is really interested in the 38,291th page of your history. I think 1 CPU unit is a core, but I'm not sure. It's mostly interesting in terms of relative numbers. And yes, both api and the web live in the same application servers.

Thanks for your answers, nice insight. Great job on the dashboard, its interface is really inspiring. I still don't grasp how API can be so efficient while doing basically the same thing as the public-facing site minus probably the HTML rendering, which leads me to believe that rendering is damn resource-heavy in Rails.

Keep in mind that a huge portion of our requests are rendering code. Syntax highlighted code. With line numbers.

Re: How we keep GitHub fast

#56

Post by lifeisstillgood »

kalid wrote: post #18
aggronn wrote: post #2

Should 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…

"When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through." -Steve Jobs

Perhaps a better analogy was made by (General Sir Peter de la Billiere I think) about UK troops patrolling in Helmand Province.

He said something like "Even when they think no-one is watching, no sargents, no generals, they still monitor their surroundings, check the garden walls as they pass. No-one is letting the monotinity reduce their awareness."

In short, if there is a job worth doing, its worth doing well.

Re: How we keep GitHub fast

#57

Post by DigitalSea »

Wow, those are some of the nicest reporting tools I've ever seen. Usually any application that involves measuring metrics like page load, average response times and whatnot looks horrible. It might be a small thing, but wow the design of that dashboard is really nice.

Github are absolutely killing it right now.

Re: How we keep GitHub fast

#58

Post by wamatt »

spullara wrote: post #38

Doesn'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&...

Re: How we keep GitHub fast

#59

Post by lazyjones »

wamatt wrote: post #31

Github is generally pretty nippy for me, and it's a pleasure to work with. Just 2 performance concerns I've noticed: 1. The network graph / /network" rel="nofollow">https://github.com/ / /network seems very sluggish to render 2. The API is slower than normal for HTTPS Usage: $> time curl -i /" rel="nofollow">https:// / For comparison (2nd request's): * https://www.googleapis.com/ 187ms * https://graph.facebook.com/ 1…

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 ...)

Post reply on HN