FAQ
Hello Gophers.

I have an HTTP endpoint that may or may not incur massive disk IO depending
on the incoming request. I do not intent to limit the amount of disk IO
operations and would like the endpoint to run to its full throughput
potential.

Effective-Go taught me: "(goroutine) if one should block, such as while
waiting for I/O, others continue to run."
So is it OK to leave the IO operation in the HTTP request handler, and let
Go runtime handle the rest? And how many goroutines does net.http server
use for concurrent requests?

Thanks!

Regards,
Howard

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Brad Fitzpatrick at Jul 7, 2015 at 7:47 pm
    Don't be afraid to block on slow operations (like I/O in any goroutine),
    and don't be afraid to use tons of goroutines.

    net/http uses one goroutine per HTTP request.

    On Tue, Jul 7, 2015 at 6:16 AM, Howard Guo wrote:

    Hello Gophers.

    I have an HTTP endpoint that may or may not incur massive disk IO
    depending on the incoming request. I do not intent to limit the amount of
    disk IO operations and would like the endpoint to run to its full
    throughput potential.

    Effective-Go taught me: "(goroutine) if one should block, such as while
    waiting for I/O, others continue to run."
    So is it OK to leave the IO operation in the HTTP request handler, and let
    Go runtime handle the rest? And how many goroutines does net.http server
    use for concurrent requests?

    Thanks!

    Regards,
    Howard

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Di3go Bernardes at Jul 7, 2015 at 8:57 pm
    bradfitz, even in case where the i/o is in disk?
    in a concurrency environment + disk i/o, all threads gonna be locked most
    of the time.
    Em terça-feira, 7 de julho de 2015 16:47:48 UTC-3, bradfitz escreveu:

    Don't be afraid to block on slow operations (like I/O in any goroutine),
    and don't be afraid to use tons of goroutines.

    net/http uses one goroutine per HTTP request.


    On Tue, Jul 7, 2015 at 6:16 AM, Howard Guo <guoh...@gmail.com
    <javascript:>> wrote:
    Hello Gophers.

    I have an HTTP endpoint that may or may not incur massive disk IO
    depending on the incoming request. I do not intent to limit the amount of
    disk IO operations and would like the endpoint to run to its full
    throughput potential.

    Effective-Go taught me: "(goroutine) if one should block, such as while
    waiting for I/O, others continue to run."
    So is it OK to leave the IO operation in the HTTP request handler, and
    let Go runtime handle the rest? And how many goroutines does net.http
    server use for concurrent requests?

    Thanks!

    Regards,
    Howard

    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Brad Fitzpatrick at Jul 7, 2015 at 10:16 pm
    If you find yourself with too many threads (as opposed to too many
    goroutines), you can put a semaphore in front of your I/O. e.g.
    http://godoc.org/golang.org/x/tools/godoc/vfs/gatefs

    On Tue, Jul 7, 2015 at 2:57 PM, wrote:

    bradfitz, even in case where the i/o is in disk?
    in a concurrency environment + disk i/o, all threads gonna be locked most
    of the time.
    Em terça-feira, 7 de julho de 2015 16:47:48 UTC-3, bradfitz escreveu:

    Don't be afraid to block on slow operations (like I/O in any goroutine),
    and don't be afraid to use tons of goroutines.

    net/http uses one goroutine per HTTP request.

    On Tue, Jul 7, 2015 at 6:16 AM, Howard Guo wrote:

    Hello Gophers.

    I have an HTTP endpoint that may or may not incur massive disk IO
    depending on the incoming request. I do not intent to limit the amount of
    disk IO operations and would like the endpoint to run to its full
    throughput potential.

    Effective-Go taught me: "(goroutine) if one should block, such as while
    waiting for I/O, others continue to run."
    So is it OK to leave the IO operation in the HTTP request handler, and
    let Go runtime handle the rest? And how many goroutines does net.http
    server use for concurrent requests?

    Thanks!

    Regards,
    Howard

    --
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Edward Muller at Jul 8, 2015 at 1:05 am
    One per request:
    http://golang.org/src/net/http/server.go?s=51504:51550#L1714
    On Tue, Jul 7, 2015 at 6:16 AM, Howard Guo wrote:

    Hello Gophers.

    I have an HTTP endpoint that may or may not incur massive disk IO
    depending on the incoming request. I do not intent to limit the amount of
    disk IO operations and would like the endpoint to run to its full
    throughput potential.

    Effective-Go taught me: "(goroutine) if one should block, such as while
    waiting for I/O, others continue to run."
    So is it OK to leave the IO operation in the HTTP request handler, and let
    Go runtime handle the rest? And how many goroutines does net.http server
    use for concurrent requests?

    Thanks!

    Regards,
    Howard

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    Edward Muller
    @freeformz

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 7, '15 at 1:16p
activeJul 8, '15 at 1:05a
posts5
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase