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

31–40 of 124 posts

Re: How we keep GitHub fast

#31

Post by wamatt »

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/ 175ms

* https://api.github.com/ 400-700ms

Not sure if anyone else noticed this

Re: How we keep GitHub fast

#33

Post by bkbleikamp »

stephengillie wrote: post #24
kalid wrote: post #18

Earlier quoted context omitted.

"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

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.

Re: How we keep GitHub fast

#34

Post by stonemetal »

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…

Considering those graphs are so similar to the ones on github's customer facing UI, my guess is common code.

Re: How we keep GitHub fast

#35

Post by TranceMan »

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…

You have the wrong project manager and shouldn't be paid by the hour.

If the data is available, making it 'pretty' is trivial.

http://d3js.org/

http://twitter.github.com/bootstrap/

No need to waste your time, some people do....

Re: How we keep GitHub fast

#36

Post by toomuchcoffee »

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…

Should I feel bad knowing that ... someone wasted valuable time...

No, but you should feel bad for thinking "it looks pretty" ==> "someone spent a lot of time making it look that way."

In particular, what you need to consider is: maybe they didn't spend all that much time on the visuals. Maybe they were either just really experienced, and it took next to no effort to get it to look that way... or maybe they had next to no knowledge, but used a framework to make it look as if they did.

I find this is a very common mistake managers make, BTW: assuming they can estimate, in the blink of an eye, how long it took to get a certain feature or behavior of an app into existence, out of nothing (and quite often, getting this estimate off by an order of magnitude in one direction or the other).

Re: How we keep GitHub fast

#37

Post by eCa »

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…

You are focusing on the time needed to make this. That is only one part of the equation. The other part is the time spent using it.

If this is (and it seems likely) an internal tool that gets used a lot, pretty soon the time it took to make it a little bit prettier/user-friendlier will be repaid in multiples during the entire lifespan of this application.

Re: How we keep GitHub fast

#39

Post by pestaa »

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 most horsepower, yet also provide almost the lowest response time and very high throughput. How API requests are so different from "browser" requests, since I suspect both are powered by the same backend?

Sorry for my naivety.

Re: How we keep GitHub fast

#40

Post by abraxasz »

bradleyland wrote: post #30
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…

Plenty of tools get by being ugly, but that's not the point. Github is killing it right now, and they're killing it by having a very well designed product that developers really like to use. Thinking of your (team's) effort as a zero sum equation can get you in to trouble. Yes, you only have limited time and effort, but on the flip side, all the time you spend doing something, you're training. By building ugly things…

I very much agree. I'm a (grad student) statistician and most of my time is spent developing models, running simulations, etc.. But once I have all the results, I need to find a way to present them in a way that is both informative, and inviting.

So I had to learn how to make beautiful plots. I used to be terrible at it, but one of my supervisors was very strict about plots: he would literally refuse to read reports in which plots weren't perfect (even draft reports). So I learnt how to make great plots (using ggplot2 for those who know R). At first, it took me forever to make any plot. Now, I can make very good ones in seconds.

So yes, instead of thinking of zero sum games, think of it as training.

Post reply on HN