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

A tale of latency and broken windows

yenkel.dev

Post reply on HN
Print view View original

11–17 of 17 posts

Re: A tale of latency and broken windows

#11

Post by kevsim »

hyperman1 wrote: post #2

A simple way to include performance in the development activities without ending ib premature optimization territory is to introduce timing budgets. Decide for each operation how long it us allowed to take. E.g. pushing this button reacts in 100ms. Make your tests record these times. Optimize when it becomes clear you're not going to make it. There was an intervieuw with the Intel engineer that got the linux laptops…

This sounds totally reasonable for a company like Auth0 that has a) a big engineering team and b) tons of people who are depending on their APIs not being slow.

Do you think it's easy enough to get this sort of machinery set up even for small startups?

Re: A tale of latency and broken windows

#12

Post by bentcorner »

acdha wrote: post #8
Chris2048 wrote: post #5

Earlier quoted context omitted.

How do you measure this? Run the item multiple times in different envs and take an average?

I usually like to set percentile thresholds: bad performance is much more likely to cause user frustration so I’d set something like p50/90/97th values for your supported scenarios (e.g. on a website, you might say “old phone on 3G”, “laptop on WiFi/cable”, and “desktop on fiber”) and treat blowing the top end budget as the most critical: fix in next release if you can’t meet your 97th percentile targets but otherwis…

Percentile thresholds IMO is the way to go. You'll find things that don't cause problems at P50 to be problematic at higher percentiles, and the higher percentiles are usually where the user pain lies.

Re: A tale of latency and broken windows

#13

Post by hyperman1 »

kevsim wrote: post #11
hyperman1 wrote: post #2

A simple way to include performance in the development activities without ending ib premature optimization territory is to introduce timing budgets. Decide for each operation how long it us allowed to take. E.g. pushing this button reacts in 100ms. Make your tests record these times. Optimize when it becomes clear you're not going to make it. There was an intervieuw with the Intel engineer that got the linux laptops…

This sounds totally reasonable for a company like Auth0 that has a) a big engineering team and b) tons of people who are depending on their APIs not being slow. Do you think it's easy enough to get this sort of machinery set up even for small startups?

Why not? It's more a question of attitude than technology.

Measure it any way you want. Take an old pc, drop some monitoring package like zabbix on it, and let it poll the APIs. Log entry and exit time. It wont be perfect, but even the lowest effort measurement is better than nothing at all.

Re: A tale of latency and broken windows

#14

Post by stonemetal12 »

kevsim wrote: post #11
hyperman1 wrote: post #2

A simple way to include performance in the development activities without ending ib premature optimization territory is to introduce timing budgets. Decide for each operation how long it us allowed to take. E.g. pushing this button reacts in 100ms. Make your tests record these times. Optimize when it becomes clear you're not going to make it. There was an intervieuw with the Intel engineer that got the linux laptops…

This sounds totally reasonable for a company like Auth0 that has a) a big engineering team and b) tons of people who are depending on their APIs not being slow. Do you think it's easy enough to get this sort of machinery set up even for small startups?

It depends on how fancy you want to get. It could be as simple as a unit test that runs some scenarios a dozen times under a timer and fails if 90 percentile time is greater than the target time.

Re: A tale of latency and broken windows

#15

Post by toast0 »

kevsim wrote: post #11
hyperman1 wrote: post #2

A simple way to include performance in the development activities without ending ib premature optimization territory is to introduce timing budgets. Decide for each operation how long it us allowed to take. E.g. pushing this button reacts in 100ms. Make your tests record these times. Optimize when it becomes clear you're not going to make it. There was an intervieuw with the Intel engineer that got the linux laptops…

This sounds totally reasonable for a company like Auth0 that has a) a big engineering team and b) tons of people who are depending on their APIs not being slow. Do you think it's easy enough to get this sort of machinery set up even for small startups?

If you're collecting stats anyway, it's not usually too hard to collect a latency metric and process it.

There's room to argue about methodology (ie client vs server latency, where and how timing probes happen), but just pick something and try to measure no more than 10 phases of the requests (timing probes have costs too), and see what happens. After you have a baseline, you can set targets and/or see how releases change your data.

Re: A tale of latency and broken windows

#16

Post by webmaven »

hyperman1 wrote: post #10
nabilhat wrote: post #7

I'm lost on the broken windows analogy. Projects like software are constructed from these discrete elements; criminal activity is not. Bank robbery doesn't have a dependency on littering and jaywalking. It makes more sense from the perspective of the real life outcomes of the law enforcement policy. By making an outsized response to trivial infractions a goal divorced from measurement against the desired result, find…

AFAIK the theory says littering does have an effect on bank robbery: If people see litter, you instill a mentality where caring for the neighbourhood is worthless. From that 'each for his' , 'dog eat dog' world view, the step to big crimes is smaller. Now I have no idea if the theory is correct.

> AFAIK the theory says littering does have an effect on bank robbery: If people see litter, you instill a mentality where caring for the neighbourhood is worthless. From that 'each for his' , 'dog eat dog' world view, the step to big crimes is smaller.

> Now I have no idea if the theory is correct.

The theory is correct, but the effect is smaller than proponents supposed (and seems to affect minor property crime more than violence). The poster child for the theory is the reduction in crime in NYC, but more recent analysis has shown that a larger driver was the elimination of lead from gasoline and paint.

Re: A tale of latency and broken windows

#17

Post by drewg123 »

nabilhat wrote: post #7

I'm lost on the broken windows analogy. Projects like software are constructed from these discrete elements; criminal activity is not. Bank robbery doesn't have a dependency on littering and jaywalking. It makes more sense from the perspective of the real life outcomes of the law enforcement policy. By making an outsized response to trivial infractions a goal divorced from measurement against the desired result, find…

I remember a closed source project I worked one once where it was like that. There was a common core that people kind of just threw stuff over the fence into. Horrible, inconsistent style. Four different ways to do the same thing, all different, with different bugs, etc.
Post reply on HN