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

Another reason why Docker containers may be slow

hackernoon.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Another reason why Docker containers may be slow

#61

Post by Fnoord »

mratzloff wrote: post #57

One time we observed a dramatic drop-off in performance from one of our services after a certain day that week. I looked at recent releases and saw it perfectly coincided with one. I asked the engineer in question to investigate, but after looking he said, "It's nothing I could be doing." So I sat with him and used git-bisect to prove to him it was his commit: he had added trace logging within a couple of tight loops…

> Moral: logging is not free.

I can see how this is even true for a sniffing hardware bridge but isn't it free when your source is fiber?

Re: Another reason why Docker containers may be slow

#62

Post by benjaminl »

amdavidson wrote: post #60
benjaminl wrote: post #23

Earlier quoted context omitted.

That would by Joyent [0] the makers of SmartOS (Basically, Open Source Solaris). Their Triton cloud product uses SmartOS under the hood. [0] - https://www.joyent.com/smartos

They're not exactly competitive: https://www.joyent.com/pricing/cloud/compute https://www.digitalocean.com/pricing/

They claim to be half the price of AWS [0]. Digital Ocean isn't relevant here as they don't offer container hosting.

[0] - https://www.joyent.com/pricing/compare

Re: Another reason why Docker containers may be slow

#63

Post by monocasa »

oneweekwonder wrote: post #47
asdbffg wrote: post #41

Earlier quoted context omitted.

Java is FOSS. Oracle used excuse, that it's current OpenJDK license (GPLv2) is incompatible with license, used by Google's runtime (Apache 2). If Google re-licensed it's Java implementation under GPL, some of arguments, used by Oracle lawyers (code reuse and patent (?) violations), would have been void, and arguing about reuse of APIs would have been a lot harder. Of course, this does not really matter, because the w…

Can google pull a swift move?

No, the copyright trial is about the "structure, sequence, and organization" of the APIs, not any literal copying anymore. Switching languages, but keeping the same class library still leaves them open.

Re: Another reason why Docker containers may be slow

#64

Post by jbn »

Skunkleton wrote: post #37
prewett wrote: post #31

Earlier quoted context omitted.

I don't know anything about Solaris Zones, but I'm guessing that the FreeBSD jails wouldn't help with the problem in the article. It's still the same kernel running in the jail, so the fadvise calls are going to bottleneck in the same place.

Why would an entirely different piece of software have the same performance bottlenecks?

Maybe because https://blog.regehr.org/archives/303 (N-version programming often exhibits the same defects...)

Re: Another reason why Docker containers may be slow

#65

Post by johnhenry »

jorisvh wrote: post #54

This is not the original title. The original title is "Another reason why your Docker containers may be slow".

I think this is important because "your" implies that there is something that someone can do to fix the problem. Omitting it makes the think that there's a general problem with the docker ecosystem.

Re: Another reason why Docker containers may be slow

#66

Post by kbutler »

hvidgaard wrote: post #58
mratzloff wrote: post #57

One time we observed a dramatic drop-off in performance from one of our services after a certain day that week. I looked at recent releases and saw it perfectly coincided with one. I asked the engineer in question to investigate, but after looking he said, "It's nothing I could be doing." So I sat with him and used git-bisect to prove to him it was his commit: he had added trace logging within a couple of tight loops…

Logging is never free. Either you add additional compile time cost to remove it, or you add at the very least a single if and/or method call at runtime. It's not easy problem to solve. The best I've come up with so far, is using a decorator in conjunction with a DI framework that supports it. It's still only a wrap around method calls, but it enables completely turning off logging in production, and enable it when it…

Preprocessor-disabled logging (and generally compile-time disabled logging) is free at run-time.

The compile-time cost of stripping out preprocessor macros disabled via #ifdef is close enough to free you'd have a really hard time measuring it - O(n) on number of lines of logging code, with n smaller than the number of lines of actual code for any real scenario, and a very small multiplier.

The "cost" there is in the visual appearance of the source code.

Re: Another reason why Docker containers may be slow

#67

Post by amdavidson »

benjaminl wrote: post #62
amdavidson wrote: post #60

Earlier quoted context omitted.

They're not exactly competitive: https://www.joyent.com/pricing/cloud/compute https://www.digitalocean.com/pricing/

They claim to be half the price of AWS [0]. Digital Ocean isn't relevant here as they don't offer container hosting. [0] - https://www.joyent.com/pricing/compare

In your link, they're comparing to EC2 VMs not Amazon's Container hosting.

Their whole premise is that their containers are equivalent to/better than VMs[0].

0: https://www.joyent.com/blog/understanding-triton-containers

Re: Another reason why Docker containers may be slow

#68

Post by Skunkleton »

rbranson wrote: post #40
Skunkleton wrote: post #37

Earlier quoted context omitted.

Why would an entirely different piece of software have the same performance bottlenecks?

Because the problem isn’t that there is one bug in a specific implementation, it’s that the whole model is fundamentally prone to this type of problem. cgroups, Jails, and Zones all suffer from having to cover an immense surface area. Contrast with VMs, which only require managing a few, significantly simpler interfaces. There are definitely differences in quality, but they all use a similar approach.

OP says that fadvise is going to bottleneck in the same places on BSD that it does under Linux, with no supporting evidence. I agree that containers in general are a tough problem.
Post reply on HN