> Go can do what Nginx can't. But what Nginx can do, it will do it faster than Go.
Ok. I expect Go to be slower then NGNIX as well but I do not know if it is 20% slow, twice slower or 10 times slower.
Also I expect it to consume more memory.
NGNIX is very fast. Even smallest cloud instances or Intel Atom servers are able to utilize 1Gbit without encryption.
If Go will do 300-500 mbit when nginx does 1gbit then it make sense.
(Cloud instances often have real 20-100mbit connection. When Hypervisor is connected to 1Gbit)
Also I expect Go consume more memory and it is still not clear how much more.
Interesting how Go encryption performance compares to NGNIX encryption.
FastCGI client must understand that FastCGI server has 8, 10 or 16 processes and it will not provide extra one if requested.
So design of such system may include 1 channel.
RequestHandlers read for FastCGI connection from channel and after request is processed FastCGI connection is released by sending it back to same channel.
May be there must be second channel for dead connections.
Seems like there is no production ready solution right now.
I have seen similar code but on google code
This one looks to be later version. I seen references that version of that code on google code has some bug.
This code has following lines
this.mutex.Lock()
defer this.mutex.Unlock()
I guess it is not the Go way to handle concurrency.
May be that code is ported FastCGI java servlet.
I am still looking for some mature code that is used in production by someone.