Webserver1: http://paste2.org/p/715491
Webserver2: http://paste2.org/p/715492
Situation:
1. User logs in.
2. User clicks somewhere (still logged in)
3. User clicks on another placed and gets redirected to the home page
(appears logged out for this page)
4. Refreshes and able to access the page
From the looks of it, you're not evicting anything. Which means memcached
isn't forgetting about anything you're telling it. For some other reason
your sessions are not being found.
From your description of the problem (sometimes logged in, sometimes not),
along with the high miss rate on
Given the behavior and the high miss rate, I really have to think that
something doesn't match between your two servers. Either the server configs
are different or they're trying to get different keys-- there's no reason,
otherwise, that data would appear to be there for one of them but not for
Well, before I come consulting you guys, I have asked the same
question at Stackoverflow and someone pointed it out that both servers
need to have the same memcached pool IP order, so we fixed that. Our
pecl/memcache version is 3.0.1, it's not too old? I haven't checked
the error logs yet so I
Here is our current setup:
webserver1 (also runs session memcache server)
webserver2 (also runs session memcache server)
database (specialized memcache storage for data caching)
We are not really a high loaded site, at peak time only about 1500
users online together. Network is not really
Ok, that seems correct for me. Your described issue still sounds for
me like a connection problem.
On which interface is your memcached bound (memcached.conf?)? Does a
telnet 172.23.111.11 11211
work from every webserver instance? I could imagine following
scenario:
User1 opens a session on
On Mar 11, 9:01 pm, Les Mikesell lesmikes...@gmail.com wrote:
On 3/11/2010 1:01 PM, Martin Grotzke wrote:
Hi,
I'm trying to follow this thread on my mobile, i hope i didn't miss
anything. But AFAICS it was not yet explained, when memcached might
drop cached data as long as there's
On 3/12/2010 11:21 AM, martin.grotzke wrote:
Hi,
I'm trying to follow this thread on my mobile, i hope i didn't miss
anything. But AFAICS it was not yet explained, when memcached might
drop cached data as long as there's enough memory and expiration is
not reached. Or is this not
I just started a new thread How to get more predictable caching
behavior - how to store sessions in memcached to discuss my more
general question on how to achieve more predictability/reliability (I
might have hijacked this thread a little bit, sorry for this).
Cheers,
Martin
On Mar 12, 6:43
Here is our current setup:
webserver1 (also runs session memcache server)
webserver2 (also runs session memcache server)
database (specialized memcache storage for data caching)
We are not really a high loaded site, at peak time only about 1500
users online together. Network is not really
I'm retrieving statistics via Memcache::extendedStats function, here
are the basics:
Session Server 1
Version 1.2.2
Uptime 398,954 sec
Cache Hits 2,065,061
Cache Misses987,726 (47.83%)
Current Items 381,928
Data Read 4,318,055.02 KB
Data Written2,011,004.09 KB
Current
Can you telnet to the instances, type stats, stats items, and stats
slabs, then copy/paste all that into pastebin?
echo stats | nc host 11211 stats.txt works too
You version is very old... It's missing many statistical counters that
could help us diagnose a problem. The extendedstats isn't
We used memcache as a session storage server because we needed to
balance load across servers and share session data. Persistent file
storage is not usable, and since memcache session storage is easy to
configure in PHP, so we have decided to use it.
Before this, memcache maximum storage was set
On Thu, Mar 11, 2010 at 6:03 AM, TheOnly92 05049...@gmail.com wrote:
We used memcache as a session storage server because we needed to
balance load across servers and share session data. Persistent file
storage is not usable, and since memcache session storage is easy to
configure in PHP, so
TheOnly92 schrieb:
We used memcache as a session storage server because we needed to
balance load across servers and share session data. Persistent file
storage is not usable, and since memcache session storage is easy to
configure in PHP, so we have decided to use it.
Before this, memcache
Hi,
I'm trying to follow this thread on my mobile, i hope i didn't miss
anything. But AFAICS it was not yet explained, when memcached might
drop cached data as long as there's enough memory and expiration is
not reached. Or is this not deterministic at all? Perhaps you can
point me to resources
Are you using php pecl memcached, together with a persistent
connection?
Jared
On Mar 9, 12:45 pm, TheOnly92 05049...@gmail.com wrote:
We have been having problems with the memcache server storing sessions
data, the cache miss was about 20%, therefore we added in another pool
of memcache
On 3/11/2010 1:01 PM, Martin Grotzke wrote:
Hi,
I'm trying to follow this thread on my mobile, i hope i didn't miss
anything. But AFAICS it was not yet explained, when memcached might
drop cached data as long as there's enough memory and expiration is
not reached. Or is this not deterministic
And I'm not sure what happens if the keys
have hash collisions.
Like many key-value stores, last write wins.
- Marc
On Thu, Mar 11, 2010 at 4:03 AM, TheOnly92 05049...@gmail.com wrote:
We used memcache as a session storage server because we needed to
balance load across servers and share session data. Persistent file
storage is not usable, and since memcache session storage is easy to
configure in PHP, so
TheOnly92 schrieb:
We used memcache as a session storage server because we needed to
balance load across servers and share session data. Persistent file
storage is not usable, and since memcache session storage is easy to
configure in PHP, so we have decided to use it.
Before this, memcache
On 11 Mrz., 10:03, TheOnly92 05049...@gmail.com wrote:
We used memcache as a session storage server because we needed to
balance load across servers and share session data. Persistent file
storage is not usable, and since memcache session storage is easy to
configure in PHP, so we have
TheOnly92 schrieb:
We used memcache as a session storage server because we needed to
balance load across servers and share session data. Persistent file
storage is not usable, and since memcache session storage is easy to
configure in PHP, so we have decided to use it.
Before this, memcache
Hi,
I wonder in which case sessions (or cached data more generally) could
be lost before the expiration is reached if there's enough memory left
in memcached. Is this possible, and under which circumstances?
If this should not happen in the normal case (no crash etc) I'd
calculate the required
Explain how using memcached opens one self to a DOS attack?
Brian
On Wed, Mar 10, 2010 at 9:15 AM, Carlos Alvarez cbalva...@gmail.com wrote:
On Wed, Mar 10, 2010 at 6:48 AM, Martin Grotzke
martin.grot...@googlemail.com wrote:
Is there anything wrong with this? What would have to be
chances are, the same DOS attack would kill your datastore as well...
i you want speed and persistence, i'd recommend checking out products
like tokyotyrant; it even speaks memcached. we use it to cache user
data and it works incredibly well...
On Wednesday, March 10, 2010, Carlos Alvarez
On Wed, Mar 10, 2010 at 1:28 PM, Brian Hawkins brianh...@gmail.com wrote:
Explain how using memcached opens one self to a DOS attack?
Using memcached to store session data just relying in a previous
calculation of how many memory you will need (all premises) exposes
you to DOS because of the
On Wed, Mar 10, 2010 at 1:52 PM, Carlos Alvarez cbalva...@gmail.com wrote:
Also, I find a lot more easier (and cheaper) to have a
4TB persistent store than a set of memcached.
Sorry. I should have written: than a set of memcached totalizing
0.5TB of memory.
Carlos.
On 3/10/2010 10:52 AM, Carlos Alvarez wrote:
On Wed, Mar 10, 2010 at 1:28 PM, Brian Hawkinsbrianh...@gmail.com wrote:
Explain how using memcached opens one self to a DOS attack?
Using memcached to store session data just relying in a previous
calculation of how many memory you will need (all
On Wed, Mar 10, 2010 at 2:41 PM, Les Mikesell lesmikes...@gmail.com wrote:
But you'll find it very expensive to scale up the number of servers
accessing that persistent store and the speed it can operate if you don't
use something like memcache in front of it.
Of course. If It was understood
the memcached to expell valid data. If your application relies on data
to be present on the memcached to work properly, you have a problem.
Now you have two problems.
--
Marc Bollinger
mbollin...@gmail.com
Agreed.
As I said before, we use a multi-layer approach to solve a similar problem.
We use a database as our primary store for user data and it's cached in
TokyoTyrant and memcached. The majority of our page views are read-only and
therefore don't need to hit the database. We pull that data
I agree memcache isn't expected - and designed - to persistently keep your
data, hence unsuitable for critical session data storage which sweetly
introduces an idea for our *beloved* memcache developers: would it not be
nice to have an option (just an option) to cache data with no possibility
My hunch is that the memcache devs have probably
considered this idea but never went ahead with
it. I would be interested to know why?
I'm not one of the devs, but I can guess why they wouldn't want to do this.
It's pretty simple: it's not just expiration and expulsion that can cause a
On 3/10/2010 5:14 PM, moses wejuli wrote:
Yes, good point as far as service interruption is concerned but I don't
see how this affects performance, especially if the programmer carefully
uses this feature for tiny amounts of data per user I just think,
given how far memcache has
it's not so much a *theoretically reliable storage mechanism* but only
storing data for as long as the programmer chooses or in this case, for only
as long as the user is logged on (data is expelled when the user chooses to
log out or is forcibly logged out for one reason or another).
data
On 3/10/2010 5:46 PM, moses wejuli wrote:
it's not so much a /theoretically reliable storage mechanism/ but only
storing data for as long as the programmer chooses or in this case, for
only as long as the user is logged on (data is expelled when the user
chooses to log out or is forcibly logged
We have been having problems with the memcache server storing sessions
data, the cache miss was about 20%, therefore we added in another pool
of memcache servers, but now the cache miss rate is up to 40%. We
adjusted the order of the memcache server pool, so that every web
server shares the same
On Tue, Mar 9, 2010 at 9:45 AM, TheOnly92 05049...@gmail.com wrote:
We have been having problems with the memcache server storing sessions
data, the cache miss was about 20%, therefore we added in another pool
of memcache servers, but now the cache miss rate is up to 40%. We
adjusted the order
I know nothing about your app, but if you increased the total size of the
pool and nothing else in the equation (number of users, number of page
views, number of sessions, size of session data, etc.) has increased, the
miss rate should have gone down.
2 things:
- as the earlier responder pointed
Interesting and a little off topic, but if you say memcached is not a good
place to put session data then what would you suggest? I've read that
memcached is a good solution for storing sessions for multiple web servers.
Brian
On Tue, Mar 9, 2010 at 1:27 PM, Nicholas Tang
On Wed, Mar 10, 2010 at 12:16 AM, Brian Hawkins brianh...@gmail.com wrote:
Interesting and a little off topic, but if you say memcached is not a good
place to put session data then what would you suggest? I've read that
memcached is a good solution for storing sessions for multiple web
It is a fine place to store transient sessions (incoming link,
navigation information, your stuff) as they can be lost. It is a bad
place to store shopping cart sessions or anything that changes the
user's experience because that would really piss off your users/shoppers.
We use memcached for
43 matches
Mail list logo
