Optimize ASP.NET Membership Stored Procedures for greater speed and scalability

Here is a good article from Omar AL Zabir. If you are also using ASP.NET Membership/Role/Profile providers, or at least checking if you can use it as i do, it has pretty good and practical results. Thanks Omar for this informative and beneficial article.

Last year at Pageflakes, when we were getting millions of hits per day, we were having query timeout due to lock timeout and Transaction Deadlock errors. These locks were produced from aspnet_Users and aspnet_Membership tables. Since both of these tables are very high read (almost every request causes a read on these tables) and high write (every anonymous visit creates a row on aspnet_Users), there were just way too many locks created on these tables per second. SQL Counters showed thousands of locks per second being created. Moreover, we had queries that would select thousands of rows from these tables frequently and thus produced more locks for longer period, forcing other queries to timeout and thus throw errors on the website.

If you have read my last blog post, you know why such locks happen. Basically every table when it grows up to hold millions of records and becomes popular goes through this trouble. It’s just a part of scalability problem that is common to database. But we rarely take prevention about it in our early design.

Continue reading

Advertisements

Is the Relational Database Doomed?

I read an interesting article in ReadWriteWeb.com which i follow daily. It is a good idea to take a look at the article. I paste first part of the article here.

Recently, a lot of new non-relational databases have cropped up both inside and outside the cloud. One key message this sends is, “if you want vast, on-demand scalability, you need a non-relational database”.

If that is true, then is this a sign that the once mighty relational database finally has a chink in its armor? Is this a sign that relational databases have had their day and will decline over time? In this post, we’ll look at the current trend of moving away from relational databases in certain situations and what this means for the future of the relational database.
Continue reading

Ten of the Biggest Mistakes Developers Make With Databases

Although fashions come and go in software development, some things stay remarkably constant. One of these is the use of databases. You may be wonderfully up-to-date with an AJAX Web interface or the latest whizbang Windows user interface, but under the covers, you’re probably still pumping data in and out of a database, just as we all did a decade or more ago. That makes it all the more surprising that developers are still making the same database mistakes that date back to those good old days of Windows 95 and before. Perhaps it’s just that most of us learn to use databases on the side, rather than really studying them. In any case, here are my nominations for the biggestmistakes that I see over and over again.

Choosing the Wrong Database
Not all databases are created equal — which means before you do anything with a database, you have to pick the appropriate database. Time and again I’ve seen Access databases groaning to bear the load of huge data sets that would have been child’s play for SQL Server, or harried users trying to pay for and set up SQL Server to hold a few hundred rows of data. Broadly speaking, there are three tiers of databases in the market these days: desktop and embedded databases suitable for smaller tasks, “Express” versions of the major players that are good up to a few gigabytes of data, and the truly enterprise databases like SQL Server, Oracle, and DB2 that can handle just about anything you can throw at them. Before you do anything else, you need to make some realistic estimates about the amount of data that you’ll be storing and pick the appropriate product to do the storage. Continue reading