Memcached module -- unix domain socket support? (too many TIME_WAITs..)

[Chancey]

Yes, i meant this like you.
Using memcached can avoid disk I/O. I guess that is why he used memcached on localhost.

sorry , my english very pool.



2008-08-01 



Chancey 



发件人： Igor Sysoev 
发送时间： 2008-08-01  14:39:19 
收件人： nginx at sysoev.ru 
抄送： 
主题： Re: Re: Memcached module -- unix domain socket support? (too many TIME_WAITs..) 
 
On Fri, Aug 01, 2008 at 02:27:55PM +0800, Chancey wrote:

> Maybe I/O is too high ? 
> Use memcached can avoid this .

Using local memcached means that all data can fit in memory, therefore
local filesystem data will be cached by OS VM and there will not be
high disk I/O.

> ?????? Re: Memcached module -- unix domain socket support? (too many TIME_WAITs..) 
>  
> On Thu, Jul 31, 2008 at 09:54:03PM -0700, Kon Wilms wrote:
> 
>  > I have a pool of memcached servers running on localhost with
>  > connection to nginx, feeding motion jpeg data out via static JPEGs to
>  > a flash application. The load is pretty high on the server because of
>  > this with each client running 3 GETs from memcached every second (i.e.
>  > 3fps).
>  > 
>  > Nginx works fine, however, the problem I have is that thousands of
>  > TIME_WAITs are created from the memcached GET requests, which I would
>  > like to eliminate. I've already tuned the kernel but this has not
>  > reduced it enough to handle a couple thousand viewers on the server.
>  > 
>  > Is there any way to connect nginx's memcached module to memcached via
>  > unix domain socket or perhaps UDP, or any other ideas on how to fix
>  > this problem?
> 
> Adding unix socket support to ngx_http_memcached_module should be easy,
> but I'm not sure if memcached suppot unix sockets.
> 
> BTW why do you serve local images from memcached ?
> It's better for both CPU and memory to serve them from local filesystem
> using sendfile.
> 
> 
> -- 
> Igor Sysoev
> http://sysoev.ru/en/

-- 
Igor Sysoev
http://sysoev.ru/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080801/4a08c6db/attachment.html>