Re: [go-nuts] Highly Concurrent Web Service Development With Go

[André Moraes]

On Wed, May 15, 2013 at 6:56 PM, Mike <mikes...@gmail.com> wrote:
> I am new to GO and I am not sure as how GO should be best used for the
> development of a highly concurrent web service.

Sure it does, Go was designed to do that.

> Imagine I want to build a web service(most probably a rest service) were it
> is supposed to process many concurrent requests. The thing is that for every
> request that arrives at the web service, some has to be processed
> sequentially and some can be processed in parallel. How should I go about
> doing so? Should the web service have some kind of go routine entrance that
> depending on the call, it will send it to another GO routine responsible for
> processing those requests and dynamically instantiate a GO routine for every
> request that can be handled in parallel and send the request to it?

First: just read the golang.org/pkg/net/http and learn how to use that
package (take the go tour too)
Second: Read http://golang.org/doc and give some attention to the
Talks topic (watch all videos)

Third: What do you mean by: some services can be run parallel and
others can't? The client can't make two requests or the server can
only handle one single request to the given service?

> I want the client code to be blocking so that the client don't care how the
> request is being handled and the just get a response on their synchronous
> call. How will I make the web service not to return to the client until the
> associated go routine is done handling the request?

Just don't exit the handler function, usually this is done using a
channel to block the thread while the response is built.

> Is this how you will build such web service? How else will you build a
> Highly Concurrent Web Service With Go?

--
André Moraes
http://amoraes.info

[dlin]

Suggest you to understand this code.  Use channel to let your server be 'lockless'. (In fact, the lock did by Go native).

I'm still try to convert my brain from C's lock method into channel style.  If you can do you can build your highly concurrent web service.

If you are still use C's lock method, I support the web server performance is worse than C implementation.

http://golang.org/doc/codewalk/sharemem/

On Thursday, May 16, 2013 5:56:24 AM UTC+8, Mike wrote:

I am new to GO and I am not sure as how GO should be best used for the development of a highly concurrent web service. 

Imagine I want to build a web service(most probably a rest service) were it is supposed to process many concurrent requests. The thing is that for every request that arrives at the web service, some has to be processed sequentially and some can be processed in parallel. How should I go about doing so? Should the web service have some kind of go routine entrance that depending on the call, it will send it to another GO routine responsible for processing those requests and dynamically instantiate a GO routine for every request that can be handled in parallel and send the request to it? 

I want the client code to be blocking so that the client don't care how the request is being handled and the just get a response on their synchronous call. How will I make the web service not to return to the client until the associated go routine is done handling the request?

[Mike]

Thanks for the response. Perhaps, I was not very clear with my question.

I really want to know how to make non-blocking web service in GO. I want my web service entrance function just act as a router and simply routes the incoming request to the proper go routines but do not return to the client until the go routine associated to the request has replied back to the entrance function with the result. it is then when I expect the entrance function to return back to the client with the reply. I do not want the service entrance to block while the last request is being processed by the other go routines and I just want it to continue accepting calles from others and just queue it on the proper go routine. 

Does this make sense?

How else would you go about building an non-blocking highly concurrent web service in GO?

[Mike]

Thank you Dlin. I will look at that code. Would you please explain how do I not cache the http request and return to client when I want to without blocking the thread?

[James Bardin]

Go does this all be default with the standard library.

Start off by going through the Go docs, and you'll be on your way.

-jim

[Tad Glines]

Mike,

This example (http://play.golang.org/p/pid0dBgT7d) is the classic go web server hello world.

It can handle over 10,000 concurrent connections. It's limits are the limits of the OS+Hardware that host it.

For example, even on a stock OSX system it can handle about 4-10K requests per second, and (at slower requests rates, over 10K concurrent connections). On linux systems with tuned TCP stacks it can do much more.

Each request is handled in a separate goroutine. When a request arrives, a new goroutine is spawned and the handler is invoked in that goroutine. A goroutine is NOT a system thread, it is more like a coroutine or green thread. Each goroutine initially only consumes about 4K and can grow its stack as needed.

--
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/groups/opt_out.
 
 

[André Moraes]

> I really want to know how to make non-blocking web service in GO. I want my
> web service entrance function just act as a router and simply routes the
> incoming request to the proper go routines but do not return to the client
> until the go routine associated to the request has replied back to the

If you use net/http server, all requests are non-block, ie, they run
on separated goroutines.

> entrance function with the result. it is then when I expect the entrance
> function to return back to the client with the reply. I do not want the
> service entrance to block while the last request is being processed by the
> other go routines and I just want it to continue accepting calles from
> others and just queue it on the proper go routine.

This should solve your problem:

http://play.golang.org/p/uI3yqYs3wV

[Tad Glines]

> entrance function with the result. it is then when I expect the entrance

> function to return back to the client with the reply. I do not want the
> service entrance to block while the last request is being processed by the
> other go routines and I just want it to continue accepting calles from
> others and just queue it on the proper go routine.

This should solve your problem:

http://play.golang.org/p/uI3yqYs3wV

All that is unnecessary. If you look at http://tip.golang.org/src/pkg/net/http/server.go line 1564, you'll see that after accepting a connection a new goroutine is spawned to handle that connection. A request handler does not block acceptance of new connections.

[André Moraes]

>>
>> http://play.golang.org/p/uI3yqYs3wV
>
>
> All that is unnecessary. If you look at
> http://tip.golang.org/src/pkg/net/http/server.go line 1564, you'll see that
> after accepting a connection a new goroutine is spawned to handle that
> connection. A request handler does not block acceptance of new connections.
>

Yes I knew that, but he also said that some requests should be handled
in the order they arrive and others could be handled out of order or
in parallel. That's the reason for the channel/goroutines.

[Tad Glines]

Ah, I see. You where replying to his first question, which included the need to process some requests serially.

His second restatement only included the desire to avoid blocking the acceptance of new connections, and I thought that was what you where responding to.