6 ms·
If your program is slow because it's waiting for external service response, you're doing programming wrong. Your program should do other work in the meantime. I
by emteycz 5y ago
If your program is slow because it's waiting for external service response, you're doing programming wrong. Your program should do other work in the meantime. I guess you're already doing that, but if so, doesn't that invalidate your reply here?
- DeathArrow 5y ago>If your program is slow because it's waiting for external service response, you're doing programming wrong. Your program should do other work in the meantime. What work? Mine bitcoins while you wait the result for an API call?
- emteycz 5y agoUsually processing other requests
- atraac 5y agoI think any sane person here assumes any IO, especially in .NET is already async and allows other requests to use that time… Most web apps are still IO constrained.
- emteycz 5y agoSure, but how is waiting for external requests relevant in any way to .NET performance then?
- SideburnsOfDoom 5y agoIf you're asking "how is waiting for external requests relevant to my service's response time" the answer is "because it's usually the largest part". I really don't know how to explain it more simply than that. If you need to improve this, and that code is .NET, then the solution is a different design, also in .NET Code.
- emteycz 5y agoI am asking how is waiting for external services relevant to .NET processing time.
- SideburnsOfDoom 5y agoI refer you to my answer above. https://news.ycombinator.com/item?id=29306220 https://news.ycombinator.com/item?id=29306220
- SideburnsOfDoom 5y ago> you're doing programming wrong. Your program should do other work in the meantime. It's not always true that there is other work to do in the meantime. In fact in my experience, it seldom is. "you're doing programming wrong" is a very strong statement, and not one that I take seriously in this context. Typically you "await" the external service response, so that it is not using a thread to do that, and "other work" in the form of starting to deal with other requests can happen in the meantime, thereby increasing service throughput. But that won't speed up a given request - you can wait for an external service more efficiently, but you can't wait faster. Services that do not depend on any other http services or any data store do happen, but they are rare in my experience (calculation engines, I suppose). So for almost every service, when thinking about response time, you have to, first and foremost, think about the latency of the data stores or upstream services.
- emteycz 5y agoThat is all true, but in the context of .NET performance, it's not relevant.
- SideburnsOfDoom 5y agoWhat then is, in your opinion, most relevant?
- emteycz 5y agoTime taken by processing done by the application itself. Faster processing is good even if your backend is mostly waiting for other services - now it can wait for more services at the same time and deal with their output faster, allowing your app to use less resources or handle more traffic. That is especially pronounced on scale - if you're spending X million for computing time a month, reducing it by few percent is very interesting to you.
- SideburnsOfDoom 5y agoBoth can be relevant. In the real world, designing how to deal with dependencies and data stores is clearly relevant, as it can be the largest large part of the time taken to respond to a given request. It would be a design error to ignore it.