In order to avoid the time spent on the creation of the sockets.
My node server need some "long connection"(TCP Socket) to keep communicating with the server written in C which runs in the background, and all the 'http request' could share the TCP sockets in the pool.
I wonder if there is a kind of socket pool implementation in nodejs? (something like the database connection pool)
Any help will be appreciated !
generic pool is a good one. https://github.com/coopernurse/node-pool
But as for http, there's built-in pooling mechanism .
Take a look at the official documentation for http.Agent; that's what (behind the scenes for most node developers) handles allocation of available sockets.
Related
I have a golang client application talking a server via GRPC. I noticed that while the application is running that the number of sockets accumulated on the client app keeps climbing till around 9000. At which point I pause client. However, after there are no more traffic between the client and the server the number sockets still stayed at that level even after 8 hours.
Is there anyway we can tune GRPC for socket usage? Such as closing sockets after a timeout? Is using streaming another way to limit number of sockets being opened?
Thanks for any help.
I'd start by making sure that your client application cleans up unused connections (grpc.ClientConn) by calling Close() method on it.
Also, since I don't know what exactly your application does so I'm gonna go ahead and suggest reusing connections for multiple RPCs (you're probably already doing this).
And to answer your question about setting timeout deadline on connections:
1. You shouldn't have to do this. Feel free to open up an issue on https://github.com/grpc/grpc-go about whatever gRPC shortcoming is forcing you to take this route.
2. But if you must know, you can use a custom dialer(https://github.com/grpc/grpc-go/blob/13975c070286c7371aa3a8b3c230e90d7bf029fc/clientconn.go#L333) and set a deadline on the net.Conn that you return from it.
Best,
Mak
I've been researching memcached, and I'm planning on using that with spymemcached on the client. I'm just curious how client/server communication works between the two. When creating a memcached client object, you can pass in a list of servers, but after the client is created is there any communication between the servers and the client saying that they are still alive and that the client send that particular server information? I've tried looking through the memcached and spymemcached documentation sites, but haven't found anything yet.
Spymemcached does not send any special messages to make sure that the connection is still alive, but you can do this in your application code if necessary by sending no-op messages to each server. You should also note that the TCP layer employs mechanisms such as keep-alive and timeout in order to try to detect dead connections. These parameters however may be different depending on the operating system you are using.
I am working on a client/server application. I have ready many articles for this and found a very common statement that "Creation/deletion of socket is very expensive process in terms of using system resources". But no where it is explained how it is consumes so much resources.
Can anybody give glimpse view on this?
Creating socket is cheap. Connecting it actually creates the connection, which is more or less as expensive as creating the underlying connection, specially TCP connection. TCP connection establish requires the three-way TCP handshake steps. Keeping connections live costs mainly memory and connections. Network connections are a resource limited by the operation systems (for example number of sockets on a port).
If you are using thread model additional thread creation resources needed.
I could find a useful like to your answer "Network Programming: to maintain sockets or not?" on Stackoverflow. And a useful article Boost socket performance on Linux
I think helpful to you.
I've been trying to implement a web server gateway (for fun and educational purposes) and I have some questions about the core architecture behind FastCGI/SCGI with respect to the pre-fork model.
How do FastCGI/SCGI implementations handle communication in pre-fork scenarios? AFAIK, the gateway only has one socket to connect to the FastCGI server. Normally, there is a parent process that accepts connections from the gateway and hands off the work to one of the pre-forked workers.
Since the connections are established after the children are forked, how are you supposed to have the children use these sockets to communicate with the gateway?
I hope I understood the question.
The server socket should be created by the parent process; when it forks, children inherit that socket making it a shared resource. Then, I suppose, each child tries to accept() connections concurrently.
As a reference I found this document (see "accept serialization") discussing starvation issue when listening on multiple sockets, and this SO discussion on sharing sockets
One options is file descriptor passing over UNIX domain socket. Stevens UNP has basic example.
I have this question asked in the Go mailing list, but I think it is more general to get better response from SO.
When work with Java/.Net platform, I never had to manage database connection manually as the drivers handle it. Now, when try to connect to a no sql db with very basic driver support, it is my responsibility to manage the connection. The driver let connect, close, reconnect to a tcp port, but not sure how should i manage it (see the link). Do i have to create a new connection for each db request? can I use other 3rd party connection pooling libraries?
thanks.
I don't know enough about MongoDB to answer this question directly, but do you know how MongoDB handles requests over TCP? For example, one problem with a single TCP connection can be that the db will handle each request serially, potentially causing high latency even though it may be bottlenecking on a single machine and could handle a higher capacity.
Are the machines all running on a local network? If so, the cost of opening a new connection won't be too high, and might even be insignificant from a performance perspective regardless.
My two cents: Do one TCP connection per request and just profile it and see what happens. It is very easy to add pooling later if you're DoSing yourself, but it may never be a problem. That'll work right now, and you won't have to mess around with a third party library that may cause more problems than it solves.
Also, TCP programming is really easy. Don't be intimidated by it, detecting a closed socket, and reconnecting synchronously or asynchronously is simple.
Most mongodb drivers (clients) will create and use a connection pool when connecting to the server. Each socket (connection) can do one operation at a time at the server; because of how data is read off the socket you can issue many requests and server will just get them one after another and return data as each one completes.
There is a Go mongo db driver but it doesn't seem to do connection pooling. http://github.com/mikejs/gomongo
In addition to the answers here: if you find you do need to do some kind of connection pooling redis.go is a decent example of a database driver that pools connections. Specifically, look at the Client.popCon and Client.pushCon methods in the source.