3 ms·

Re: It is if you're doing it right. Well, okay, but the typical suggestion is to use async/await even if your app logic is not currently intended to be divided

by tabtab 7y ago

Re: It is if you're doing it right. Well, okay, but the typical suggestion is to use async/await even if your app logic is not currently intended to be divided that way. Is it a "keep up good habits" suggestion? Unless scaling up happens a lot in a shop in a way that can be app-side parallelitized, I'd say YAGNI dictates to leave it out of app logic. (I deal mostly with database-heavy work-oriented CRUD-ish apps, not social networking and ad-funded sites, by the way.) Re: If a request takes 10x as long, it will have 10x requests in flight at any given time. That assumes the app logic is "parallelitized" per above, doesn't it? Otherwise, the processing time per request shouldn't be different because async/await-ing database/network calls will not make them process faster by itself. By the way, I couldn't find much info on "session cookie servers". Is that usually a roll-your-own kind of task, perhaps with the aid of an API? Hey, I think your diagram came out as you intended. Kudos! Ascii U.

nostrademons 7y ago
> Well, okay, but the typical suggestion is to use async/await even if your app logic is not currently intended to be divided that way. Is it a "keep up good habits" suggestion? Unless scaling up happens a lot in a shop in a way that can be app-side parallelitized, I'd say YAGNI dictates to leave it out of app logic. (I deal mostly with database-heavy work-oriented CRUD-ish apps, not social networking and ad-funded sites, by the way.) For that domain you could take it or leave it. Async/await is most helpful when you have lots of users hitting a server with lots of backends; if it's a few users hitting 1 webserver with 1 DB, performance gains will be marginal, and it's functionally equivalent to blocking calls but with some extra syntactic overhead. The deciding factor will probably be what libraries you need to support: many libraries are moving to async/await because they don't want consumer/HPC applications as customers. > By the way, I couldn't find much info on "session cookie servers". Is that usually a roll-your-own kind of task, perhaps with the aid of an API? Google has a custom server for this because of security needs to validate signed cookies & timeouts, but most sites on the outside just stick a JSON or protobuf record into memcached or Redis and fetch it. It usually is a separate fetch before many of the other database calls, though, because most (consumer) sites have some notion of a session and saved user state that's independent of the user record, because you frequently get anonymous users who don't have an account. So it might physically be on the same Redis or memcached box, but still requires separate network round-trips.
- tabtab 7y ago
  Re: if it's a few users hitting 1 webserver with 1 DB, performance gains will be marginal Let's say it's 4 web servers hitting 4 DB's, but otherwise most of the app logic code will not be parallelitized?

by tabtab 7y ago

nostrademons 7y ago

> Well, okay, but the typical suggestion is to use async/await even if your app logic is not currently intended to be divided that way. Is it a "keep up good habits" suggestion? Unless scaling up happens a lot in a shop in a way that can be app-side parallelitized, I'd say YAGNI dictates to leave it out of app logic. (I deal mostly with database-heavy work-oriented CRUD-ish apps, not social networking and ad-funded sites, by the way.) For that domain you could take it or leave it. Async/await is most helpful when you have lots of users hitting a server with lots of backends; if it's a few users hitting 1 webserver with 1 DB, performance gains will be marginal, and it's functionally equivalent to blocking calls but with some extra syntactic overhead. The deciding factor will probably be what libraries you need to support: many libraries are moving to async/await because they don't want consumer/HPC applications as customers. > By the way, I couldn't find much info on "session cookie servers". Is that usually a roll-your-own kind of task, perhaps with the aid of an API? Google has a custom server for this because of security needs to validate signed cookies & timeouts, but most sites on the outside just stick a JSON or protobuf record into memcached or Redis and fetch it. It usually is a separate fetch before many of the other database calls, though, because most (consumer) sites have some notion of a session and saved user state that's independent of the user record, because you frequently get anonymous users who don't have an account. So it might physically be on the same Redis or memcached box, but still requires separate network round-trips.

tabtab 7y ago
Re: if it's a few users hitting 1 webserver with 1 DB, performance gains will be marginal Let's say it's 4 web servers hitting 4 DB's, but otherwise most of the app logic code will not be parallelitized?