Hot answers tagged

117

In the case of a CPU cache, it is faster because it's on the same die as the processor. In other words, the requested data doesn't have to be bussed over to the processor; it's already there. In the case of the cache on a hard drive, it's faster because it's in solid state memory, and not still on the rotating platters. In the case of the cache on a web ...


75

You implemented a cache (I assume) because the system wasn't performing well enough. That is something that is relevant for the user. Here are things that QA can check: That the system, after the cache was introduced, is still correct. This means they should attempt to trick the cache into providing stale data, which is something QA can verify, and make ...


37

One question is whether the cache itself is really a requirement that should be tested by QA. Caching improves performance, so they could test the difference in performance to ensure it meets some requirement. But good idea to have some testing around caching, whoever is responsible for it. We used performance counters. If your cache system takes advantage ...


33

It is faster because both it is closer and because it is SRAM not DRAM. SRAM is and can be considerably faster than DRAM the values are kept statically (the S in SRAM) so they don't have to be refreshed which takes away cycles. DRAM is dynamic, like tiny rechargeable batteries, you have to regularly recharge the ones so they don't drain away and become ...


31

This is probably too broad for a definitive answer. Personally, I feel that a data access layer is the better place for caching, simply because it is supposed to be very simple - records go in and out and that's it. A business layer implements many additional rules of higher complexity, so it's better if it doesn't also have to manage per-object ...


26

Data access and persistence/storage layers are irresistibly natural places for caching. They're doing the I/Os, making them handy, easy place to insert caching. I daresay that almost every DAL or persistence layer will, as it matures, be given a caching function--if it isn't designed that way from the very start. The problem is intent. DAL and persistence ...


23

Then what? Since nobody said it: Toolbox. That is if you want global variables. Singleton abuse can be avoided by looking at the problem from a different angle. Suppose an application needs only one instance of a class and the application configures that class at startup: Why should the class itself be responsible for being a singleton? It seems quite ...


23

If this class really was as trivial as it appears to be, then there would be no need to worry about violating the SRP. So what if a 3-line function has 2 lines doing one thing, and another 1 line doing another thing? Yes, this trivial function violates the SRP, and so what? Who cares? The violation of the SRP starts becoming a problem when things get ...


22

One thing that should be mentioned explicitly is the impact of the speed of light. In this video Grace Hopper shows a piece of wire about a foot long, which is how far an electrical signal can travel in one nanosecond*. If a CPU is operating at 3GHz, then that implies a distance of 4" per clock cycle. This is a hard physical limit on memory access speeds. ...


19

If you want true Unit Tests, then you have to mock the cache: write a mock object that implements the same interface as the cache, but instead of being a cache, it keeps track of the calls it receives, and always returns what the real cache should be returning according to the test case. Of course the cache itself also needs unit testing then, for which you ...


18

Caching on the DAL is straightforward and simple Your DAL is the central data access layer, which means that any and all data access can be controlled through the classes there. As both reading and persisting happens on those layers it is equally easy to clear or update cache entries as changes happen. Caching in the business is flexible Caching on the ...


17

First if you are concerned about recent (last 5-10 years, since Nahalem?) Intel x86 architecture, then you're a little off in your description of the caches. Each core has their own 128K L1 cache split (64K data / 64K code). Above that, each core has its own L2 cache which basically acts as a buffer between the L1 and L3 cache. Each socket has its own L3 ...


14

You need a cache busting solution. The role of cache busting is: Rename resources to a unique name depending on their content. Update all references to those resources. In a Grunt-based project it's common to use grunt-rev to ensure that all files that need to be refreshed are given unique names, based on their content. If you ensure that your JSON files ...


13

Just like using a single database for multiple services, the approach you describe causes a strong coupling between the services. For example, you can not change the data model of one service without having to accordingly change the model in others. This means that both development and deployment are coupled and your microservices in reality become a ...


12

Is unanswerable, except to say it depends. There are a lot of factors which will determine which approach is going to be the best in your case, e.g.: Is it normal for created objects to be retrieved shortly after they are created? What's the ratio of updates to accesses? Re. deciding you need a cache: If you're optimising without data then yes, it's ...


11

The Single Responsibility Principle is your best friend here. First of all, move AllFromCache() into a repository class and call it GetAll(). That it retrieves from the cache is an implementation detail of the repository and shouldn't be known by the calling code. This makes testing your filtering class nice and easy. It no longer cares where you're ...


11

Having more variables than registers isn't necessarily a problem. If a variable's value isn't used after a certain point in the function, the compiler can use that register for another variable. Even when there's more variables in use at a certain point than there are registers, the compiler will probably do a better job of figuring out the order in which ...


9

First you last question: Why Redis/memcached? No, they're not (usually) faster than simple in-process dictionaries. The advantage comes when you have several worker processes, or even many app-layer machines. In that case, instead of each process having its own small cache, they all share a single big (distributed) cache. With bigger caches, you get ...


9

You need caching when you have a problem that can be solved by caching. That problem may be too much processor usage on the DB; if it is then MySQL caching is going to help you a lot -- but maybe not enough, it depends what else is going on. Or it could be that your network connection from the application instances to the DB are getting overloaded. In that ...


9

A cache line is the smallest unit that you can touch physical memory with. Meaning when you read/write 1 byte, a full cache line containing it is read into the cpu cache and written back. Note that even instructions that bypass the cache to write (ephemeral streaming instructions) write in cache line sizes. Depending on the CPU, cache line sizes are ...


9

I've been trying to address a similar issue. My users need to be authenticated for every request they make. I've been focusing on getting the users authenticated at least once by the backend app (validation of the JWT token), but after that, I decided I shouldn't need the backend anymore. I chose to avoid requiring any Nginx plugin that is not included by ...


9

As always, one must differentiate: what information is to be stored in the cache? I always go with these simple rules: Information every webserver instance can calculate for itself should go into an in-RAM cache as these need to be accessible ASAP on request but have no need to be shared (never change or do not contain information relevant to other servers)...


8

It seems what you need is a wrapper for all the parameters that define a page (say, pageNumber, pageSize, sortType, totalCount, etc.) and use this DataRequest object as the key for your caching mechanism. From this point you have a number of options to handle the cache: Implement some sort of timeout mechanism to refresh the cache (based on how often the ...


8

RAID arrays use a battery backed cache, so they can process data faster than they can write it. Without the battery, they couldn't do caching without risk of data loss during a power failure. That's the only instance I can think of where you'd need a cache that is specifically battery backed. If it was backing volatile memory, it wouldn't matter. I suppose ...


8

My suggestion is that instead of worrying about whether to use an external or internal cache, your first concern should be that your booking-service does not care whether or not your are using an external service. That is to say, your booking-service should be caching against an interface with the concrete implementation injected in; it would not know or ...


7

Whether or not the data will evict the pointer from cache depends on how how much memory you actually touch, how memory addresses are mapped to cache lines, and on the replacement policy. The most common replacement policy is Least Recently Used (sometimes just approximating the least used) where the new data will replace the data which was used the least ...


7

PSR-6 recommendation regarding Caching Interface expresses a view I personally prefer: While caching is often an important part of application performance, it should never be a critical part of application functionality. So, I'm in favor of considering it as an optional dependency.


7

You are correctly pointing out a race condition. Cache-aside, as described here and here, is an imperfect abstraction that is not appropriate for all data storage use cases. Consistency. Implementing the Cache-Aside pattern does not guarantee consistency between the data store and the cache. An item in the data store may be changed at any time by an ...


6

Please read ServiceStack's wiki page on Caching. What memory gets used is entirely determined by the Caching provider used, e.g. if you use a distributed cache like Redis or Memcached the memory of the process of that daemon/service will grow to retain the cached data. If you use ServiceStack's MemoryCachedClient (the Default) then caches are just kept in ...


6

I believe your class is doing one thing; it's a data cache with a timeout. LoadFluffies seems like a useless abstraction unless you call it from multiple places. I think it would be better to take the two lines from LoadFluffies and put them in the NeedsReload conditional in GetFluffies. This would make the implementation of GetFluffies a lot more obvious ...


Only top voted, non community-wiki answers of a minimum length are eligible