> Yes. > OS doesn't pre-allocate the full buffer. > > Yes. > Memcached should easily handle million concurrent idle connections (given > enough memory). > > Except, if user has only allocated 512MB/1GB RAM for TCP, it is "possible" at > runtime only four connections have eaten up all the memory, which > could lead to connection refused or some other errors. > > Lets revisit the question. > Is memcached unable to handle large no of concurrent connection? > Usually no. Under some circumstances. Yes. > > And yes, don't guess. Just try it. Open <server_tcp_mem/256MB> connections > with large multi-get request (response > 256MB) and don't read them at > client side. And then try opening more connections.
Usually no?? Are you sure you mean usually it can't handle it? That is insanely wrong. Memcached runs on LAN's almost all of the time. There are almost NO buffers stuck in use because of the low latency. This isn't an internet facing tool, wherein you have to tune that more carefully and leave a lot more free memory for TCP retransmits. Connections to memcached use a handful of kilobytes. So very few people are going to run into this problem, complaining about it is nothing short of alarmist. It's also never going to be 256MB: The actual memory used is limited (in linux) by the tcp_rmem and tcp_wmem set of sysctl's. Even when people aggressively tune those, they set the maximums around 16 megabytes. Usually it's much lower than that. SENDBUF can't use more than what's in wmem. -- --- 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 memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
