Many instances question - shared library

[Luke Mauldin]

I have deployed a Go shared library on Linux that exposes C functions as extension points for a 3rd party application and is loaded dynamically at runtime. The 3rd party application then invokes "C" functions (which are backed by Go) and that is all working as expected.  However, due to the nature of the application, there maybe 100 or 200 instances of the 3rd party application running on the server at any given time and each of those is loading its own copy of the Go shared library so I have to "pay the penalty" of the Go runtime for each process.  Has anyone else encountered this scenario?  Is there anything I can do to reduce this cost?  I have already done simple things like setting GOMAXPROCS 1 because generally there will only be 1 primary goroutine running in each instance.

I have looked at tinygo but that seems to be targeting a different use case.  Any other recommendations?

Luke

[Amnon Baron Cohen]

> However, due to the nature of the application, there maybe 100 or 200 instances

Interesting...
Could you elaborate the nature of the application, and why a single instance is not enough... 

[Luke Mauldin]

The multiple instances are required to due to way the 3rd party application works. In brief, it creates a new process for each user connection and then each new process dynamically load the Go shared library to provide C extension points.

[Amnon Baron Cohen]

That does not sound like a scalable architecture!

The number of simultaneous user connections the architecture can support is limited to the number of processes 
your server can run. The resources required by a process are orders of magnitude more than those required for a goroutine.
And the Go runtime adds to that.

Three options:
1) rewrite third party app in Go to run in a single process with a goroutine per connection
2) don't use Go for your extension
3) Write a stub extension in C which talks over gRPC to a single Go server instance

[Luke Mauldin]

I agree that it is not a scalable architecture but unfortunately it is a large third party application the business depends on and it cannot be rewritten. Option 3 to use grpc is a good idea but unfortunately won’t work either because the Go shared library invokes C function calls back into the process that loaded it to perform work.
Long term, I am looking at having to rewrite the Go shared library into a language that doesn’t have a runtime like C++ or Rust but in the meantime I was checking to see if there is anything I can do to lessen the Go runtime overhead in this unique situation.