RE: UNSUBSCRIBE
Thanks for the tip Aniketh. I would appreciate if somebody on this group could tell me about a more definitive solution to this issue. Saurabh Dasgupta Microsoft Limited (company number 01624297) is a company registered in England and Wales whose registered office is at Microsoft Campus, Thames Valley Park, Reading, RG6 1WG -Original Message- From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On Behalf Of aniketh patrick Sent: 30 January 2009 07:37 To: memcached@googlegroups.com Subject: Re: UNSUBSCRIBE well if you really have to unsubscribe and you don't want to see any more memcached mails but you are still getting messages then the fastest way would be create a filter and route it to trash which will ensure no mails memcached mails in your inbox :) that was 47 words, if anyone was wondering regards, aniketh On Fri, Jan 30, 2009 at 12:17 PM, Saurabh Dasgupta wrote: > > Hi Nick, > I am still receiving the emails inspite of my unsubscribing using the link > given below. It has been a couple of weeks now. Any reason why? > > thanks, > Saurabh > > > > From: memcached@googlegroups.com [memcac...@googlegroups.com] On Behalf Of > NICK VERBECK [nerdyn...@gmail.com] > Sent: Friday, January 30, 2009 5:02 AM > To: memcached@googlegroups.com > Subject: Re: UNSUBSCRIBE > > Unsubscribe here: > > http://groups.google.com/group/memcached/subscribe > > > On Thu, Jan 29, 2009 at 9:52 PM, Gaurav Arora wrote: >> I have been wondering how to do the same too ... >> >> >> >> -- >> >> Regards, >> >> Gaurav Arora >> >> >> >> From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On >> Behalf Of Ben Standefer >> Sent: Friday, January 30, 2009 5:54 AM >> To: memcached@googlegroups.com >> Subject: UNSUBSCRIBE >> >> >> >> UNSUBSCRIBE > > > > -- > Nick Verbeck - NerdyNick > > NerdyNick.com > SkeletalDesign.com > VivaLaOpenSource.com > Coloco.ubuntu-rocks.org >
Re: UNSUBSCRIBE
well if you really have to unsubscribe and you don't want to see any more memcached mails but you are still getting messages then the fastest way would be create a filter and route it to trash which will ensure no mails memcached mails in your inbox :) that was 47 words, if anyone was wondering regards, aniketh On Fri, Jan 30, 2009 at 12:17 PM, Saurabh Dasgupta wrote: > > Hi Nick, > I am still receiving the emails inspite of my unsubscribing using the link > given below. It has been a couple of weeks now. Any reason why? > > thanks, > Saurabh > > > > From: memcached@googlegroups.com [memcac...@googlegroups.com] On Behalf Of > NICK VERBECK [nerdyn...@gmail.com] > Sent: Friday, January 30, 2009 5:02 AM > To: memcached@googlegroups.com > Subject: Re: UNSUBSCRIBE > > Unsubscribe here: > > http://groups.google.com/group/memcached/subscribe > > > On Thu, Jan 29, 2009 at 9:52 PM, Gaurav Arora wrote: >> I have been wondering how to do the same too … >> >> >> >> -- >> >> Regards, >> >> Gaurav Arora >> >> >> >> From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On >> Behalf Of Ben Standefer >> Sent: Friday, January 30, 2009 5:54 AM >> To: memcached@googlegroups.com >> Subject: UNSUBSCRIBE >> >> >> >> UNSUBSCRIBE > > > > -- > Nick Verbeck - NerdyNick > > NerdyNick.com > SkeletalDesign.com > VivaLaOpenSource.com > Coloco.ubuntu-rocks.org >
RE: UNSUBSCRIBE
Hi Nick, I am still receiving the emails inspite of my unsubscribing using the link given below. It has been a couple of weeks now. Any reason why? thanks, Saurabh From: memcached@googlegroups.com [memcac...@googlegroups.com] On Behalf Of NICK VERBECK [nerdyn...@gmail.com] Sent: Friday, January 30, 2009 5:02 AM To: memcached@googlegroups.com Subject: Re: UNSUBSCRIBE Unsubscribe here: http://groups.google.com/group/memcached/subscribe On Thu, Jan 29, 2009 at 9:52 PM, Gaurav Arora wrote: > I have been wondering how to do the same too … > > > > -- > > Regards, > > Gaurav Arora > > > > From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On > Behalf Of Ben Standefer > Sent: Friday, January 30, 2009 5:54 AM > To: memcached@googlegroups.com > Subject: UNSUBSCRIBE > > > > UNSUBSCRIBE -- Nick Verbeck - NerdyNick NerdyNick.com SkeletalDesign.com VivaLaOpenSource.com Coloco.ubuntu-rocks.org
RE: UNSUBSCRIBE
I'm sorry. Please forgive me. I forgot that I wasn't l33t enough to join a group that talks about a second level caching solution. Let me take a guess, you're American right? Heh. No wonder. -- Regards, Gaurav Arora From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On Behalf Of David Rolston Sent: Friday, January 30, 2009 10:50 AM To: memcached@googlegroups.com Subject: Re: UNSUBSCRIBE Why do people who are too stupid/lazy to read the simplest directions join groups like this. On Thu, Jan 29, 2009 at 9:02 PM, NICK VERBECK wrote: Unsubscribe here: http://groups.google.com/group/memcached/subscribe On Thu, Jan 29, 2009 at 9:52 PM, Gaurav Arora wrote: > I have been wondering how to do the same too ... > > > > -- > > Regards, > > Gaurav Arora > > > > From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On > Behalf Of Ben Standefer > Sent: Friday, January 30, 2009 5:54 AM > To: memcached@googlegroups.com > Subject: UNSUBSCRIBE > > > > UNSUBSCRIBE -- Nick Verbeck - NerdyNick NerdyNick.com SkeletalDesign.com VivaLaOpenSource.com Coloco.ubuntu-rocks.org
Re: UNSUBSCRIBE
EAT SANDWICH On Thu, Jan 29, 2009 at 9:19 PM, David Rolston wrote: > Why do people who are too stupid/lazy to read the simplest directions join > groups like this. > > > On Thu, Jan 29, 2009 at 9:02 PM, NICK VERBECK wrote: > >> >> Unsubscribe here: >> >> http://groups.google.com/group/memcached/subscribe >> >> >> On Thu, Jan 29, 2009 at 9:52 PM, Gaurav Arora wrote: >> > I have been wondering how to do the same too … >> > >> > >> > >> > -- >> > >> > Regards, >> > >> > Gaurav Arora >> > >> > >> > >> > From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On >> > Behalf Of Ben Standefer >> > Sent: Friday, January 30, 2009 5:54 AM >> > To: memcached@googlegroups.com >> > Subject: UNSUBSCRIBE >> > >> > >> > >> > UNSUBSCRIBE >> >> >> >> -- >> Nick Verbeck - NerdyNick >> >> NerdyNick.com >> SkeletalDesign.com >> VivaLaOpenSource.com >> Coloco.ubuntu-rocks.org >> > >
Re: UNSUBSCRIBE
Why do people who are too stupid/lazy to read the simplest directions join groups like this. On Thu, Jan 29, 2009 at 9:02 PM, NICK VERBECK wrote: > > Unsubscribe here: > > http://groups.google.com/group/memcached/subscribe > > > On Thu, Jan 29, 2009 at 9:52 PM, Gaurav Arora wrote: > > I have been wondering how to do the same too … > > > > > > > > -- > > > > Regards, > > > > Gaurav Arora > > > > > > > > From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On > > Behalf Of Ben Standefer > > Sent: Friday, January 30, 2009 5:54 AM > > To: memcached@googlegroups.com > > Subject: UNSUBSCRIBE > > > > > > > > UNSUBSCRIBE > > > > -- > Nick Verbeck - NerdyNick > > NerdyNick.com > SkeletalDesign.com > VivaLaOpenSource.com > Coloco.ubuntu-rocks.org >
Re: UNSUBSCRIBE
Unsubscribe here: http://groups.google.com/group/memcached/subscribe On Thu, Jan 29, 2009 at 9:52 PM, Gaurav Arora wrote: > I have been wondering how to do the same too … > > > > -- > > Regards, > > Gaurav Arora > > > > From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On > Behalf Of Ben Standefer > Sent: Friday, January 30, 2009 5:54 AM > To: memcached@googlegroups.com > Subject: UNSUBSCRIBE > > > > UNSUBSCRIBE -- Nick Verbeck - NerdyNick NerdyNick.com SkeletalDesign.com VivaLaOpenSource.com Coloco.ubuntu-rocks.org
RE: UNSUBSCRIBE
I have been wondering how to do the same too ... -- Regards, Gaurav Arora From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On Behalf Of Ben Standefer Sent: Friday, January 30, 2009 5:54 AM To: memcached@googlegroups.com Subject: UNSUBSCRIBE UNSUBSCRIBE
UNSUBSCRIBE
UNSUBSCRIBE
Re: stats subcommands in memcached...
>>> My next question is stats cachedump. Are people using that feature?? >>> Personally I would like to kill that as a stats subcommand, and try to >>> think >>> of a better way we may help developers to try to debug their application. >>> >> >> stats cachedump can be very helpful. Here's how we use it (albeit rarely): >> >> We're taking a production machine down for other reasons. There's some >> question about our cache utilization. We run stats cachedump, parse >> the keys (which are all nicely prefixed), and get a nice picture of >> which portions of our cached data live in which slabs, how numerous >> they are, how much size they take up, etc. That sort of data -- a high >> level snapshot of the steady state of a production system -- can be >> very valuable, and cachedump makes it reasonably easy to grab, without >> writing any new code. In fact, if anything, I'd like to keep the >> command but remove the buffer limit... >> > > I would prefer if we wrote this as a new and separate command and not as a > subcommand to stat... Sounds reasonable to me -- as long as there's some way to get at this data, it doesn't much matter how (to me, anyway). In fact, explicit support for this would be much better, since one would not then have to iterate over all the slabs. The key thing, to my mind, is to be able to get a dump of every item in the cache (or at the least a representative sample). It doesn't have to be performant in the slightest. Here's how I would rank the per-item attributes: Crucial: * key * value size Nice to have: * storage details as relevant (e.g. for the slab allocator, which slab it was in) * value * expiry * flags as set by the client? Best, -josh
Re: Killed by SIGPIPE using Memcached::libmemcached
On Jan 29, 2009, at 7:50 PM, Mikael Johansson wrote: Hi, send() allows you to specify MSG_NOSIGNAL in the flags parameter which will suppress the SIGPIPE signal. The library can detect this error when send() returns -1 and errno is set to EPIPE, and flag the server as down. We use this in pecl/memcache and it seems to work fine. What do you do on platforms that doesn't support MSG_NOSIGNAL? If the user of libmemcached doesn't have support for MSG_NOSIGNAL on his platform he must handle the signal, and I don't like the situation where the default behavior libmemcached would cause a program abort on machine A while work perfectly on machine B if a client node goes down... Just my 0.5 NOK. Cheers, Trond
Re: Killed by SIGPIPE using Memcached::libmemcached
On Jan 29, 2009, at 6:11 PM, Bill Moseley wrote: Excuse my poor IPC skills, but could the SIGPIPE handler be localized just to the library's socket calls and then restored? I guess there's risk that something else might interrupt before restoring the handler. We could do so, but then we would have to set a new signal handler before each IO operation and restore it after each IO operation. That would generate two extra system calls pr IO operation. I'm happy to handle the SIGPIPE in my application, but I assume the library checks for errors on the socket calls so catching SIGPIPE would seem to fit into that same category of error checking. But, perhaps not. We could, but as stated above it would generate a lot of extra overhead. The more I think of it I believe that leaving this to the user is the best option (and the docs should tell the developer this!) Cheers, Trond
Re: New PHP extension for Memcached
There are a couple of in-house ones I know of as well :) On Jan 29, 2009, at 11:57 AM, pcdinh wrote: Andrei Zmievski, one of key men behind Unicode support in PHP6 has released a new PHP extension for interfacing with memcached via libmemcached library Check it out at http://pecl.php.net/package/memcached To my best knowledge, there are 3 PHP extensions that are based on libmemcached so far -- ___ Brian "Krow" Aker, brian at tangent.org Seattle, Washington http://krow.net/ <-- Me http://tangent.org/<-- Software ___ You can't grep a dead tree.
New PHP extension for Memcached
Andrei Zmievski, one of key men behind Unicode support in PHP6 has released a new PHP extension for interfacing with memcached via libmemcached library Check it out at http://pecl.php.net/package/memcached To my best knowledge, there are 3 PHP extensions that are based on libmemcached so far
Re: Memcache with UNIX socket.
On Wed, Jan 28, 2009 at 7:06 AM, Stephen Johnston wrote: > I've seen this sentiment expressed a few times and while I agree with it for > pure speed, there are some things to consider. One reason I can think of to > use Memcache in this scenario is that almost all of the "in-process" caches > for php are not optimized for FastCGI. Eaccelerator, XCache and APC all are > in-process only for the FastCGI parent. Seriously? Someone who uses PHP should try to fix that. There are multiple in-process caches for Perl that don't have this problem and are faster than memcached for local use. - Perrin
Re: Memcache with UNIX socket.
On Wed, Jan 28, 2009 at 10:36 AM, Henrik Schröder wrote: > I should also add that although in-process caches are the fastest, memcached > is still much, much faster than your average database. It's been a little while, but when I compared connections to a local MySQL (using Unix sockets) vs. a local memcached for a simple primary key lookup, MySQL was faster. This is probably no longer true now that the memcached clients are a lot faster, but it does illustrate the cost of the TCP connection. - Perrin
Re: Memcache with UNIX socket.
On Thu, Jan 29, 2009 at 4:33 AM, Swen Thuemmler wrote: > I see a valid reason using memcached (not distributed) on the same > machine: memcached is rock-solid while your garden-variety webserver > tends to need a restart now and then - loosing all cached content, if > you use an in-process cache. And I think in most cases, the overhead of > a local TPC connections is not _that_ big. It's pretty big. You have to marshall all the data over it. And a good in-process cache, like one based on BerkeleyDB or mmap'ed files, won't lost any data when you restart. - Perrin
Re: Killed by SIGPIPE using Memcached::libmemcached
Hi, send() allows you to specify MSG_NOSIGNAL in the flags parameter which will suppress the SIGPIPE signal. The library can detect this error when send() returns -1 and errno is set to EPIPE, and flag the server as down. We use this in pecl/memcache and it seems to work fine. //Mikael Brian Aker wrote: Hi! On Jan 29, 2009, at 1:48 AM, Trond Norbye wrote: Personally I don't think the library should install a signal handler, because you as a developer might want to trap SIGPIPE We have been asking ourselves this question, aka "Should we optionally add one?". I would love to get some more feedback on this. Cheers, -Brian -- ___ Brian "Krow" Aker, brian at tangent.org Seattle, Washington http://krow.net/ <-- Me http://tangent.org/<-- Software ___ You can't grep a dead tree. signature.asc Description: OpenPGP digital signature
Re: Killed by SIGPIPE using Memcached::libmemcached
Hi! On Jan 29, 2009, at 1:48 AM, Trond Norbye wrote: Personally I don't think the library should install a signal handler, because you as a developer might want to trap SIGPIPE We have been asking ourselves this question, aka "Should we optionally add one?". I would love to get some more feedback on this. Cheers, -Brian -- ___ Brian "Krow" Aker, brian at tangent.org Seattle, Washington http://krow.net/ <-- Me http://tangent.org/<-- Software ___ You can't grep a dead tree.
Re: Killed by SIGPIPE using Memcached::libmemcached
On Thu, Jan 29, 2009 at 10:48:26AM +0100, Trond Norbye wrote: > > Bill Moseley wrote: >> Yes, I can trap the signal, thanks. I guess I'm more wondering what the >> behavior should be. And maybe there's no simple answer. >> >> libmemcached works with sockets so should expect a possible SIGPIPE. >> And the library is somewhat of an abstraction in that from the >> application's point of view it is just storing and fetching and >> doesn't really know how the library does that magic. >> >> I guess my assumption was libmemcached would trap the signal, flag the >> server as down (to stop attempting to use it) and return an error >> stating which server generated the signal. Then someone scrambles to >> replace that downed server. >> >> But, perhaps ignoring the signal is the better approach and use a >> separate process to look for failed memcached servers. >> >> > Personally I don't think the library should install a signal handler, > because you as a developer might want to trap SIGPIPE (maybe not the > ones generated by libmemcached, but others in your program). Excuse my poor IPC skills, but could the SIGPIPE handler be localized just to the library's socket calls and then restored? I guess there's risk that something else might interrupt before restoring the handler. I'm happy to handle the SIGPIPE in my application, but I assume the library checks for errors on the socket calls so catching SIGPIPE would seem to fit into that same category of error checking. But, perhaps not. -- Bill Moseley mose...@hank.org Sent from my iMutt
Re: Memcached 1.3 or above for windows.
> Of course, you first need to installmemcachedas a service via the > command line. Or, as a. said, install it as a service with the correct parameters the first time, with the built-in Windows mechanism for installing services. We do not install this as a service using the "-d install" switch. "-d install" gives no flexibility to install other instances or to change paramaters like port or memory. Instead we use the built in "sc" tool in Windows to manage services. This is the command line command required to install one instance: sc create memcached11211 binPath= "C:\Admin\memcached runtime \memcached.exe -d runservice -p 11211 -m 2048" start= auto DisplayName= "MemCached 11211" Just repeat for multiple instances on the same machine by changing the port number in the servicename (the "memcached11211" part at the start), binPath and DisplayName parameters. - Tormod
Re: stats subcommands in memcached...
Josh Snyder wrote: My next question is stats cachedump. Are people using that feature?? Personally I would like to kill that as a stats subcommand, and try to think of a better way we may help developers to try to debug their application. stats cachedump can be very helpful. Here's how we use it (albeit rarely): We're taking a production machine down for other reasons. There's some question about our cache utilization. We run stats cachedump, parse the keys (which are all nicely prefixed), and get a nice picture of which portions of our cached data live in which slabs, how numerous they are, how much size they take up, etc. That sort of data -- a high level snapshot of the steady state of a production system -- can be very valuable, and cachedump makes it reasonably easy to grab, without writing any new code. In fact, if anything, I'd like to keep the command but remove the buffer limit... I would prefer if we wrote this as a new and separate command and not as a subcommand to stat... Cheers, Trond
Re: Memcache with UNIX socket.
thank you all... now i think that using memcache might not be a big overhead. anyways will try to benchmark the system with IPC (in process cache). then will see what i should implement. Regards, On Thu, Jan 29, 2009 at 3:03 PM, Swen Thuemmler wrote: > > On Wed, Jan 28, 2009 at 11:56:27AM +0100, Henrik Schröder wrote: > > If each webserver is only going to access its own memcached server on the > > same machine, why are you even using it in the first place? Why not > simply > > use an in-process cache in each webserver? That's much, much faster in > your > > case since it has no overhead. > > > > You should only use memcached if you want distributed synchronized > caching, > > in that role it outperforms pretty much anything, but if you don't need > it > > to be synchronized and if you don't need it to be distributed, there are > > other solutions that are better. > > I see a valid reason using memcached (not distributed) on the same > machine: memcached is rock-solid while your garden-variety webserver > tends to need a restart now and then - loosing all cached content, if > you use an in-process cache. And I think in most cases, the overhead of > a local TPC connections is not _that_ big. > > Just my 2 ct > > --Swen > -- "The future belongs to those who believe in the beauty of their dreams" = Abhinav Gupta Software Engineer @99acres.com
Re: Killed by SIGPIPE using Memcached::libmemcached
Bill Moseley wrote: Yes, I can trap the signal, thanks. I guess I'm more wondering what the behavior should be. And maybe there's no simple answer. libmemcached works with sockets so should expect a possible SIGPIPE. And the library is somewhat of an abstraction in that from the application's point of view it is just storing and fetching and doesn't really know how the library does that magic. I guess my assumption was libmemcached would trap the signal, flag the server as down (to stop attempting to use it) and return an error stating which server generated the signal. Then someone scrambles to replace that downed server. But, perhaps ignoring the signal is the better approach and use a separate process to look for failed memcached servers. Personally I don't think the library should install a signal handler, because you as a developer might want to trap SIGPIPE (maybe not the ones generated by libmemcached, but others in your program). We _could_ create a compile-time-switch to enable / disable the installation of a signal handler, but that would be painful for people providing binary versions of libmemcached so I don't think it is a good idea to do so. An alternative could be to use a behavior flag, but I don't see that buying us anything (the user could just call the sigset function instead).. Just my 0.5 NOK Trond
Re: Memcache with UNIX socket.
On Wed, Jan 28, 2009 at 11:56:27AM +0100, Henrik Schröder wrote: > If each webserver is only going to access its own memcached server on the > same machine, why are you even using it in the first place? Why not simply > use an in-process cache in each webserver? That's much, much faster in your > case since it has no overhead. > > You should only use memcached if you want distributed synchronized caching, > in that role it outperforms pretty much anything, but if you don't need it > to be synchronized and if you don't need it to be distributed, there are > other solutions that are better. I see a valid reason using memcached (not distributed) on the same machine: memcached is rock-solid while your garden-variety webserver tends to need a restart now and then - loosing all cached content, if you use an in-process cache. And I think in most cases, the overhead of a local TPC connections is not _that_ big. Just my 2 ct --Swen
