I need to do some performance testing for an ASP.NET MVC application and specifically want to measure how many database queries each HTTP request results in. The data access layer is using LINQ-to-SQL.
I'd like to be able to automate the tests so am looking for a good way to be able to do a before and after count of the number of SQL queries. The possibilities I can think of are:
A performance monitor counter for the ASP.NET process,
A system table in the MSSQL database that can be queried before and after each page request,
A property somewhere in the System.Data.SQLClient namespace that tracks the number of queries executed by the process.
Has anyone done this before and can perhaps point my down the right path?
The best approach I've been able to come up with so far is to use SQL Server Profiler to profile the db connections while the test app is running and get it to save the results to a database table (File->Properties->General). My test app can then query that table to see what and how many TSQL statements were executed.
Related
on upload.aspx page i have
conn1.ConnectionString = "Data Source=.\ip-of-remote-database-server;AttachDbFilename=signup.mdf;Integrated Security=True;User Instance=True";
and all the queries are also on same page ,only database on another machine..
so is this the correct way of implementing ?? or i have to create all queries on another machine and call them by application??
Any given query query might originate from the client code (such as ASP.NET), or it might be stored a-priori in the DBMS itself as a VIEW or a stored procedure (or even a trigger).
But no matter where it originated from, the query is always executed by the DBMS server. This way, the DBMS can guarantee the integrity of data and "defend" itself from the bugs in the client code.
The logical separation of client and server is why this model is called client/server, but that doesn't mean they must be separate physical machines - you'll decide that based on expected workload1 and usage patterns2.
1 Distributing the processing to multiple machines might increase performance.
2 E.g. you might need several "fat" clients around the LAN (communicating with the same database server) to reach all your users. This is less relevant for Web where there are additional layers of indirection between users and the database.
It depends on your infrastructure. If you have got Sql Server locally you can use it. I assume that it is a school project so it does not matter. In real life it usually a good idea to separate web server and database server
I have an SQL Server(SQL Azure) table that is being queried at a high rate, but gets updated only few times a month.
I wonder what options do I have that can cache the result set on the application side so that it will not have to hit SQL Server all the time.
One option is to just [OutputCache] the action methods which return the views. You may even be able to get away with SQL Dependency caching, though not sure if this works with Azure.
Another option is to try implementing a second-level cache for EF.
Another option is to have an entirely different read model. This way, you wouldn't query against the table, but something else that is closer to IIS and/or faster than SQL Azure (like NoSQL or JSON from Azure cache).
Just about everything I've seen relating to ASP.Net's Login control treats it like a black box. I'm interested in seeing the SQL commands issued against ASPNETDB and watching the dataflow.
For example, the Login control uses ASPNETDB and stored procedure dbo.aspnet_Membership_FindUsersByName. I'm not clear on how to call the procedure because it expects #PageIndex and #PageSize parameters (#ApplicationName and #UserNameToMatch make sense to me). I would like to read about the procedure or trace it.
Would anyone know of good reading on the topic, or suggest a path to explore the control?
What you are looking for is called a SQL Server Trace. The Graphical User Interface for SQL Traces is SQL Server Profiler. This only ships with certain versions of SQL Server (for instance, if you have SQL Server Express Edition then you will not have SQL Server Profiler, but you will still be able to utilize the Trace stored procedures and database objects).
Using Profiler (or the Trace db objects), you'll be able to filter out certain events and data depending on what you are specifically looking to capture. This will give you all the information you'll need to find out the data being transmitted to and from the server -> client application (or in this case, the ASP.NET application).
The events and data that a Trace puts forth can be extremely daunting, especially if you are new to this (which it sounds like you are) and there are a lot of hits to the database. Learn about the Profiler Templates you can utilize, and the individual Events you can analyze.
If you have access to SQL Server, then fire up the profiler and you can see in real-time the sql statements executed against the db.
Just for good measure a brief step by step guide for starting up profiler.
Starting up SQL profiler
If your using SQL express you may not have profiler, however here's an open source alternative (note. I've never used it)
free profiler
If you set it up to use SQL Server (using aspnet_regsql.exe), you can see the stored procedures it uses.
I am building an ASP.NET web application that will use SQL Server for data storage. I am inheriting an existing structure and I am not able to modify it very much. The people who use this application are individual companies who have paid to use the application. Each company has about 5 or 10 people who will use the application. There are about 1000 companies. The way that the system is currently structured, every company has their own unique database in the SQL Server instance. The structure of each database is the same. I don't think that this is a good database design but there is nothing I can do about it. There are other applications that hit this database and it would be quite an undertaking to rewrite the DB interfaces for all of those apps.
So my question is how to design the architecture for the new web app. There are times of the month where the site will get a lot of traffic. My feeling is that the site will not perform well at these times because I am guessing that when we have 500 people from different companies accessing the site simultaneously that they will each have their own unique database connection because they are accessing different SQL Server databases with different connection strings. SQL Server will not use any connection pooling. My impression is that this is bad.
What happens if they were to double their number of customers? How many unique database connections can SQL Server handle? Is this a situation where I should tell the client that they must redesign this if they want to remain scalable?
Thanks,
Corey
You don't have to create separate connections for every DB
I have an app that uses multiple DBs on the same server. I prefix each query with a "USE dbName; "
I've even run queries on two separate DB's in the same call.
As for calling stored procs, it's a slightly different process. Since you can't do
Use myDB; spBlahBLah
Instead you have to explicity change the DB in the connection object. In .Net it looks something like this:
myConnection.ChangeDatabase("otherDBName");
then call your stored procedure.
Hopefully, you have a single database for common items. Here, I hope you have a Clients table with IsEnabled, Logo, PersonToCallWhenTheyDontPayBills, etc. Add a column for Database (i.e. catalog) and while you're at it, Server. You web application will point to the common database when starting up and build the list of database connetions per client. Programmatically build your database connection strings with the Server and Database columns in the table.
UPDATE:
After my discussion with #Neil, I want to point out that my method assumes a singleton database connection. If you don't do this then it would be silly to follow my advice.
Scaling is a complex issue. However why are you not scaling the web aspect as well? Then the connection pooling is limited to the web application.
edit:
I'm talking about the general case here. I know tha pooling occurs at many levels, not just the IDbConnection (http://stackoverflow.com/questions/3526617/are-ado-net-2-0-connection-pools-pre-application-domain-or-per-process). I was wondering whether the questioner had considered scaling at the we application level.
I was wondering what is the easiest way to see total number of database queries from my ASP.Net (.NET 2.0) application.
My application heavily use sql 2005 database because all data are dynamic and everything goes through one connection string in web.config. Connection pooling is enabled there.
So, I am wondering how many select statements are executed for particular page I load in my browser.
I don't care if I can see that information from .net side or from db side as long as I can see only connections to MY database. Not all connections to that db server because I use shared db server and there is a lot of other databases.
The best way to do this is to set up a profiler on your database and then make a single request to your ASP.NET application. The profiler will aggregate any data you wish and you will be able to use that data to determine what queries were sent to SQL Server from your application.
The SQL Server Profiler will list all actions performed on your DB. If you use a different db login name for your project (probably a really good idea if you are not) you can filter so it only shows actions from your login (see Events Selection, Column Filters then Login Name).
Use SQL Profiler. You can configure it to filter by the database you want and to just show select statements.
If you have some sort of database layer in your code, you could modify it to write out a log message every time you run a select statement. Then just load the page once and count the number of log statements. This may or may not work, depending on how your code is structured, but it's an option.
Edit: I misread the question. I thought you had multiple clients connecting to the same database, not the same database server. In that case, a profiler probably is the best choice.
Do you have access to SQL Server Profiler? You can set up traces to monitor this sort of thing by loading a page and looking at the effects in the profiler.
JUst be aware that Profiler can affect performance, so it is best to do this on dev.