1. Post #721

    January 2011
    499 Posts
    Yeah I understand why async might be useful. But this endpoint is only getting a database record by id. Not really super intensive work there...
    Imagine having a OS thread receiving web requests on a web server. That OS thread then services your GET for ID 1. It then sends out an IO request to a database server or another web service and it will be a 100ms round trip. That OS thread sending that request probably takes 1ms-2ms at MOST/WORST case. Instead of 1 thread being able to service 500-1000 requests within a second, you need 500-1000 threads to sit and service and ACTIVELY wait on those requests. You are literally never going to scale.

    When asynchronous programming is so easy, there is no reason you shouldn't be asynchronous from the start. You aren't doing multi-threading parallelism, you are doing asynchronous concurrency.
    Reply With Quote Edit / Delete Reply Windows 7 Firefox Show Events Agree Agree x 1 (list)

  2. Post #722
    faster than stupid, but still slower than everybody else

    June 2010
    3,151 Posts
    Like I said, .Net Core only exposes async methods for Azure Table
    Right, that's why I asked if there was some requirement to using it because the obvious answer seemed to be to just not use async. Not sure what you have tried or even figured it out, but maybe you need to inherit your controller class from AsyncController instead of Controller?

    see: https://stackoverflow.com/questions/...d-does-not-hit

    Asynchronous methods aren't just helpful when it comes to the amount of work. I came across a very helpful article that benchmarks the performance between the different methods of synchronous and asynchronous methods.
    I gotcha, you can also upgrade your infrastructure to handle more requests concurrently. I just personally don't like the idea using the async framework features unless it's really needed because it leads to more complex code and harder to understand, and thus, harder to debug

  3. Post #723
    Gold Member
    horsedrowner's Avatar
    January 2009
    3,348 Posts
    I gotcha, you can also upgrade your infrastructure to handle more requests concurrently. I just personally don't like the idea using the async framework features unless it's really needed because it leads to more complex code and harder to understand, and thus, harder to debug
    I would actually argue the opposite. If you use async/await properly, you signal which functions are expensive and which are not (relatively speaking, of course). Kind of like using methods instead of properties.
    As an example, consider IQueryable. The System.Data.Entity namespace contains Async overloads for all of the methods that execute the query, and none of those that execute on the client. There's CountAsync, but no WhereAsync.

    There's definitely some sort of complexity involved, though. At a glance, it seems simple ("just add async and await") but when you start looking into how it works, it becomes complex and difficult to understand.

  4. Post #724
    Grammar Nazi General
    Adelle Zhu's Avatar
    April 2009
    2,082 Posts
    So I'm at work right now and we have been experiencing some shitty download speeds on large files. Fast.com says we're getting 70mbps which is the tier we're on and all of the small packet functions we do seem fine but large downloads rarely reach above 2mb/s. Is this the fault of the remote server or should I be checking my firewall/router for throttling settings?

  5. Post #725

    January 2011
    499 Posts
    I would actually argue the opposite. If you use async/await properly, you signal which functions are expensive and which are not (relatively speaking, of course). Kind of like using methods instead of properties.
    As an example, consider IQueryable. The System.Data.Entity namespace contains Async overloads for all of the methods that execute the query, and none of those that execute on the client. There's CountAsync, but no WhereAsync.

    There's definitely some sort of complexity involved, though. At a glance, it seems simple ("just add async and await") but when you start looking into how it works, it becomes complex and difficult to understand.
    Async/await makes the user facing code slightly more complicated because most people do not spend a day researching it in my opinion. If delve into it and realize how it works under the covers and understand SynchronizationContext, IO Completion Ports, and what the IL looks like after the transformations, you are able to reason about your code pretty easily.

    Stephen Cleary has a great series of blog posts where he dives deep into Async/Await, .NET TPL, and threading in general. Specifically these two, async and await and there is no thread.

    All new code should be asynchronous in my opinion, it is too easy to not write asynchronous code in .NET whether in a Desktop application, a Windows service, or in ASP.NET.
    Reply With Quote Edit / Delete Reply Windows 7 Firefox Show Events Agree Agree x 1 (list)

  6. Post #726
    Gold Member
    Karmah's Avatar
    December 2007
    6,884 Posts
    I figured out the solution to my problem.

    Earlier in here I posted about how I was trying to do asset sharing across multiple OpenGL contexts.
    I had an issue where it appeared that I was successfully creating texture objects in a separate thread in a different context, as the ID's were incrementing appropriately across the 2 threads, however the textures weren't being sampled from at all.

    I dug into the spec for bindless textures, and fortunately I found that bindless textures creation and sharing is supported across multiple contexts. The same handle works across all of the contexts in the share-group.
    However, texture residency isn't automatic across the share-group

    I don't yet have a smart system for dealing with texture residency; rather I just make them all resident as soon as they are created (which in my case, was in the secondary context)
    Therefore the solution was just to make that same handle resident in the main rendering thread.

    Edit:
    Aw man, I didn't know vertex array objects can't do this either. The vertex buffers can be shared but the array object can't.
    I'm going to have to rethink the layout of some of my systems.

  7. Post #727
    Gold Member
    Karmah's Avatar
    December 2007
    6,884 Posts
    I almost over-engineered a solution to that problem too, luckily I waited and (very last minute) figured out a much more elegant solution.

    I was prepared to write out an entire third class to manage VAO handles per context, using a singleton class and a map of vectors storing VAO's.

    And then I realized that: sure, models are generic and deprived of state, but the components that use them are unique per engine instance; they can just generate their own vertex array objects to encapsulate the model they've requested.

    I can't believe it took me this long to realize this - I would have almost made a horrible horrible mess of my code.