Basically, yes: we are currently simply inside the memory limit of the servers. We haven't intentionally gone for "huge memory", but they do have an amount appropriate to their role. We only solve things that are actually problems, but we have plenty of options. To explain our setup - we currently have only 4 physical redis servers for the production ...
We don't accept bug reports that pertain to our walls, unless you happen to be in one of our offices and actually see a bug on a wall. At that point, you're welcome to ask if said bug belongs to anyone (we all love pets) and if not, help it find a new lease on life outside.
Are the pages build completely from redis cached data or does it need to make some db calls?
Sometimes we serve pages from cache, sometimes we do not see: Does Stack Exchange use caching and if so, how?
How many (approximate) database calls are to be made to build a complete page?
select avg(SqlCount + 0.0) from LogsLastTwoDays
where ResponseCode = 200 ...
We made a slight tweak to the Cache-Control header for logged in users; it looks like we didn't include the max-age in this (although to be honest, what you describe is pretty much what I would expect most browser behaviour to be anyway). I will be deploying a new build including the max-age shortly.
The actual order of users is cached, but the reputation displayed under their name is not. If Jon stays ahead of Silva, then the system will eventually update the list to reorder them. The list usually updates fairly quickly, but you can browse through the list and find quite a few places where there are users "out of order." In fact, this has already ...
Firstly, it should be noted that unplanned failures (with that level of nodes) are exceptionally rare. The only one I can think of involves a certain UPS incident. We don't use "sentinel" - the likelihood and availablity (human and system) is such that in the event of catastrophic failure we can reasonably make the "call" ourselves at the time. And basically,...
I reported this issue around 4 years ago (see this meta post), and while some bugs related to this were fixed, the flag counter at the top still counts different things than the per-mod flag counters. This is certainly confusing, but I'm not entirely sure if it is by design or not.
There are two big categories that are counted in the top counter that the ...
This was indeed a bug in the query for reputation break-down, those quick accepts/unaccepts didn't have the corresponding deleted accept being fed into the cancelling algorithm...this has been fixed and you will no longer see the errant -15 that was cropping up like the case in question.
The posts edited statistic does not count edits that only edit tags. Since many of your edits are tag-only edits, as the screenshot shows, the count won't go up by much. In fact, you can confirm that only the last edit of those 20 was an edit that edited more than just the tags.
Also, edits to tag wikis and excerpts do actually count, towards both the ...
Additional to Sam's excellent stats - on the subject of redis-cache - it should be noted that we (generally, not always) use redis as our 2nd-level cache; our first point of call is usually more local (using redis pub/sub to handle notification of cache invalidation / update).
When we discussed it, we didn't have any fundamental objection to adding this ...
It's unfortunate that the documentation for Redis is misleading - and recent mention of upcoming clustering support also contributes to this misunderstanding. Redis fully supports "clustering" the way that many people are thinking, which relates to high availability and fault tolerance. You can have multiple Redis instances running, one is the master, and ...
Thanks for catching this, but for the moment this is working as intended. The ads are still running off of the old 2014 meta posts for two reasons:
The new posts only went up a couple days ago and we normally wait a bit to have them pick up speed.
We should be switching over to the new ads sometime next week.
Probably caching, same as last year. The leaderboard has to account for changes from across the network and from all users; it's not practical for that to be up-to-the-second accurate. Think about other site-wide items that are cached, like review counts. This is similar.
This isn't a browser refresh issue; it is by design. Reputation lost on deleted posts is not restored immediately; there is a random/arbitrary delay built in (this is to prevent someone deleting their post from trying to sniff out who down-voted them). You just happened to refresh and eventually see the point restored.
Yes they're cached separately since they have different rebuild triggers. There's no need to regenerate the same HTML over and over again - so we cache the actual HTML output...this makes eliminating the same from both lists or syncing counts extremely non-trivial. I wouldn't expect this to get a fix in the near future, just not a high priority.
Take a look at this image:
This is the "sprites" for the page. The vote being selected or not is rendered only by the offset into this image via CSS.
You can see more about sprites and CSS with a web search, but the key point is this, you won't see the up vote being "downloaded" ...
It looks your computer still has the old version of the flair image cached. It shows the diamond on his flair image fine for me, and has shown it fine since I first checked the about page shortly after the announcement of the new moderators.
I think that they chose Redis, because Redis can do a lot more things than Memcached.
Take a look at this reply: https://stackoverflow.com/a/11257333
Even if Memcached is a bit faster, Redis remains a good choice in regard of:
Persistence of data: you do not need to warm your cache
Storing data: more manipulations, requesting, and atomic levels of storage
What is caching?
Caching is the storing of dynamic data in static form for reasonable periods of time. This reduces the number of queries required to display a page. The Stack Exchange engine caches heavily in places, to minimize cross-site queries. It uses Redis to help facilitate this. There is more on how exactly SO caches here.
Where is caching ...
As Nick says, this is indeed caching.
However, if you want to force a rebuild of the Linked Questions list, here are the steps to trigger it:
Copy the URL of the question having an out-of-synch linked question.
Go to that linked question.
On the linked question, post a new comment with the URL you copied in step 1.
Delete the comment.
Based on ...
like there are for reputation
Reputation score is updated live because it's essential part of Stack Exchange, seen and "used" by each and every user. That's why it's always visible, anywhere.
But keeping it live isn't simple or cheap task, it required development time and consume resources.
Tag score on the other hand is something important, but only for ...
I suppose this is done by the server-side caching of SO. The server-side caching is a technology approach to keep a cached version of pages that are not frequently updated, but take server resources to load, or do not have significant changes coming too often. This can be applied to frequently visited pages too, if they do not change as frequently as they ...
This is probably what happened:
You downvoted an answer
The answer got deleted (by the owner / a moderator)
1 reputation points got deducted from your reputation
The situation persisted until few refresh of my browser window and after that I found the original reputation point has been restored.
This delay could be due to several reasons. It could be ...