Posts

Showing posts with the label utilization

Having a Bench is a Good Thing

Image
Look around at the folks on your team, and ask yourself “ Is everyone tasked with stuff? ”, and, “ Is everybody busy with tickets?” . In short,  Is utilization at capacity? Ok, you did that, right? I’m guessing that the answer to the above questions either is, or should be, “ YES ”, right? And — if you’re the product manager/lead/whatever — you’re probably patting yourself on the back, and feeling pretty happy about it, right? Oh, you might have issues on the margin (“ Well, Bob could be a bit busier, and Alice is about to run out of stuff to do… ”), but by and large, you’re good, no? Well, the answer is  NO , and you  shouldn’t  be happy about this, not by a long shot. You see, “ High utilization of resources will improve performance ” is one of the major fallacies in Product Management (•). Wait,  what? If you max out your resource utilization, performance suffers? How can that be? Well, it’s because we’ve all grown up either ignoring queues, or im...

CPU Utilization in Erlang R15B02

Image
Rickard Green makes an interesting point on the erlang-questions mailing list regarding CPU utilization in Erlang R15B02 Regarding increased CPU utilization in R15. When schedulers run out of work, they busy wait for a while before going to sleep. Waking up a busy waiting thread is much faster than waking up a sleeping thread. Due to the rewrites of memory allocation in R15, schedulers are more frequently woken, which cause more busy wait, which in turn cause an increase in CPU utilization when schedulers frequently run out of work (you will at least see some decrease of CPU utilization due to this in R16). When not running out of work there will be no busy wait at all. That is, the increase in CPU utilization does not translate into loss of performance. The busy waiting is there since it shortens the average time to wake up a scheduler, and by this reduces average communication latency between processes. Depending on application the reduced latency might also translate into imp...