 |
|
|
| 80,000 hits w/ a SQL Server backend? Is it clustered? We have SQL Server vs. MySQL debates at the office all the time. MySQL has better load times in certain situations and is supposed to scale better. It also has a very reduced language set & forces you to make multiple connections and write more code, so I think the trade off is probably negligible. |
|
|
|
SQL Sever backend indeed... And you know the way I do my code, every single quesry is done with a stored procedure, just trying to get the most performance out of the thing as possible. I even make sure I don't name my stored procedures with SP_ because that even slows the server a bit. And thats not 80,000 hits, thats 60,000 - 80,000 unique users, and around 1,000,000 + page views per day. However, keep in mind, that isn't all on the pages that we are talking about. In a few weeks we will start to see how it goes when we begin hitting the DB on every page load. right now it is only on a handful of public pages, but those pages still get pretty good traffic rates.
The DB Server is not a clustered server yet, but will be hopefully pretty soon. And the thing is a beast with 8 CPUs and as many Gigs of RAM, so it would take a lot to bring it down. |
|
[reply]
|
05/27/04 11:05 AM EST
posted by Doug2 web |
|
| On a related note.. I would like to ask HOW THE HELL TO I GET RID OF THE VIEWSTATE?! I set EnableViewState="false" yet it's still there. I suppose I should blog this. |
|
|
|
| Um, why get rid of it? |
|
[reply]
|
05/27/04 01:02 PM EST
posted by Doug2 web |
|
| Because I have a search page.. and I want it to be a GET form so that the resulting page URL can be copied and pasted to other people and they get the same search results.. however, if I do that now it gets the VIEWSTATE in the querystring which can't be pasted to someone else without an error. |
|
[reply]
|
05/28/04 06:10 AM EST
posted by nate web |
|
| Well, you could always generate the url on the search results page for people to c&p. |
|
|
|
Jerry, only other thing RE: SQL Server vs MySQL. As I understand it, MySQL will outperform SQL Server any day of the week when you look at Java. SQL Server has severe limitations when using JDBC. SQL Server is rarely compared to MySQL when using some other language, such as ASP or especially rarely ASP.NET. Also, when people and groups typically test these databases against each other, they will do something that "makes sense" in testing. I say "makes sense" because it really doesn't to me, because it is a whole package deal not just a DBMS. Anyhow, the thing that "makes sense" is that they try to take out any variables and makes it just DB vs DB. In most cases that means using the same app and driver between both connections. This is a very obvious disadvantage with SQL Server using .NET simply because that means the use of the OLEDB drivers. If you would instead use OLEDB for MySQL and the SQL Server specific SQLClient for SQL Server connections, from what I have read you will see a much different picture. This is where SQL Server gets its playing field leveled with the other DBMSs when using .NET. In some other applications and languages, perhaps SQL Server is slower or less efficient than MySQL, but its basic usability typically makes up for it in my eyes, however, the time and effort that MS has invested in SQL Server's use with .NET as the clear favorite in terms of data access is too often unnoticed due to the people who run these comparisons attempting to perform a "scientific" benchmarking experiment where science is really not need.
I want to see which database works best with .NET with an optimal configuration, not which database works best with .NET when there is a level middleware playing field. SQL Server will typically lose that battle because MS isn't investing time in OLEDB connectivity issues and bottlenecks due to the SQLClient option.
|
|
|
|
To test the speed issue, I ran a SELECT joining a few simple tables using System.Data.SqlClient's DataAdapter (5-10 columns per table, ints & varchars) and CoreLab's MySql Direct .NET's MySql driver.
After 10,000 iterations of each, MySql averaged about .17 seconds per query, Sql Server averaged .34 seconds per query. This was hardly scientific, but it coincides with my theory that MySql is faster when it comes to large, simple data gathering.
Beyond the very simple case, Sql Server has clear advantages in other simple & common scenarios. A Sql Server store procedure allows you to embed business logic at the SQL level, which is often more efficient, like so:
.NET Code
Call stored procedure
SQL Server Code
DECLARE @MyVar int
SELECT @MyVar = COUNT(*) FROM Table1
IF @MyVar = 0
-- some SQL
ELSE
-- some other SQL
In MySql, however, I would have to make TWO database calls and push this logic to my application, like so:
.NET Code
- Call SQL command 1
- Parse Query 1 value, call conditional 2nd Query based on result.
MySql Code
Query 1
DECLARE @MyVar int
SELECT @MyVar = COUNT(*) FROM Table1
Query 2
Various queries...
So in this very common scenario, MySql is clearly inefficient, even though each query may execute more quickly. MySql 5.0 is due to be released soon and they've promised stored procedures, IF/ELSE logic and views.
I've also heard that SQL Server gets really crappy beyond 1 million records, though I've never tested that claim. I do know that MySql can handle 10s of millions of rows as long as you configure the #$$& out of it. |
|
Note: Only registered ShinyDonkey.com users
can post images. Only administrators can delete images.
New messages disabled indefinitely due to SPAM.
|
|
|