Posts tonen met het label Performance Tuning. Alle posts tonen
Posts tonen met het label Performance Tuning. Alle posts tonen

woensdag 19 september 2012

Optimize your SQL statements

It is always good practise to optimize your SQL query statements for a better performance. Just making sure your query does what it needs to, isn't enough. You should consider the performance impact of your code and try to optimize it for the best performance.

Below is a short list of steps to take when optimizing your query statements.
More details on the steps can be found in this blog.

  1. Check if you're missing any required table joins.
    This could result in a Cartesian join.

  2. Check if you're missing any required WHERE clause to prevent retrieving too much data.

  3. Check if statistics are being created & updated automatically.

  4. Check if the statistics are up-to-date.
    The DBCC SHOW_STATISTICS command can be used to view the last updated date-time, total table rows and the number of rows sampled.
    Outdated statistics can be renewed using  the sp_updatestats stored procedure, or By using the FULLSCAN option to update all statistics of a table.

  5. Check for any missing table or Index scans by using the execution plans.
    you can use these DMV's to check for missing indexes: sys.dm_db_missing_index_details, sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_groups.

  6. Check for RID Lookups, also by using the execution plans.
    These cannot always be eliminated, but by making use of covering indexes, RID Lookups can be reduced.

  7. Check for any sort operator, again by using the execution plans.
    There are 3 options:
    • Modify the underlining tables to create a CLUSTERED index on the required sort columns. It could be worth trying out creating the CLUSTERED index on another column which is not the Primary Key.
    • Create an Indexed view on the underlining tables and sort the view by creating a CLUSTERED Index.
    • Create a NON CLUSTERED Index on the specified columns and Include all other columns which will be returned.


  8. Check for excessive index fragmentation.
    The DMV sys.dm_db_index_physical_stats can be used for this matter.

  9. Check table locks.
    To prevent locking problems, follow these guidelines:
    • Keep transactions as short as possible.
    • Review the transaction isolation level, and consider minimizing locking contention, thus increasing concurrency by changing to 'Read Committed using row versioning' or 'Snapshot'.
    • Specify table hints such as READUNCOMMITTED or READPAST on the select statements. Although both of these table hints do increase concurrency, both have disadvantages such as 'dirty reads' when using the READUNCOMMITTED or returning an incomplete data set when using the READPAST and therefore they may not be acceptable to use in all circumstances.


Source: http://www.sqlservercentral.com/articles/Performance+Tuning/70647/

Speeding Up Database Access

I found a complete serie on speeding up acces to your SQL Database.

So far, there are only 4 parts published of an 8 part series of articles on speeding up access to a SQL Server Database.
Here's an overview of the content of all 8 parts (including links of already published parts):

  • Part 1 Pinpointing missing indexes and expensive queries
    • Find expensive queries (with trace log)
    • Locate missing indexes with the query optimizer (or with Tuning Advisor)
    • Find unused indexes
  • Part 2 Pinpointing other bottlenecks
    • Find Locks and Latches (via counters in perfmon)
    • Execution plan reusability (using counters or dynamic management views (DMV))
    • Fragmentation of data and indexes
    • Memory check (using counters to verify if there’s a lack of memory)
    • Disk usage (locate possible disk bottlenecks using counters)
    • CPU (use counters to see if the CPU is stressed)
  • Part 3 Fixing missing indexes
    • Indexes explained (clustered and nonclustered indexes)
    • Index usage (when / when not)
    • Maintaining indexes
  • Part 4 Fixing expensive queries
    • Cache aggregation queries
    • Keep records short
    • Considering Denormalization
    • Be careful with triggers
    • Use table variables for small temporary result sets
    • Use Full Text Search instead of LIKE
    • Replacing cursors with set based code
    • Minimise traffic from SQL Server to Web Server
    • Object Naming
    • Use SET NOCOUNT ON
    • Use FILESTREAM for values over 1MB
    • Avoid functions on columns in WHERE clauses
    • Use UNION ALL instead of UNION
    • Use EXISTS instead of COUNT to find existence of records
    • Combine SELECT and UPDATE
  • Part 5 Fixing locking issues
  • Part 6 Fixing execution plan reuse
  • Part 7 Fixing fragmentation
  • Part 8 Fixing memory, disk and CPU issues

I'll update this post when new parts are published.

dinsdag 17 juli 2012

BizTalk Server Performance

Have you ever wanted to evaluate the performance of your Biztalk installation?
Evaluating your performance could be done by analyzing quite some counters in the performance monitor of Windows. Or maybe by using the Performance Analysis of Logs (PAL) Tool.

However I just found a recently released tool to benchmark your biztalk environments.
The tool is called blogical and can be found on codeplexe here.

How it works:
  1. After the user has started the application and specified the BizTalk Group, the tool analyzes its configuration, finding all the BizTalk servers, Messageboxes etc.
  2. Secondly, the user gets to select one of two scenarios: Messaging or Orchestration. Each scenario has a set of tested environments such as
    • “Single server (2*Quad CPU, 4GB RAM)”
    • “1*BTS (1*Quad CPU. 4GB RAM) + 1*SQL(1*Quad CPU, 8GB RAM)”.
    • “2*BTS (2*Quad CPU. 8GB RAM) + 2*SQL(2*Quad CPU, 16GB RAM)”.
  3. The user selects the environment which most resembles his/her own.
  4. The user then starts the Indigo Service, a console application hosting a service which will be called from the BizTalk Send port.
  5. As the user clicks “Run test”, the tool continues to start ports and orchestrations. It will also start the Perfmon collector sets if the user has chosen to create those.
  6. As the test proceeds the user can monitor the counter values through the gauges (CPU utilization, Received msgs/sec and Processed msgs/sec). The default test duration is 30 minutes, with a warm-up of 2 minutes.
  7. Finally, the user is presented a result, which is either Succeeded or Failed.

For more information:
Benchmark your BizTalk Server (Part 1)

How to install:
Benchmark your BizTalk Server (Part 2)

BBW Drill Down:
Benchmark your BizTalk Server (Part 3)

High Scores:
http://blogical.se/bbw


Another thing I wanted to share with you regarding performance of Biztalk installations is the Microsoft BizTalk Server 2009 Performance Optimization Guide .
This guide provides in-depth information for optimizing the performance of a BizTalk Server solution.

Also check BizTalk Health Check post on Technet Wiki. It's a list of checkpoints that should be covered when performing a health check

woensdag 13 juni 2012

Identify Performance Bottlenecks in BizTalk

I found a series of blogs on how to identify Performance bottlenecks in BizTalk Environments.
Also look at this article on finding and eliminating bottlenecks

Here's an short overview of all the steps, including a link to the more detailed explanation:

Step 1: Monitoring BizTalk Host Instances via Windows Performance Counters


 The first place to measure the BizTalk performance can be done using Performance Counters. These counters let you monitor all components like the message box, orchestrations, adapters, etc… .

Step 2: Analyzing BizTalk Adapters


A deeper look at the adapter performances, again using some performance counters.

Step 3: Analyze Pipelines


It is important to understand the impact of Pipeplines that are used. Because each of the pipelines have a significant impact on the overall BizTalk performance as they perform actions on every single message that gets through BizTalk
One way to analyze what is really going on in pipelines is using an Application Performance Management Solution with Transactional Tracing capabilities, like dynaTrace for example.

Step 4: Analyzing Orchestration


Orchestration can get quite complex sometimes, but how to analyze the performance of these orchestrations?

The actual logic behind the Orchestration Definition is compiled into an assembly, loaded into BizTalk, and gets executed when messages are processed by that Orchestration Definition. A more detailed overview of the execution of such an orchestration can be generated with PurePath for example.

Another way to analyze the orchestration performance can again be done using performance counters.  BizTalk provides a set of counters for the Orchestration Engine as well as for the MessageBox.

Step 5: Analyzing external service calls (SendPorts)


Often BizTalk Orchestration makes a call to an external web service. PurePath can also give you an idea of the time consumed for this external web service call.


FINAL NOTE


As a final note I would like to point out to use the MessageBox Viewer Tool. The tool gives an overview of what might be wrong in your installation.
This tool runs a set of tests and queries against the MessageBox database an creates a nice report. The result can be viewed using the tool or it can generate an HTML report.

dinsdag 12 juni 2012

Best practices on Biztalk Tracking

I announced in a previus post that I joined the blogging team on biztalkadminsblogging.com.
However it took untill today before my first blog post was created.

I gave it a long thought what my first blog post should cover. the result is a post on some best practices for the usage of tracking in BizTalk... hope you like it!

The actual post can be found here http://www.biztalkadminsblogging.com/index.php/item/83-best-practices-for-tracking

maandag 21 mei 2012

Guideline to Solve Performance issues of Biztalk

Typically a performance problem can be narrowed down to one of the following components of a BizTalk Server environment:
·         A receive adapter or the system from which the adapter is receiving documents. For example, if documents are being received by the HTTP adapter at a suboptimal rate then the problem may be with the HTTP receive adapter or with the client that is posting to the HTTP adapter.
·         An orchestration service instance.
·         Performance of the SQL Server that hosts the BizTalk Server databases.
·         A send adapter or the system that the adapter is sending documents to. For example, if documents are being sent by the SQL adapter at a suboptimal rate then the problem may be with the SQL send adapter or with the computer running SQL Server that the SQL adapter is updating.

Use the following guidelines to help identify the components of the BizTalk Server environment that are performing poorly:
·         Capture any warnings or errors generated in the BizTalk Server or SQL Server Event Viewer.
·         Follow the steps in "Identifying Performance Bottlenecks" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154238 to help identify performance bottlenecks.
Once the poorly performing component has been identified, follow the appropriate guidelines to help resolve the issue:
Guidelines for resolving performance problems related to send and receive adapters
·         For information about troubleshooting problems with BizTalk Server adapters, see "Troubleshooting BizTalk Server Adapters" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154240. This section contains general troubleshooting information including information about how to set up logging for certain adapters, and information that can be used diagnose network problems, problems with MSDTC, problems with the registry, problems with the file system, and problems with IIS.
·         For information about troubleshooting problems with MSDTC, certificates, Enterprise Single Sign-On, and SQL Server, see the appropriate section of "Troubleshooting BizTalk Server Dependencies" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154242.
Guidelines for resolving performance problems related to orchestrations
·         For information about modifying the appropriate sections of the BTSNTSvc.exe.config file, see "Orchestration Engine Configuration" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154244.
Guidelines for resolving performance problems related to SQL Server
·         SQL Server Profiler can be used to capture Transact-SQL statements that are sent to SQL Server and the SQL Server result sets from these statements. Since BizTalk Server is tightly integrated with SQL Server, the analysis of a SQL Server Profile trace can be a useful tool for analyzing problems that may occur in BizTalk Server when reading from and writing to SQL Server databases. For information about how to use SQL Server Profiler, see "Using SQL Server Profiler" in SQL Server Books Online at http://go.microsoft.com/fwlink/?linkid=104423.
·         SQL Server Management Studio can be used to execute SQL statements directly against SQL Server databases. This functionality may be useful for querying the BizTalk Server databases or for updating the BizTalk Server databases in certain scenarios. For more information about using SQL Server Management Studio to execute SQL statements, see "Writing, Analyzing, and Editing Scripts with SQL Server Management Studio" in SQL Server Books Online at http://go.microsoft.com/fwlink/?linkid=104425.
·         For more information about resolving performance problem related to the BizTalk Server databases, see "Troubleshooting SQL Server" in BizTalk Server Help at http://go.microsoft.com/fwlink/?LinkId=154250.

vrijdag 10 februari 2012

Top 10 Performance Tips for SQL Server

Found a blog with some tips for SQL Server Performance Tuning.
the 10 tips helps you start on performance tuning in Microsoft SQL Server Tuning.

For the complete explanation, I refer to the original blog
Here's a short overview of the tips:
  1. Stop waiting around
    Check the SQL wait statistics to recognize the bottlenecks

  2. Locate I/O bottlenecks
    Find I/O bottlenecks, as they are one of the key reasons for bad SQL performance

  3. Root out problem queries
    Find the most expensive queries

  4. plan to reuse
    Determine the statements that are not reusing query execution plans

  5. Monitor index usage
    Evaluate the usage of all indexes

  6. seperate data and log files
    Make sure the data and the log files are on separate physical drives

  7. use seperate staging databases
    Use a seperate database in simple recovery model for all initial imports to minimize the transaction logging

  8. Pay attention to log files
    Make sure there is plenty of free space in the log file to avoid the auto-grow operation as much as possible

  9. Minimize tempdb contention
    Optimize your tempdb files

  10. Change the max memory limit
    Make sure you configure the correct max memory setting

Source: Top 10 Performance Tips for SQL Server

donderdag 9 februari 2012

Biztalk Best Practices

I found a neat blog about best practises for orchestrations in BTS.

Another great addition to this blog can be found here. This is a check list to review BizTalk code.

A third great blog has some tips and tricks on how to program BizTalk code.

Links:
BizTalk Server 2010 - Orchestration Best Practices - TechNet Wiki
My BizTalk Code Review Checklist - Richard Seroter's Architecture Musings
8 Tips And Tricks For Better BizTalk Programming - MSDN Magazine

vrijdag 25 november 2011

woensdag 17 augustus 2011

The Mystery of Query Timeouts by Kendra Little - YouTube

"People are complaining about query timeouts. I don't see anything happening in SQL Server, but they always say the database is the problem. How can I tell what's really going on?"

When your users keep hitting timeouts in their application, they naturally think the database is killing off helpless queries. In this webinar Kendra Little will tell you how to triage treacherous timeout situations and collect hard evidence about whether or not the problem is in the database. Do the right detective work and you can turn your frustrated users and irate developers into raving fans.

This session is be 200-level - you should have familiarity with OLTP concepts and understand what DMVs and Profiler are, but you don't have to be an expert with them.