Currently my web application runs on two Cloud-based Windows 2012 R2 Servers - one running Tomcat and one running SQL Server Express. The Windows Servers are 4GB Intel XEON(R) CPU E5-2660 v2 #2.20 Gghz
I am testing my application on PaaS (Platform as a Service) in Azure.
I created a Linux Web App with Tomcat 9.0 to hold the application (P1V2) and an Azure SQL Server to hold the database (S2)
One test I did was to compare the time it takes to produce an Excel report (using Apache POI) on both systems.
On the Cloud system (running SQL Server Express) it took about 10 seconds. On Azure it took about 35 seconds.
Obviously I would like the Azure system to be at least as fast as the one based on SQL Server Express, especially as the cloud system runs SQL Server Express which is capped at 1GB and 1 core.
I have tried the following:
Checked to see if there any spikes in the dashboard chart for the
database. There are no significant ones - DTU's are maximum 25%
I added Query Performance Insight / Recommendations / Automate to automatically
tune the database. This did speed it up somewhat but by no means
enough.
I read Help, My Azure Site Performance Sucks! and Why is running a query on SQL Azure so much slower? and Azure SQL query slow
I checked that the database and application were in the same location. (West Europe)
I imagine that the problem is the database.
As an example, I found a query (using the Query Performance Insight / Long Running Queries) that runs in 2 seconds on Azure and in 0 seconds on SQL Server Express. Note that I am NOT asking how to optimize this query. Rather I am imagining that the fact that this query takes longer on Azure - with the same database schema, the same data and the same indexes - might be a clue as to how to speed up my application as a whole.
SELECT cp.*
,(
SELECT min(market_date)
FROM mydb.rates ms
WHERE ms.curr1 = cp.curr1
AND ms.curr2= cp.curr2
) MIN_MARKETDATE
FROM pairs cp
order by curr1, curr2
The easiest way to do an apples-to-apples comparison is to use the vCore model for your Azure SQL. You say you are using an S2 database which is 50 DTU or half of a core. You would need to scale up to at least an S3 to be the equivalent of a 1 core VM.
That will ensure you are testing with the same general setup and should help you to match performance.
Related
This question was migrated from Stack Overflow because it can be answered on Database Administrators Stack Exchange.
Migrated 12 hours ago.
We are testing one feature in our enterprise application with Azure.
It try to Insert / Update / Delete / Fetch around 110K rows , The Java Web App is deployed in local machine , And we tried Local On Premise SQL Vs Azure Various hardware options , the difference is huge.
Local Machine Hardware : Intel i7 , 14 Core Cpu 32 GB RAM,
Local On Premise SQL Server 2019 also in same hardware.
when we run the feature locally in this hardware the whole operation gets completed in 4 Minutes.
But when run the same feature with Azure SQL Database ( General Purpose vCore 2 Provisioned installation ) its taking around 20 Minutes.
The confusing part here is when we tried to scale up the Azure DB to
vCore - 4 ,
vCore - 6 ,
vCore - 10,
DTU Based Premium Option with 250 DTU's
in all cases the timing almost same , no improvement.
When we check the usage metrics in Azure portal , all metrics showing CPU / IO usage are under 10% for all combinations(vCore 2,4,6,10).
Now the question is what is the standard way to Connect/Configure Azure SQL DB from local machine to gain maximum performance for long data intensive work.
And why the increase in Azure capacity not achieving any performance improvements ?
I have two virtual servers in cloud: DB and Web. There is MS SQL Server Express 2012 instance on Db server. In Database in SQL Server there is the table 'Job' with relatively big records(10Kb per record).
When i run simple query from DB server, it takes less than one second to execute. But when i run it from Web server it takes more than one minute.
SELECT TOP 10000 * FROM Job
And it have direct relationship between retrived records count and time to execute. It takes about seven minutes to retrieve 100000 records from Web server.
In SQL Server Profiles it takes same CPU time to execute query from DB and Web server, but total time different.
The same effect is on any query which returns large amount of bytes.
I have another application servers in this cloud and they have that effect too.
But on development environment and other deploys all is ok. Query executes on Web server slightly slow than on DB Server.
I have checked network speed between Web and DB servers. Its stable and about 1Gb. Turning off Windows Firewall have no effect.
I am using SQL Azure migration wizard for migrating one of my database to a different instance. It literally took more than 12 hours to do BCP out itself. The only change i have doneis to increase the packet size from 4096 to 65535(max). Is that wrong ? And i am doing this from a AWS server which is part of the same subnet where SQL server RDS instance is hosted
Analysis completed at 7/16/2016 1:53:31 AM -- UTC -> 7/16/2016 1:53:31 AM
Any issues discovered will be reported above.
Total processing time: 12 hours, 3 minutes and 14 seconds
There is a blog post from the SQL Server Customer Advisory Team (CAT) that goes into a few details about optimal settings to get data into and out of Azure SQL databases.
Best Practices for loading data to SQL Azure
When loading data to SQL Azure, it is advisable to split your data into multiple concurrent streams to achieve the best performance.
Vary the BCP batch size option to determine the best setting for your network and dataset.
Add non clustered indexes after loading data to SQL Azure.
If, while building large indexes, you see a throttling-related error message, retry using the online option.
SQL Server Enterprise Edition's query optimizer will use indices from a view to increase performance of a query even if the view is not explicitly referenced in the query, if applicable. Question: does Azure Database do the same thing? I know SQL Server Express does not do this, for example. I want to ensure I can still get the performance I need from the query optimizer when doing a sort on a joined table with a few million users (works great on enterprise edition but takes several seconds on express - bottle neck at the sort).
Sometime last year (2012) Microsoft announced that the engine was the same between SQL Server and SQL Azure (now called Windows Azure SQL Database :/). So you will likely get the same behavior. Same performance may be another question. Windows Azure SQL Database is also keeping replicas in place in the event of hardware failure. You get the benefit of the secondary coming online in a fashion that is seamless to you. But, This does have a bit of a performance cost. Also, the SQL running in Windows Azure is running in a shared environment. It is pretty well documented that the performance is not the same as a local dedicated multi-processor machine with fast storage. It is a bit of an unfair comparison multi-user, multi-instance vs. dedicated. For many applications this is fast enough, but not all.
Hi experts I want to know in which scenario I have more Performance(Time to run queries):
If the Backend is MS SQL Server and Fontend MS Access
If both Backend and Frontend are Same on MS Access
If both Backend and Frontend are same and on MS Sql server
and why?
As long as the instance of MS SQL is running on a database server rather than a stand-alone PC then this should provide superior query performance against Access. Access is limited by the processing power the the machine from which you are accessing it as due to been a file based system it has no processing power of it's own and everything must be run locally.
In terms of the front-end, it really depends on what other tasks you are looking to carry out, using an Access front-end over and MS SQL back-end is perfectly acceptable as you can still load any query processing on the server side and thus not decrease performance.
SQL Server is always faster than Access (has a better query optimizer too, amongst all other things), so just axe the Access completely...