More generally, it becomes pretty clear when you're using a tool for something it's not really meant to do. PHP is an okay programming language/runtime, but there are other tools that would do some of these jobs better, hence our interest in Go and Python.
Recently, on a short term contract, I had to deal with a lot of PHP code that was running in a similar manner. I ended up using golang, to monitor the queue and spin up Goroutines that executed the PHP code ONCE. Between the concurrency, and php back in "one and done" mode the problem was "solved" and the internal team happily took over finishing the porting to pure Golang. Its a great example of Go "in the small" and it really does shine.
Go "in the large" is a whole other matter. You should read the following (in this order)
http://thenewstack.io/a-survey-of-5-go-web-frameworks/ <<< Im a user of gorilla/mux gorilla/context and alice for middleware chains. Gorilla/context and alice are not mentioned by this article, but the lament a the end about the concept of context being lacking in golang is spot on.
https://blog.golang.org/context <<< but this would be better for context however its does not mix with the current HTTP server (no ones solution does)... its from the go team but there isn't a lot of indication on how to use it and be future proof
https://joeshaw.org/net-context-and-http-handler/ <<< explains the context package well
https://github.com/remind101/pkg <<< has wrappers for getting net/context into gorilla and alice..
The end result is non of the GO web support is what I would call "great" yet. However it isn't stopping me from building with them. Look at the tradeoffs your going to have to make, be smart about how you couple your business logic to your server/framework, as your framework will quickly become a hard dependency. If your careful in that implementation, this http://blog.golang.org/introducing-gofix might be a way to back out one of those dependency if your unhappy.
The tooling to help you root out an issues exists and you should know its there and how to use it: http://blog.golang.org/profiling-go-programs http://saml.rilspace.org/profiling-and-creating-call-graphs-... https://deferpanic.com/blog/compile-time-code-weaving-in-go/
On Golang:
1. There are a bunch of good frameworks out there for you to bootstrap with -- if you pick one realize its going to have shortcomings -- if you don't pick one and you think your going to use the standard library + tools like gorilla and alice, your going to end up doing a lot more work than you expect. -- a lot of the info on this front is stale, look for the context package on the google blog to see how the thinking is evolving (and its pretty rational)
2. There are parts of Go that look great on the surface, and work for "small programs" but if your building in the large they are going to be lacking. Logging is the example that comes to mind, and a lot of the "solutions" are just coming up short at the moment. Profiling on OSx being broken is another (and this isn't the fault of the GO, but rather apple.
3. Your going to have a very different workflow with go than you do with a python or PHP. This same would hold true if you moved from PHP to C or java. The distinction is that C and Java have a LARGE toolchain to support your transition, here again Go is lacking.
All that having been said, I would choose Golang over Python or PHP for what your trying to do. Your going to pay a large tax upfront (in both ramp up and real time development costs) for something that (potentially if you don't screw it up) is much more maintainable in the long run.