> Why make them concurrent if you need to know to know the end result of the DB call *before* opening the file?
I actually don't need to know the result of the DB call before opening the file, only before sending the file as a response. > only use goroutines when you know for a fact that you have an issue which needs solving via concurrency Thanks, that's a good advice. So the question now comes to how to easily benchmark the written code. I haven't done anything like that, but from docs it seems I should use the benchmark functions from the testing package? On Tuesday, July 25, 2017 at 8:44:10 AM UTC+8, nat...@honeycomb.io wrote: > > > I need to query a db to get its content type and then send the actually > file that lives on the file system. Now the question is, should I put > db.QueryRow and os.Open each in a goroutine to make them concurrent? > > Why make them concurrent if you need to know to know the end result of the > DB call *before* opening the file? > > > Should I writing things sequentially by default and only when hitting > performance problems do I profile the program and wrap calls in goroutine? > > Personally I would say yes, only use goroutines when you know for a fact > that you have an issue which needs solving via concurrency, e.g., IO-bound > workloads. While it's nice to have goroutines and channels within easy > reach, they do complicate program structure and can cause data races if not > used properly. Unless your app is problematically slow, design everything > to be as simple as possible. People tend to assume things like "DB queries > are slow" or "filesystem access is slow", but that doesn't mean doing > either of those things will cause issues, and even if they do, solutions > such as adding indexes to problematic fields or doing caching might help A > LOT more than trying to be more concurrent will. > > > On Monday, July 24, 2017 at 8:34:30 AM UTC-7, Glen Huang wrote: >> >> Hi, >> >> I'm still pretty new to go. Hope this question isn't too stupid. >> >> I'm writing a restful API server, and in order to send a response, I need >> to query a db to get its content type and then send the actually file that >> lives on the file system. Now the question is, should I put db.QueryRow and >> os.Open each in a goroutine to make them concurrent? >> >> And a more general question is, when using APIs from the stdlib or >> 3rd-party packages, how do I determine whether to wrap them in goroutines >> when more than one of them need to happen sequentially and the order >> actually doesn't matter? Should I manually time the API executions to make >> the call? Should I writing things sequentially by default and only when >> hitting performance problems do I profile the program and wrap calls in >> goroutine? >> >> How do you decide when to use goroutines? >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
