Hello,
it would be hard to give you a complete solution without knowing many
more details about your application.
So to comment on just one part, spawning goroutine, or two, per
connection. It is absolutely THE correct way in Go. All those goroutines
will be effectively mapped to system threads by the Go scheduler, and
you need not worry too much about that, like in other languages. It's
one of the distinct Go advantages, where developers job is easier thanks
to simple yet very powerful abstractions.
Now, the number of goroutines will grow if you have many connections,
but how many is too much? I've successfully launched hundreds of
thousands of goroutines on the notebook I'm typing this message on, and
the machine was perfectly usable whole time. And I was limited only by
available memory, mind you. So, on the adequate server... you get the idea.
If you really care about the number of goroutines, then you should
concentrate on proper timeouts and error handling, so in the case that
systems you interface with are too slow or get unavailable, that you
exit stale goroutines properly at some point, not just continue
accumulating them.
Also, it could be that diameter server you mention is too slow because
your Go app is too efficient. :) In that case you will need to actually
limit the concurrency in your app, to give the diameter time to process
all incoming requests.
Googling "golang concurrency patterns" will give you a lots of material
to chew on and learn. I would advise reading the results from
blog.golang.org first, because they're of high quality and very
insightful, you can learn a lot from simple examples there.
On 25.08.2016 08:41, kvrat...@gmail.com wrote:
Hi all,
I'm looking for some good practices of concurrent programming in Go.
My software works and even customer satisfied :). But I feel job doesn't done
perfectly.
The task was to convert some well documented but proprietary protocol to
Diameter with custom dictionary.
But my feelings are not about protocols but about concurrent model which I
implemented.
I spawn goroutline per connection and this goroutline is responsible to
assembly protocol messages from tcp stream.
Then I spawn another goroutline to process protocol message (calculate Crc and
etc and make request to Diameter server, receive answer from Diameter server,
and send response to server).
This per-message goroutline gets two arguments. There are request and channel.
As soon as per-request goroutline creates response it sends it to channel.
Channel is processed by per-connection goroutine to send response.
I feel this simple model is not correct and stable under load. For example
diameter server can be slow and number of goroutines and channels will grow
dramatically.
When I did similar job in erlang I used this process model. But there
supervisor controlled per-request workers.
Originally C-version uses several native threads with async logic (select and
epoll) inside them.
Probably same async model can be implemented in Go by I would like to have
benefits of Go using its concurrency features.
Could you advise correct concurrent model for my task?
--
Zlatko
--
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.
