MSDN Magazine - April 2008 - (Page 70)

which will attempt to populate the cache item tice is to scale up—one gigantic box, perhaps with their own queries to the database. To solve two in a cluster configuration (although only this problem, you can add a thread lock to stop one is actually running the database at any the other page executions from requesting the given time). Eventually, though, in every large data from the database. scale Web application, a single database cannot But run through the scenario again: the first handle the load. You have to scale out. It’s pos request comes in, discovers the cache item is sible; you just need to apply the same strategies not populated, applies a lock to the code, and applied to the Web application itself. The first runs the query to populate the cache object. step is always specialization—breaking the da The second request arrives a second later while tabase into logical partitions. Those partitions the first is still running, finds the cache object could be datacentric, perhaps by region. So you is not populated but the lock is in place, so it would have multiple databases, each contain blocks. As does the next 28 requests. Then the ing a portion of the whole database. One server first one finishes its processing, removes the would have East Coast data, for example, while lock, and continues. What happens to the other the other has West Coast data. 29 requests? They’re no longer blocked, so they Really largescale Web applications, however, continue executing as well. But they’ve already partition their databases into readers and writ run through the check to see if the cache ob ers (see Figure 6). The reader databases are read ject is populated (and it wasn’t at the time). So only; they receive their data from the writer they’ll try and grab a lock, and one will succeed databases via replication. All data queries go to and run the query again. the reader databases, which are optimized for See the problem? Other requests that arrive reading data as fast as possible. Reader databases after the first request completed populating are by their nature very distributable. the cache object will run normally, but those All data write requests are sent to the writer requests that come in while the query is run databases, which are partitioned and tuned to ning are in a tough spot. You have to write code write efficiently. Replication moves the new data to deal with this. If a request hits a lock, when from the writer to the reader databases. the lock is lifted it should check again to see The consequence of creating such special if the cache object is populated, as shown in ized databases is latency: a write is now going Figure 5. Likely, the cache object will be popu to take time to be distributed to the reader da lated now; that was why the lock was taken in tabases. But if you can deal with the latency, Figure 6 Distributed Database the first place. Although it’s possible that it isn’t, Architecture the scaling potential is huge. because in the meantime some other chunk of code has expired the cache object again. The Endless Scaling Effort Writing caching code that works well is hard work, but the re As long as your application continues to grow, your efforts to turns can be tremendous. Caching does add complexity, however, scale it are going to continue to grow as well. The ASP.NET tech so use it judiciously. Make sure you’re really going to benefit from niques that work effectively for 10,000 simultaneous users aren’t the complexity. Always test your caching code for these complex as effective with 100,000 users, and the rules change again with 1 scenarios. What happens on multiple simultaneous requests? What million users. Of course, performance can completely depend on happens if expirations come quickly? You need to know the answers your application; we’ve seen applications that had scaling challenges to these questions. You don’t want your caching code to make your with less than a thousand users! scaling problems worse. The key to effective scaling is to measure before you cut: Use test ing to be sure you’re spending effort where it’s needed. Test your Scaling Databases work to be sure that you’ve actually made an improvement, not just The normal approach for scaling Web sites is to scale out, rather a change. Even at the end of a development cycle focused on op than up. This is largely due to ASP.NET thread and memory limita timizing for scalability, you should know where your slowest bits tions combined with the shortterm nature of Web requests. are. Hopefully, however, they’re fast enough for the users today, so When it comes to scaling databases, however, the normal prac that you can work on what your users will need tomorrow. ■ 70 msdnmagazine ASP.NET Performance

Table of Contents Feed for the Digital Edition of MSDN Magazine - April 2008

MSDN Magazine - April 2008 Contents Toolbox CLR Inside Out Basic Instincts Cutting Edge Foundations Test Run Service Station Windows with C++ Going Places { End Bracket }

MSDN Magazine - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.