Tag Info

Hot answers tagged

528

It's important to distinguish here between single instances and the Singleton design pattern. Single instances are simply a reality. Most apps are only designed to work with one configuration at a time, one UI at a time, one file system at a time, and so on. If there's a lot of state or data to be maintained, then certainly you would want to have just one ...


90

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 ...


67

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 ...


34

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 ...


31

In the case you give, it sounds like the use of a Singleton is not the problem, but the symptom of a problem - a larger, architectural problem. Why are the screens querying the cache object for data? Caching should be transparent to the client. There should be an appropriate abstraction for providing the data, and the implementation of that abstraction ...


28

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 ...


24

I wrote a whole chapter on just this question. Mostly in the context of games, but most of it should apply outside of games. tl;dr: The Gang of Four Singleton pattern does two things: give you convenience access to an object from anywhere, and ensure that only one instance of it can be created. 99% of the time, all you care about is the first half of that, ...


20

Recording views is very simple, simply add a row to a table that represent the "view" action. This is fast because no locking is required in the database, you're just adding a row onto the end of a heap. Aggregating that into the total number of views requires something like doing SELECT COUNT(*) FROM ... which means you have to lock the table while the ...


20

In addition to Martijn's comments I'd add: Warm up your JVM. Bytecode starts starts off being interpreted for Hotspot and then gets compiled on the server after 10K observations. Tiered Compilation can be a good stop gap. Classloading is a sequential process that involves IO to disk. Make sure all the classes for your main transaction flows are loaded ...


17

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. ...


16

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 ...


16

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 ...


15

There are a bunch of things to be aware of yes. I'm in Crete at the moment with limited net access so this will be (fairly) short. Also, I'm not a low-latency expert, but several of my colleagues play one in real life :-). You need to appreciate Mechanical Sympathy (a term coined by Martin Thompson). In other words you need to understand what your ...


14

Its not global state per se that is the problem. Really you only need to be worried about global mutable state. Constant state is not affected by side affects and thus is less of a problem. The major concern with singleton is that it adds coupling and thus makes things like testing hard(er). You can reduce the coupling by getting the singleton from another ...


13

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 ...


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 ...


10

Keep your data small if possible Keep things that will be accessed together (or right after another) next to each other in memory Learn about your compiler's optimization parameters Read What every programmer should know about memory for more details than you could ever want


10

The intricacy of this issue has been beyond human comprehension these days. (It has been that way since the last 5 years.) Combine that with short-vector parallelism (SIMD) and you have a sense of hopeless that optimizing code by hand is no longer economically feasible - not that it's not possible, but it would not be cost-effective anymore. The current ...


10

Here is a list of standard options. Optimize the access to the database to only do what you need, efficiently. A good DBA can help here a lot. This is a basic step that most companies do. Cache data away from the database using something like memcached. This is usually done at the application layer, and is highly effective. Virtually every competent ...


10

If you wan to use a LRU eviction cache (Least Recently Used eviction), then probably a good combination of data structures to use is: Circular linked list (as a priority queue) Dictionary This is why: The linked list has a O(1) insertion and removal time List nodes can be reused when the list is full and no extra allocations need to be performed. ...


10

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

I guess the best answer is that it depends. In my experience there are a lot of factors that go into choosing caching algorithms. Factors to consider Read/Write Balance. (What percentage of accesses are reads vs writes) Amount of cache. Type of media behind the cache. (Are they slow SATA drives or fast SSD drives?) Hits vs Misses. (How often are things ...


9

"Are there any reasons not to do this?" Scalability. Sure, when you're using it now, the data is under a few MB. Will that always be the case? I don't think so. Especially if you expect other people to use this system. You're re-inventing the wheel. If the content is stored in files, you should just let Apache (or whatever other web server you're using) ...


9

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 ...


8

Most likely the value has been cached somewhere along the way so you are seeing stale data. Because it is not critical for this data to be accurate the developers have decided to favour performance over getting up to date data. You really wouldn't want to go to the database and do a row count for every hit on the site just to update this figure so they ...


8

Unless I'm misunderstanding the question, I don't think that this is an appropriate scenario for caching. Cached data normally has at least one of the following attributes (usually all of them): Expensive to retrieve or compute; Highly static - may change occasionally but very rarely; Non-critical - OK if the requester sees stale data. It doesn't sound ...


8

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 ...


7

I have experimented with different approaches to object caching, and I see advantages to an approach where collections are cached as references rather than actual objects. An example: User GetUser(int ID); ICollection<User> GetRecentUsers(int amount); ICollection<User> GetActiveUsers(int amount); void Update(User user); In this example, if ...


6

Assuming you know almost nothing about the application you're going to develop, you should know more about it before actually choosing and implementing a cache system. In other words, there are no default implementations: some are good for some purposes, and are totally bad for others. For example, take just two implementations: Least Recently Used and ...


6

90% of the problem is optimizing your database queries and configuring your server correctly. Make sure you have proper indexes, that the queries arent doing row scans, etc. Use whatever profiler tools your database offers. You'd be suprised how much this can affect a server. A lot of companies will rush out and buy a new database server when all they ...



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