I had this configured in this way: Before a client starts, it already has a connection to the memcached. For the moment, this is the only one connection. Maby a reconnect is needed as well if the connection is not open. Parent opens the connection to the next request when the child detaches. (I also have a possibility to use from two to three client processes and one of them has some time when other ones are working, so the opening of a new connection may not be a problem. Still.)
I know that TCP connections may stop after a while even if it's being used all the time. It may be a spanning tree of bridges and routers for example and there is a timeout in different protocols including TCP. Also, if the server is going to be loaded, a pool of connections would be nice. How can I make the connections usable constantly in the pool, do I have to check the connection once in a while? Just select something from the stats for example? One possibility would be to use shared memory. How about a memcached pool in a shared memory? Could that be possible? With threads for example (from the memcached library). One possibility could be a filesystem socket? Between different operating systems (Unix/Linux), file system sockets are available, sometimes they aren't. I don't see any problems if all of the connections are available in the client. The client process tries to free them at the end and maby this causes problems. Otherwice it would be ok. With best regards, Jouni maanantai 25. heinäkuuta 2016 19.48.25 UTC+3 Jay Grizzard kirjoitti: > > You can’t really usefully duplicate the open connection fd this way — if > you think about it, when you duplicate a network fd, the new fd has the > same endpoints (srcip:srcport dstip:dstport) as the original, meaning there > would be no way for the local system to know which of your multiple > processes a response is destined for. There’s still only one TCP stream, no > matter how many pointers you have to it. > > If you’re just going to fork a new process, hit memcache once, and then > exit, you really don’t have any options besides “don’t use persistent > connections and open a new connection with each process”. If performance is > *super* critical (…which it’s not, if you’re forking a new process per > request), you could do memcache over UDP, but you probably don’t need/want > to do that. > > -j > > On Mon, Jul 25, 2016 at 3:17 AM, <[email protected] <javascript:>> wrote: > >> >> A traditional web-server application forks a new process for every >> request with 'fork' (man -s2 fork). Question how to use memcached_pool with >> processes. >> >> With processes, the memory is isolated between the processes. After fork, >> the whole memcached_pool is doubled to a new process. Freeing the memory >> after the request is served and the child process is closing, causes an >> instability (was it an illegal close or a segfault). In addition, copying >> the pool to each client does not seem to be reasonable. >> >> The solution in use now is to use 'memcached' instead of >> 'memcached_pool_pop' to get a new connection (allways to the next client >> process). It is recommended in the ~/doc/protocol.txt that the memcached is >> used with multiple open connections and not to open a new connection every >> time. >> >> What is the best practise with 'fork'? >> >> How can I make my server application faster? Is it possible to use >> 'memcached_pool'? Is it somehow possible to just 'dup' the memcached socket >> connection somehow or is dupping the socket connections this way possible >> at all? >> >> With best regards, >> >> Jouni >> >> >> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "memcached" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
