text:
BizTalk Server 2006: Managing a Successful Performance Lab
Doug Girard
August, 2006
Summary: This document illustrates and identifies ways in which to test and evaluate servers before going live in a business setting. Step-by-step testing protocol is emphasized and demonstrated. Checklists and resource lists/links provide additional direction. Multiple scenarios are explored and illustrated.
Part of every application's pre-production testing should include performance and stress testing. You should know the limits of your platform and your applications with certainty prior to ever receiving or sending a live message in production use.
Performance and stress testing can also intersect with capacity planning. You should understand up front what type of hardware you'll require and how much will be critical for your business. Also, if your company has very strict requirements for volume or latency with constraints on hardware, proving that the system can meet the required goals with expected hardware will be key.
This document exists to provide some general guidance around approaching performance labs with BizTalk Server 2006. For specifics, we have made reference to correlated documents that already exist on the web or in the product documentation for additional assistance.
Performance is a topic that needs to be considered from the very beginning of a BizTalk project's life cycle. As our Planning for Sustained Performance: Project Planning Recommendations by Phase documentation article explains, performance needs to be firmly positioned in the Requirements, Design, Implementation, Verification, and Release milestones of your project.
Part of this project plan should budget in the necessary time and resources to conduct a full BizTalk Server performance lab for the solution that will run in production. Before beginning your performance lab engagement, you should have already:
Established performance criteria
Identified performance risks
Estimated sizing
Acquired detailed throughput and latency profiles
Investigated performance risk mitigations
Refined system size estimations
Reached design and code implementation completion
Completed your functional testing, including all smoke testing, sanity checks, regression tests, and multi-machine trials.
Now that you are actually ready to begin the performance lab, developing a well thought-out strategy and a methodology for approaching the engagement will go a long way towards achieving success. A successful performance lab will include the following elements:
Defining the Scope
Constructing a Plan
Technical Preparation for the Lab
Lab Build-out
Lab Execution
Concluding the Lab
Each of these points will be elaborated upon in the following sections. The overall lab process might resemble the following depiction.
Figure 1: Fictional Contoso Performance Lab Process
Define the abstract / executive summary.
What is the background for this lab?
What are the prioritized goals for the lab?
What is the bar of success?
What is an acceptable "call it quits" point?
Create a high-level architectural diagram as part of the lab documentation.
If third-party systems are used, record each respective system design at a high level.
Defining the Purpose
The benefits to conducting a BizTalk Server performance lab should already be obvious to you and your team, but communicating this to the business is often a critical step, justifying the time commitment and the cost. Below are a few examples.
Abstract / Executive Summary:
Contoso's Operations team will be conducting a performance lab on the Order Fulfillment application between January 1 and January 14, 2006. We plan to upgrade the Order Fulfillment application from BizTalk Server 2004 to BizTalk Server 2006. While we are code complete with the migration, it is still yet to be proven that BizTalk Server 2006 can handle the new volume requirements mandated by the business for the next three years of operation. With a target go live date of April 15, 2006 the Operations team will be using this lab opportunity to attempt to meet the current load requirements, the projected load requirements, and later obtain the maximum sustainable throughput (MST) for the environment with different hardware configurations. Specific goals for the lab are outlined in the Goals section to follow within this lab manual.
Purpose Statement:
The purpose of this lab engagement is to prove to the business that BizTalk Server 2006 can comply with our performance guideline requirements for the next three years of operation.
Setting Goals and Success Criteria
Successful performance labs can often go awry in the absence of quantitative, measurable goals. Goals should be used as motivation and these points should be revisited periodically during the lab to monitor progress. Goals should also lead to establishing success criteria, the minimum bar for completing a rewarding engagement. Below is a comprehensive example.
Goals Overview
The primary purpose of the lab is to ensure BizTalk Server 2006 can perform in parity with their current BizTalk Server 2004 environment by being able to process 12M messages within a 12-hour period sustainably. Second to this is proving that BizTalk Server 2006 can perform well against the performance needs expected three years from now, meeting 20M messages within a 12-hour period sustainably. This is independent of the server classes chosen and topology arrived upon. Abbreviated tests will be carefully constructed to simulate this daily performance goal.
After the primary objectives have been proven, regardless of the topology of machines, the lab's focus will shift to trying to optimize the performance of the system with different hardware configurations, obtaining the Maximum Sustainable Throughput (MST) on different hardware configurations. Later, the business will be able to choose their hardware knowing the upper limit of each topology.
Finally, if there is extra time, recovery, administrative, and failover cases will be attempted.
Performance Goals
Process 12M messages within 12 hours at a steady input rate. Any hardware configuration.
Process 20M messages within 12 hours at a steady input rate. Any hardware configuration.
Process 20M messages with load exactly simulating production profile, with peaks and troughs. Any hardware configuration.
Establish MST numbers for different hardware configurations.
Resume 1M failed messages in the DB while under 400 message/sec load and recover to steady state processing with 1 hour.
Drop a BizTalk Server node from the group under 400 message/sec load and observe healthy system BizTalk Server behavior.
Success Criteria
Goals 1, 2, and 4 are required for lab success and the lab will not culminate until completed.
Goals 3, 5, and 6 are optional if time remains, otherwise they will be conducted at a future time before our production window comes around.
Performance Profile Specifics
12M messages/day is the current performance requirement
Per day actually means within a 12-hour trading window
This means 12M inbound, 15M outbound
12M messages/day is the current performance requirement
20M/day (averages to 463 msgs/sec in 12-hour period)
Notes: They expect 25% year–over-year growth in transaction volume, so finding the max sustainable throughput through BizTalk Server is an important lab exercise
20M/day (averages to 463 msgs/sec in 12-hour period)
Currently up to 2500 messages/sec (inbound and outbound)
Currently up to 2500 messages/sec (inbound and outbound)
No different
No different
Hours of Operation
Open 24 hours, need to be able to handle transactions at any hour
Bulk of transactions come in during normal business hours (12-hour period)
Downtime possible on Sunday morning (12 AM to 6 AM)
Open 24 hours, need to be able to handle transactions at any hour
No different
No different
Additional Requirements
They don't have any tight SLAs but need to make sure that the system is "sustainable" which they define as "make sure that all of Monday's data is reconciled by EOD Monday (midnight)"
Should test for error cases where a machine is knocked out
Other Goals
Have fun!
Get a minimum of 8 hours of sleep per night.
Remember, performance criteria should have been arrived at very early in the application life cycle (i.e., the Requirements Phase) and should be easily translated into lab goals.
Performance criteria should always be future-thinking and should account for the year-over-year growth in transaction volume expected by your business.
Documenting the Scenario
Documenting the entire scenario end-to-end brings everyone onto the same page during the lab, identifies the scope of the application(s) to be tested, and creates a paper trail for historical reference. Below are some approaches to properly documenting your scenario from a performance perspective, above and beyond what you might normally have in project specifications.
Basic Questioning
Question | Scenario Profile |
Basic Scenario Definition |
Do you have a purge messaging scenario? |
What transports do you use inbound? |
What transports do you use outbound? |
Do you use DTA tracking? |
Do you use BAM tracking? |
DO you use orchestration? |
Do you use BRE? |
Volume |
How many message per day do you normally receive inbound? |
How many messages per day does this normally result in outbound? |
What is the volume on a slow day? |
What is the volume on a heavy day? |
What is your expected year over year growth in transaction volume? |
What is the maximum peak of messages that you will receive inbound in a given interval? |
Hours of Operation |
Do you need to be able to handle a load 24 hours a day, 7 days a week, 365 days a year? |
Do you have planned downtimes each week? For what duration? |
Message Types |
Do you receive XML messages? |
Do you receive Flat File messages? |
Do you receive other document formats? |
Additional Requirements |
Do you have strict Service Level Agreements (SLAs)? Some examples are:
What are your data maintenance plans, i.e., archiving, purging, disaster recovery? |
Describe in exhaustive detail the hardware and topology used for the lab end-to-end.
Create reference posters and hang these in the room of the lab. Mark these posters with changes made during the week.
Plan to maintain a shared Lab Manual which will contain comprehensive information on the scenario and lab, and will be updated daily with status and progress made.
Construct a conservative day-to-day schedule which builds in buffer.
Create a project plan and keep it updated.
Schedule all lab resources far in advance.
Schedule the necessary personnel to ensure staffing is never a bottleneck, including developers and any Subject Matter Experts (SMEs) who oversee third-party systems that may be involved in the solution.
Outlining Hardware and Topology
Creating an inventory of the hardware available to you and the hardware planned to be a part of the topology is one of the first steps in beginning a lab engagement. Settling on machine and hardware device naming conventions can also go a long way toward creating a smooth lab experience.
Very likely, your hardware topology will change during the course of the lab, so having daily updates posted on the walls or on a projector will avoid confusion due to changes. Keeping track of all of your changes, in both hardware and software, and the justifications for each change, should be recorded methodically in your Lab Manual. A spreadsheet, daily notes, or even diagrams can be used.
Figure 2: A Possible Lab Topology
The above diagram is an oversimplified depiction of an environment's topology. Ideally, you'll also want a very verbose diagram which includes host distributions and service descriptions, machine specifications (name, manufacturer, CPUs, memory, local disks, IP Address, network card/s, operating system), endpoint details, hardware device specifications, switch specifications, SAN specifications, and the like.
Proposing a Lab Timeline
Setting appropriate times to meet throughout the lab, especially with the extended team, is an exercise which should be done up front. Laying out a skeleton of a schedule is also a good idea and can help keep your team on track, but a performance lab will almost never track exactly to schedule. Therefore, be sure you are creating a conservative timeline which builds in buffer and time for unexpectedly arduous troubleshooting. Below is an example. During the lab this project plan should be updated to reflect the latest information and remain fresh.
Meeting Schedule
Activity Schedule
Figure 3 and4: Establishing a Conservative Activity Schedule
It is also very common in performance testing to discover a performance bottleneck in custom code or orchestration that needs redevelopment. And frequently custom testing or measuring tools need to be adjusted after analysis. Factoring in some extra time for redevelopment in the cycle and having developer resources available on hand during the lab is a "must-have".
Establishing a Recording Methodology
With your team, agree upon some standards for recording, data collection, and daily status reporting. Dividing up these responsibilities among team members is often a good idea. Using a common Lab Manual to archive these findings is a must. During the lab, convening at the end of each day to summarize the progress made and agree upon key findings will help drum a consistent rhythm for the lab, and will aid with daily status reporting.
Below is a fictitious sample of a daily status report sent to the extended team.
Key take-aways:
Gigabit network is needed, otherwise network saturation occurs on at least the destination queue machine's NIC.
We believe we should collapse the data layer to two physical machines with three message boxes, one sharing the master message box, but continuing to separate the LUNs on the SAN.
2 receivers do not get pegged at 400 doc/s total but are maxed at 500 docs/s (250/s each). To achieve greater than 400/s we should go to 3 or more receivers.
We haven't yet seen the senders as the bottleneck and would like to reduce the other bottlenecks and see if we can get rates of greater than 65-70 doc/s out of each of them.
Topology Changes:
Went to three message boxes on three different SQL boxes today.
Gigabit switches were installed.
Resolved Issues:
SSPI Context Errors resolved. Removed the machine entries from the Active Directory Domain Controller, removed SQL machines from the domain and re-added them. (May be related to first using a Local System account and then switching it to a Domain Account.)
Two more Intel Xeon 2-ways acquired and built out.
Throttling settings understood a bit better after a call with PSS.
New Issues:
We need more than just 2 receivers. We cannot keep up with the volume of messages coming in, especially when running off of local disks.
There are currently no maintenance plans, and recommendations are needed from the extended Ops team.
May need two more 2-ways prepared.
Test Run | Results |
1 |
Went to three message boxes On 3 SQL boxes 300/s looked perfectly clean, aborted run to bump up load |
2 |
400 documents/second 200/s at each receiver 2 receivers,6 senders,3 SQL CPU Recv – 65,65 Send – 99, 99, spiky 65 Master – 10-15 MB2 – 31 (8 way) MB3 - 53 Rate Recv – 198,198 Send – 65 Spool – 25,000 and 25,000 at end Little back up in MSMQ recvs 20 min run 30 sec for MSMQs to drain 3:15 to complete 16.23% catch up Definite Bottlenecking at NIC on destination MSMQ; need gigabit switches No throttling on recv until end of run, then DB Rate throttling on send H2 of run, memory and unprocessed |
3 |
Et cetera … |
Describe the solutions to be tested on a very granular level, such as at a message-flow level.
Have third-party SMEs meticulously document their system details.
Create message histograms and arrive at a representative data set for lab testing.
Define the discrete use cases to be tested.
Create a detailed performance profile.
Receive solution artifacts from all respective teams prior to the lab start date.
Ensure build and deploy instructions are also available.
Recording the Detailed Solution Design
Defining the BizTalk Server scenarios to be tested and their individual performance profiles in thorough detail is a necessary prerequisite for beginning a performance lab. This will help to scope the lab, allow your team to easily settle on discrete use cases to test, and create the needed data to test with.
Detailed Questioning
Question | Scenario Profile |
Scenario Complexity |
How long do your orchestrations run (secs, mins, days, months)? |
How many subscriptions are there (static and dynamic)? |
How complex are the subscriptions (convoys, number of items)? |
How many orchestrations are initiated per request? |
How many transactions and persistent points are used? |
How many messages are created inside of BizTalk per request? |
Scenario Complexity - Messaging |
How many subscriptions are there? |
What is the complexity of the subscriptions (in-order, convoys)? |
Scenario Complexity - Maps |
How many transformations are called? |
How complex are the maps used? |
Are your maps memory- or processor-heavy? |
Scenario Complexity - Other |
Are your SQL databases dedicated to the BizTalk solution or shared among other solutions? |
Is your data subsystem dedicated to the BizTalk solution or shared among other solutions? |
Are there other, more sophisticated specifics to your solution that are worth mentioning? |
Additional Requirements |
Do you have budget limits, e.g. the cost for hardware and software licenses needed for that hardware cannot exceed $750K? |
Do you have minimum hardware size requirements, e.g. we don't put anything into production that is smaller than an 8-way? |
Do you have maximum hardware size requirements, e.g. we will only use 2-proc blade servers and scale out? |
Do you have restrictions on a maximum number of servers, e.g. our department charges back by our IT department for the number of machines we have in deployment (multiplied 4 fold for the different environments - production, pre-production, integration testing, development)? |
Do you have configuration limitations, e.g. we will not use NLB only Switch Load Balancing or we only use 3rd party clustering tools? |
Do you have environment limitations? Using the same type of hardware that will be used in the production environment is critical to reproducing performance numbers. This includes not only machine type (CPU type, #CPU, memory, etc), but also switches, SANs, # of firewalls. The performance lab may influence some of what hardware should be purchased but there are some parts of the build-out that are not in control of the department/team that is building the project. |
Are there architectural requirements that would affect performance, e.g. Geo-clustering, remote SAN mirroring, etc.? |
Creating a Message Histogram
What is the breakdown of message sizes and types received during the average day? Perhaps 50% are 1KB XML, 25% are 10KB XML, 15% are 100KB XML, and 10% are 10KB FF (which expand to 100KB XML).
Create a histogram of the data to be expected and then arrive at a representative sample of messages which can be used for Load Generation while still closely simulating the production message profile. See the figure below.
Size Bucket | Actual Qty | Percent | Ten Msgs | Rounding | Chosen Size |
< 1 |
1 |
0 |
0 |
0 |
20000 |
66 |
6.6 |
6 |
0 |
0 |
0 |
0 |
92 |
0.3 |
0 |
0 |
560 |
1.8 |
0.1 |
0 |
2899 |
9.6 |
1 |
1 |
2986 |
9.9 |
1 |
1 |
1671 |
5.5 |
0.5 |
1 |
1317 |
4.3 |
0.4 |
1 |
470 |
1.5 |
0 |
0 |
4 |
0 |
0 |
0 |
All XML |
Average 15.2KB |
Defining Discrete Use Cases
Conceivably, your BizTalk Server implementation only supports one primary use case, perhaps the sending of all messages through a set of specific maps and onto one destination endpoint. In other cases, your solutions may be more complex. If they are more intricate in nature, identifying all of the different use cases will assist with test case creation and help to predict the effects of inbound load on the system.
The example below shows a simple content-based routing solution in which all messages reach the same destination queue (100%), but a small portion (roughly 10%) are also mapped and routed to a second back-end system based on properties of their messages. This means that a daily inbound volume of 1M messages will actually result in 1.1M messages outbound, and hence an additional processing burden on the send side.
Message Type | Message Percentage | Destination Queue | Processing Needs |
All Product Orders |
100% |
Passthru MSMQ |
Orders Over $1000 |
9.8% |
Mapping SOAP |
In still more advanced cases, multiple orchestration flows, or even multiple applications, may be involved simultaneously. Documenting these use cases and their load proportions helps to define all of the needed test cases and properly set message volumes.
Figure 5: Use Case A: Receives 25% of the System's Daily Volume
Creating a Detailed Performance Profile
It is very important to create a performance profile for your average day and for your busiest day. Analyze the message flow during a typical 24-hour period. What is the volume of messages per 30-second slices of time throughout the day? The result should be something like the chart below.
Figure 6: Actual Message Volume Profile
Next, create another chart with discrete "buckets" of message sizes (in significant ranges) as different series, such as depicted below.
Figure 7: Message Volume by Message Size
Now that you have these profiles established and well understood, it is much easier to create performance and stress tests. You can translate these profiles into actual test cases which can be run with LoadGen or another stress tool. Examples of some of these performance patterns that you'll want to turn into test cases are described below.
Steady Flow
A flat and steady rate of data, probably set at a rate equal to your average messages processed within a given processing period, makes for a very common and elementary test case.
Figure 8: Steady Flow Volume
Weekends and Lulls
Testing for all of your load patterns, even expectedly low volumes, is important. Systems can behave unexpectedly under low load and could potentially violate service level agreements unless carefully tested for.
Figure 9: Low Volume Pattern
Ensure your application will still meet expected SLAs and performance goals, even under uncharacteristically low volume.
Simulated Testing
Arriving at a pattern more representative of your actual live data profile is no easy task and requires careful analysis of your actual performance profile. How many messages arrive and at what rates? Does this amount differ during the day? Do you get single or double camelback-shaped humps or does the profile remain steady all day long? When do you expect peaks and troughs, and what rates are these peak numbers at? Do you get volume surges only at certain hours? What is the distribution of message sizes? Does this distribution change throughout the day? Et cetera.
You may be able to simulate this load pattern with load generators such as LoadGen. If you currently have the messages arriving into another system, you may also be able to replay an actual day's captured load or route/duplicate the day's normal messages over to the testing environment. In the end, you should succeed in producing a repeatable load profile which can actually simulate your production load.
Figure 10: Typical Volume Profile
You should also consider different times of the year. Would you expect your volumes to rise during holidays or drop during vacation times? If so, be sure to create test cases to handle these changes in volume.
Figure 11: Holiday Volume Profile
Recovery Processing
Another test case often overlooked is simulating a period of downtime. Downtime may be a regular occurrence within your infrastructure and testing for recovery processing with queued-up messages will be necessary.
Figure 12: Recovery Profile
Edge Cases
There may be other infrequently occurring edge cases that would still warrant performance testing. Be mindful of application upgrades, resuming and terminating instances, and any other operational tasks that might be part of long-term ownership of the infrastructure and would have to run while processing load. Make certain these scenarios are considered for inclusion in the capacity testing.
In general, a careful and comprehensive examination of your load profiles and scenarios throughout the day, the week, and the year, and testing for these cases during the lab will ensure that BizTalk Server can predictably handle all of these patterns.
Assembling Solution Artifacts
Finally, making sure all solution artifacts are code complete and thoroughly tested before the lab begins is a must. You do not want to be wasting cycles during the lab debugging code for functional issues. Having these artifacts available before the lab will also allow you to test them briefly during the lab build-out stage to iron out any deployment problems and ensure the actual lab hits the ground running, which segues to our next section.
Obtain all build-lab infrastructure at least a week in advance of the lab start date.
Configure third-party software systems.
Configure the BizTalk Server environment.
Validate implementation.
Write automated load tests.
Configure performance monitoring.
Establish and document the solution's performance baseline.
Build-out Checklists
There are times during the lab when you should try to establish near-robotic practices to reduce errors, and the lab build-out is one of them. Checklists should be used whenever possible—for machine creation and configuration, overall environment construction, and application deployments, just as a few examples. The following sections elaborate on some of these.
Note To create checklists, use the product documentation and other references (see the "Additional Resources" section) to arrive at comprehensive checklists that are customized for your implementations. Below are some typical types of checklists that should be created and followed before and during the lab. The specifics of these checklists are only to be used as illustrations, and are by no means documentation or intended to be followed as standard, complete, or comprehensive guidance.
Network and Administrative Configuration
Consulting with your network administrators, creation of Active Directory® domain accounts and groups might have a checklist which resembles the following.
Domain Controller Created (Optional)
Domain Accounts Created
DOMAINNAME\Northwind BizTalk Application Users
DOMAINNAME\Northwind BizTalk Isolated Host Users
DOMAINNAME\Northwind BizTalk Server Administrators
DOMAINNAME\Northwind BizTalk Server Operators
DOMAINNAME\Northwind SSO Administrators
DOMAINNAME\Northwind SSO Affiliate Administrators
DOMAINNAME\Northwind Account
Password: ********
Membership in all groups & local admin on all boxes
Password: ********
Administrator (local)
Password: ***********
Password: ***********
Some companies will prefer to create a separate domain for the purposes of the performance lab, eliminating other network contention, but others may not go to these lengths.
In general, permissions issues can often slow down progress in a lab and are fundamentally tangential to the purpose of the exercise. Running with administrative privileges should not be done in production, but might be a reasonable idea for a performance lab.
Also, be sure to schedule time with your lab technicians to assemble the right mix of network hardware, configure switches, subnets, and VLANs, and test for correctness and fitness.
SQL Server Creation
Consulting with your SQL Server™ and SAN administrators, SQL Server and related database setup guidelines might look something like the following.
Install OS
Windows Server 2003 ENT SP1
Pagefile separated
Set the /3GB Switch on the SQL Servers
Install all Prerequisites
Enable DTC
Install SQL Server 2005
Install SQL Server 2005 Service Pack 1
Use SQL Aliasing
Enable AWE - Min 13GB, Max 13GB
Pre-create BizTalk DBs
BizTalkMsgBoxDb [Primary] On the SAN
S: DATA (10GB initial)
T: LOG (10GB initial)
S: DATA (10GB initial)
BizTalkMsgBoxDb [Secondary] On the SAN
S: DATA (10GB initial)
T: LOG (10GB initial)
S: DATA (10GB initial)
BizTalkMsgBoxDb [Secondary] On the SAN
S: DATA (10GB initial)
T: LOG (10GB initial)
S: DATA (10GB initial)
BizTalkMgmtDb (U:)
BizTalkDTADb (U:)
Ensure that SQL Agent Running and Jobs Enabled (after the BizTalk group is created)
The performance of a BizTalk solution is often highly dependent upon the performance of the SQL Server databases hosting the BizTalk Server Message Database, Tracking Database and BAM database. For this reason, it is beneficial to have access to resources that can create a high-performance SQL Server environment. In particular, it is critical to have available resources who can align the SQL Server databases and available SAN storage to ensure that SQL Server is making best use of the storage subsystem.
Note: Similar steps might also be taken for other machines in the topology, such as a dedicated MSMQ box.
Third-party System Build-outs
There may be other third-party systems which need to be built out and configured before the lab can begin. If subject matter experts (SMEs) are required for these systems, be sure they are scheduled during the build-out and lab execution stages. Be sure they thoroughly document their build-out procedures as well.
BizTalk Server Creation
Creation of Enterprise Single Sign-on (SSO), the BizTalk group, and all of the BizTalk Server boxes might follow the guidelines outlined in the following sections.
Enterprise SSO Server--Master Secret Server
This step installs SSO only and NOT the full BizTalk Server environment. This is a special case of the SSO service and can be installed before all other BizTalk servers.
Install OS
Windows Server 2003 ENT SP1
Pagefile partition separated
Install Prerequisites
.NET Framework 2.0
SQL Server 2005 Client Tools
SQL connectivity components and SQL Server Management
Make sure SQL native client tools for TCP/IP is enabled
SQL connectivity components and SQL Server Management
Enable DTC / DTC Testing
Install BizTalk Server 2006 for SSO
Custom Configure BizTalk Server 2006
Configure SSO Service ONLY
BizTalk Group Creation
The first BizTalk Server box in the group to perform installation and then walkthrough configuration will thereby be responsible for initial creation of the BizTalk group.
Install OS
Windows Server 2003 ENT SP1
Pagefile partition separated
Install all Prerequisites
.NET Framework 2.0
SQL Server 2005 Client Tools
SQL connectivity components and SQL Server Management
Make sure SQL native client tools for TCP/IP is enabled
SQL connectivity components and SQL Server Management
Enable DTC / DTC Testing
Install BizTalk Server 2006
Custom Configure BizTalk Server 2006
Create initial group and associated databases
Ensure that pre-created database location is selected for the Master message box (not the default locations)
Create two additional message boxes on the pre-created secondary databases
Install any additional BizTalk adapters
Install any BizTalk Server hotfixes or service packs needed
Additional BizTalk Servers
Now that the BizTalk group has officially been created, other BizTalk servers can simply join the existing group. Below is a sample checklist for installing and joining additional BizTalk Server boxes.
Install OS
Windows Server 2003 ENT SP1
Pagefile partition separated
Install Prerequisites
.NET Framework 2.0
SQL Server 2005 Client Tools
SQL connectivity components and SQL Server Management
Make sure SQL native client tools for TCP/IP is enabled
SQL connectivity components and SQL Server Management
Enable DTC / DTC Testing
Install BizTalk Server 2006
Custom Configure BizTalk Server 2006
Join to existing BizTalk Server group
Install any additional BizTalk adapters
Install any BizTalk Server hotfixes or service packs needed
The first box which configures by joining the group may also choose to export these JOIN settings to an XML file for importing on successive BizTalk Server boxes also joining the group. This may expedite the overall group creation.
Application Installation
Deploying the actual applications can be the most error-prone part of the build-out so be sure to take the appropriate time and diligence in ensuring this is done properly (and is well documented).
Create Hosts
Create Send/Receive Handlers
Create Host Instances
Create Application/s
Application Installation
Deploy BizTalk Binaries to Group
Import Bindings to Group
GAC BizTalk and non-BizTalk binaries on all boxes
Ensure dependency components exist on all boxes
Deploy BizTalk Binaries to Group
Install dependency applications
Configure transports and physical endpoints
Install MSMQ Services
Install MSMQ QFE – KB 908926
MSMQ private queue creation
Create file shares and assign correct permissions
Install MSMQ Services
Startup Services
Perform Basic Smoke Testing
Miscellaneous Configuration
Afterwards, there may be additional BizTalk Server-related configurations required. Below is a sample checklist that might be used by one such company.
Tracking Disabled at the group level
Ensure all machine times are being properly synchronized
DTC Testing
Ensure DTC logging is off
Ensure any custom tracing/logging is disabled unless absolutely needed
LoadGen Installed and Configured
Performance Logs Setup
Performance Monitors Setup
Setup debugging box for stepping through custom code
Check for unnecessary MSMQ tracking or logging
Defragment all local disks
All virus scanning off / uninstalled
Backup the SSO secret
Note The 64-bit machines in the group may have special setup considerations.
Validation and Troubleshooting
Once the entire environment is constructed, you may want to use some of the tools available from the BizTalk Server product team and the community to help validate the success of the build-out, troubleshoot, and document it. A list of helpful resources is available in the following table.
Tool Name | Description |
The BizTalk Server 2006 Best Practices Analyzer examines a BizTalk Server 2006 deployment and generates a list of issues pertaining to best practices standards for BizTalk Server deployments. The Best Practices Analyzer gathers data from different information sources, such as Windows Management Instrumentation (WMI) classes, SQL Server databases, and registry entries. The Best Practices Analyzer uses the data to evaluate the deployment configuration. The Best Practices Analyzer does not modify any system settings, and is not a self-tuning tool. | |
BizTalk Assembly Checker |
This GUI tool is located on the BizTalk Server 2006 CD under \Support\Tools\x86\BTSAssemblyChecker.exe and ensures that your BizTalk assemblies are properly synchronized across all the servers in your group. |
SSO issues are usually related to network settings, MSDTC settings, service settings, account permissions, account group memberships, etc. This tool generates a report about this information. It also dumps out all mappings of all affiliate applications. Optionally it can also output BizTalk Server configuration as data items, and check on a problematic mapping. This tool does not perform some self-diagnosing or provide the option for fixing on the spot. In order to understand the report, one should have some basic understanding of the SSO architecture.
| |
UK SDC BizTalk 2006 Documenter (community) |
Creates compiled help files for a given BizTalk Server 2006 installation. This tool can be run on an ad-hoc basis using the UI or from the command line as a post build/deploy task to create a compiled help file describing a BizTalk Server 2006 installation. It will compile: BizTalk Host configuration, send/receive port configuration, orchestration diagrams, schema and map content, pipeline process flow, adapter configuration, rule engine vocabularies and policies, and more, and publish them as compiled help files. Optionally you can embed custom HTML content and custom descriptions for all BizTalk artifacts to produce a more customized look and feel to the CHM output. |
Final Build-out Steps
Preparation for the lab should also include constructing automated load test scripts, configuring performance monitoring and logging, and establishing a performance baseline on a basic hardware configuration. Techniques for completing each of these steps are described in the "Lab Execution" section to follow.
Conduct testing by running automated tests.
Evaluate and document the test results.
Modify the configuration of BizTalk Server, third-party systems, or solution artifacts to tune for performance based on the results reviewed.
Record all changes made to the environment.
Repeat this cycle until sufficient goals for the lab are met.
Meet at the end of each day to discuss the ground covered, the lessons learned, the issues solved, the new issues opened, and the plan for the next day. Send out status updates to the team nightly by e-mail.
Update the project plan with timeline goals met or failed.
Remember to have fun!
Conducting Testing
If you currently have production-load arriving into another system (perhaps a system you are about to upgrade or replace) you may be able to replay an actual day's captured load or route/duplicate the day's normal messages over to the testing environment.
However, this approach may not allow for the control and repeatability that is often desired in a performance lab. To obtain a more scientific approach, load-generation tools can give you the ability to produce predictable and repeatable load patterns, measure throughput and latency with accuracy, and still closely simulate actual production volumes with precision.
The following sections offer some suggestions for establishing such a testing regime and producing load.
Running Automated Tests
Internally, the BizTalk Performance and Stress teams use a homegrown tool called LoadGen for their testing. In order to encourage this type of testing technique and help customers and partners in the field conduct these test runs, this tool was released to the web as a free download. The following sections provide some useful information about setting up and using this test application.
LoadGen Setup
LoadGen can be downloaded from: http://www.microsoft.com/downloads/details.aspx?FamilyId=C2EE632B-41C2-42B4-B865-34077F483C9E&displaylang=en
Note |
This tool should be used in a test environment only, and should not be used against a production environment. This tool is provided "as-is" and is not supported. |
As indicated on the download page, LoadGen requires the following prerequisites, so make sure these are installed on the box before attempting the LoadGen installation:
.NET Framework 2.0 Software Development Kit (SDK)
Another important point to bring up is use of this tool with MSMQ. This transport is supported, but the LoadGen installer does not auto-register the MSMQ COM components during installation since the MSMQ runtime service may not be installed on everyone's machine. To use the MSMQ transport with LoadGen, you'll need to manually register the MSMQTransmitter.dll and ComMsmqMonitor.dll files located in the <InstallDirectory>/Bins folder, from a command line as shown:
> regsvr32 MSMQTransmitter.dll
> regsvr32 ComMsmqMonitor.dll
If you do not register the components, and intend to use MSMQ, you will receive the following runtime errors:
Cannot Load Transport DLL C:\Program Files\LoadGen\Bins\MSMQTransport.dll for Section MSMQRxQTxn. Exception has been thrown by the target of an invocation.
LoadGen need not be installed on the same box as a BizTalk Host instance. In fact, it is generally a better practice to install and run LoadGen on a separate and dedicated box to externalize its processing impact from BizTalk Server.
LoadGen is not supported on a 64-bit operating system, so make sure the LoadGen client is running on a 32-bit operating system.
LoadGen Basics
Once installed, the command-line application can be run from the <Install Directory>/Bins folder where you will find LoadGenConsole.exe. This application takes as input an XML configuration file which specifies the load profile to be created. The documentation is quite comprehensive in this area, so be sure to read it. There are also samples included which are worth a look.
Within this configuration file, there is the notion of "Sections" and it's not obvious, but these are run in parallel with each other. This allows you to create intersecting load patterns. Something to keep in mind is that generating load does not come for free. Be sure to keep a close handle on your system resources during these tests and determine if it's more appropriate to have another LoadGen instance running on another machine to achieve the desired load.
LoadGen supports a number of the native BizTalk adapters and has extensibility options to allow for creation of your own adapter harnesses. Samples for using the included adapters and for using custom transports are included in the LoadGen documentation.
In addition, if you need to dynamically change the content of each message sent, you can use the Message Creator feature (scoped within each section) to change each schema instance differently. This could commonly be used to generate unique message identifiers, etc.
LoadGen Tips and Tricks
The following are some additional tips and tricks that may help with your testing of BizTalk solutions with LoadGen:
As previously explained, LoadGen is generally better run on separate and dedicated boxes apart from BizTalk Server. This practice will externalize LoadGen's processing burden and better simulate production load.
Be sure to include LoadGen machines in your performance monitoring (with PerfMon) as well. These boxes may also be susceptible to resource limitations.
The following formula may be useful when deciding on how to specify the LoadGen configuration:
Figure 13: LoadGen Formula
Some additional advice can be found here: http://blogs.msdn.com/CSDCustomerExperience/archive/2006/01/07/510486.aspx
Achieving Simulated Testing
Part of creating a sustainable BizTalk solution may involve a number of "housekeeping" tasks normally run on the live production system. These may include your default Archiving and Purging scheme, Backup and Restore procedures, SQL Agent Jobs, production logging, etc. All of the routine processes will need to be in place in a production system, so if the goal of the testing is to mimic a real-world production system, these tasks should also be included as part of the tests.
Using a Test Run Checklist
Before conducting a test run, it is also a best practice to develop a setup checklist to ensure no stone is left unturned and all runs begin with consistent configurations. The following example checklist might be used to prime the environment before each run. The tasks are arranged by the "layers" of the logical architecture from LoadGen test harnesses at the top to senders at the bottom.
Layer | Task | Completed? |
LoadGen |
Ensure Correct Send Rate |
| |
| |
Receive Servers |
| |
Receive Locations Enabled |
Receive Hosts Restarted |
Ensure that system resources are unutilized |
| |
Databases |
MessageBoxClean executed |
| |
Recycle log files |
Check DB's disk usage is low |
| |
Send Servers |
Send Hosts Restarted and Enabled |
Send Ports started |
| |
| |
Logging |
Performance Logs started |
Run-time Checklist
Equally important is consistently monitoring the environment during the runs. The following might be a number of manual work items to perform while the load testing is in flight.
BizTalk Servers
Check machine event logs for processing errors.
Monitor the BizTalk group with the Admin MMC Console for failures.
Monitor related PerfMon performance counters
SQL Servers
Check machine event logs for processing errors.
Monitor related PerfMon performance counters
Monitoring strategies are elaborated in the "Monitoring and Reviewing the Results" section to follow.
Conducting Throughput Testing
Depending on your application's performance requirements, either throughput-based or latency-based, your testing methods can change dramatically.
The documentation article What and Wayne Clark's blog entry Understanding BizTalk Server Throughput and Capacity provide approaches to conducting successful throughput testing. The advice is to attempt to find the maximum sustainable throughput (MST) of the current configuration by slowly increasing the message volume until signs indicate that you have an unsustainable system. If properly followed, this plan also helps to identify the points of bottlenecking, and after eliminating each, the pattern is again repeated, finding the next MST value. Eventually, you will push the throughput higher and higher until you arrive at a point where the current topology cannot sufficiently handle more volume without making significant remediating changes.
LoadGen is a good tool for throughput-centric testing. When a run completes, it will output the sending rates and statistics about the documents sent.
Using PerfMon to monitor a destination queue's incoming rates (e.g. 'MSMQ Service:Incoming Messages/sec') on the other end of BizTalk Server, as an example, may be sufficient to see if BizTalk Server is keeping up with the inbound rate sustainably. You might also have luck monitoring the 'BizTalk:Messaging: Documents Processed/Sec' counters on each of the BizTalk send host instances in comparison to the sending rates of the load generator. Be warned that receive rates published by BizTalk Server ('BizTalk:Messaging:Documents Received/sec') will not be equal to the sending rates of the load generators, as these numbers include time for receive-side processing such as adapter, pipeline, and map execution. While these may be interesting to watch for bottlenecking, they should not be confused with the inbound throughput rates.
However determined, watching the outbound rates in comparison to the inbound rates (from a BizTalk Server perspective) will give you some idea of how BizTalk Server is performing. If flow rates in equal flow rates out, then you have a sustainable system. However, if your outbound rates are less, then it may be an indication that changes are needed somewhere in this messaging tier. Watching for backups at front-end queues, time-outs, or unrecoverable growth of BizTalk Server database tables will also indicate that the load is too high for the current configuration.
When in an overdrive condition, the Spool Size (i.e. 'BizTalk:MessageBox:GeneralCounters:Spool Size') will grow as messages are placed on the spool pending processing. Note that the Spool Size reported is per Message Box and needs to be summed across all Message Boxes to determine if/when spool-based throttling will occur.
The host queue length size (i.e. 'BizTalk:MessageBox:HostCounters:Host Queue – Length') can also be used to give a more granular view of the number of messages being queued up internally, by showing the queue depth for an individual host. This counter can be useful in determining if a specific host is bottlenecked. Assuming unique hosts are used for each transport, this can be helpful in determining potential transport bottlenecks.
Going any further would be duplicating the volumes of guidance already present in the core product documentation and would be imprudent, so the Performance and Capacity Planning sections of the core product documentation are your next stops on the road to conducting successful throughput testing.
Conducting Latency Testing
Latency testing has a much different approach than throughput testing. In throughput-centric applications, requirements typically come in the form of "BizTalk Server must be able to process 12 million messages within a 24 hour period sustainably", although this is oversimplified. Latency testing, on the other hand, typically has requirements which resemble the sample given below. Therefore, measuring the inbound and outbound throughput rates is not sufficient to determine if application performance requirements are being met.
Description |
Performance Requirements |
Protocol/s: HTTP Throughput Rate: 100 msgs/sec Avg. Message Size: 10K Scenario: Requests and responses are asynchronous. |
Average Latency: < 300ms Required Roundtrip Times:
Roundtrip times are measured from the time the request enters BizTalk Server to the time the response leaves BizTalk Server and is sent back to the client minus the time it spent in the back-end server. |
In simple synchronous request-response scenarios, having a load generation client which is capable of time-stamping the initiating message and then time-stamping the correlated response message would be required. However, using high-resolution time stamps is still critical. After the run, aggregating all of the results will determine if SLAs have been met for the entire message set.
In more complicated scenarios, where asynchronous requests begin at one server and responses are returned to another, more sophisticated methodologies will have to be adopted. Exact time synchronization between these different machines can be a concern. Message correlation can also be a challenge. And one might also wish to snapshot timestamps at different stages in the end-to-end processing to analyze bottlenecks or to isolate BizTalk Server from other components susceptible to slowdown.
Alaeddin Mohammed and Kevin Lam's Performance Tuning for Low Latency Messaging white paper offers some strategies for conducting a lab with such rigorous requirements. The paper and the following diagram illustrate how times could be captured and calculated by clients, BizTalk Server pipeline components, and test harnesses, and carried along by the messages.
Figure 14: Possible Latency Measuring Approaches
Other companies may wish to explore options with the Document Tracking and Administration (DTA) or Business Activity Monitoring (BAM) features of BizTalk Server, especially if already using these components in the scenario.
Remember, with latency-mindful solutions, try especially hard to isolate BizTalk Server components in the times being measured. If roundtrip delays are introduced by outside components or resources, you may spend unnecessary and possibly unfruitful effort trying to optimize the BizTalk Server platform for lower numbers.
Alaeddin Mohammed and Kevin Lam's Performance Tuning for Low Latency Messaging white paper, although developed for BizTalk Server 2004, still remains the definitive source on low latency guidance with regards to BizTalk Server. The Troubleshooting Message Box Latency Issues topic in the BizTalk Server 2006 core documentation is also a must-read.
For further information about optimizing solutions for low latency, be sure to pursue the resources listed in the "Additional Resources" section of this paper.
Monitoring and Reviewing the Results
Some tests will be architected to run for only short durations. Still others will run overnight, for 24 hours, or even longer for stress purposes. Developing a monitoring strategy up front, one which is based on a strong foundation of accuracy, is important for the team to agree upon.
Performance Monitoring
In an attempt to be as scientific as possible, complete performance metrics should be logged and backed up for every run using Microsoft Performance Monitor (PerfMon), or an equivalent. This should include metrics for all BizTalk Server boxes, SQL Server boxes, and other machines that are part of your solution.
You might create performance logs sampling at something like 15-second intervals, or perhaps longer in proportion to the run duration. Ideally, dedicating one separate machine for performance logging for the group is probably a good idea.
For repetitive counters across numerous machines, one tip is to add all counters for one of the BizTalk Server boxes, save off the logging configuration file as an .HTM file, and then manually edit the file (say, in WordPad) to add additional BizTalk servers that are part of the group. Be careful—the format is finicky with some fields maintaining fixed widths (see the figure below). Be sure to also update the CounterCount field after making changes. Also be aware that certain hosts may not be present on certain boxes in your topology, so unless you are adding all counters on all hosts (*), this may be an additional configuration step.
Figure 15: Quickly Editing the PerfMon Configuration
Another tip is to use the same line thicknesses for similar machine types or counters. This will allow for a more readable console.
Live Monitoring
You should also consider using one live console for ad-hoc monitoring during runs. The "View Graph" and "View Report" features of PerfMon are especially useful for in-flight monitoring. Creating multiple consoles, each specializing in some class of monitoring and zeroing in on similar counters (e.g., CPU across all boxes) will also improve readability.
What to Track
The BizTalk Server 2006 Performance Counters topic explains in detail each of the counters exposed by the adapters, the messaging engine, the Message Box, and other components of BizTalk Server, including BAM, BRE, BAS, etc.
For insight into what counters to track specifically, consult the BizTalk Server Performance blog at http://blogs.msdn.com/biztalkperformance/ and, of course, the core documentation. Based on your type of scenario and testing, there are recommendations for particular metrics to be watchful of and values that should raise eyebrows.
Engine throttling is also something to be aware of. More sophisticated engine throttling behavior has been introduced in BizTalk Server 2006 which prevents more unrecoverable situations from occurring by closely monitoring many facets of the BizTalk Server runtime and adjusting processing accordingly. Easily configurable throttling parameters exist on the host level allowing for tuning at a fine level of granularity. The Host Throttling Performance Counters topic explains how to watch for the appearance of host throttling and the significance of these events.
Custom Performance Counters
During performance labs it can often be useful to create custom performance counters against your own databases or even gather additional BizTalk Server database metrics.
As an example, one may wish to regularly measure the depths of the BizTalk Server Parts or PartZeroSum tables as a finer measure of sustainability. To enable logged measurement of these table depths, a simple stored procedure can be written and called periodically by a SQL Agent Job (say, once a minute), as the example below illustrates.
CREATE PROCEDURE UpdateUserCounters
DECLARE @Parts int
DECLARE @PartZeroSum int
SELECT @Parts = count(*) FROM Parts WITH (NOLOCK)
exec sp_user_counter1 @Parts
SELECT @PartZeroSum = count(*) FROM PartZeroSum WITH (NOLOCK)
exec sp_user_counter2 @PartZeroSum
For more on custom SQL user counters see the SQL Server, User Settable Object article in the SQL Server Books Online.
While this may help in performance lab diagnostics, this approach is not generally recommended for use in a production environment.
Other Tips
Restarting host instances at the beginning of each run will ensure performance counters (and hence aggregations) are properly reset. Clearing the PerfMon display will also ensure cached data is discarded.
BizTalk Server Monitoring
Monitoring the health of your BizTalk servers during and after a run is also necessary. Errors may be logged in the Windows® Application event logs, messages may become suspended, etc. Given that you will need access to many machines and the fact that it is hard to keep track of them all, it is a good idea to properly plan for this. Below are a few suggestions for how to reduce the management burden and multi-machine challenges.
Single Management Console
In multi-machine topologies, management of the many machine statuses can quickly become unruly. Creating a single Microsoft Management Console (MMC) incorporating several plug-ins will make conducting a lab much easier.
For starters, open MMC.exe and add a snap-in for BizTalk Server Administration. This will allow you to monitor the entire BizTalk group and benefit from features like its Group Hub Page, bulk suspend/terminate/resume operations, and bulk host instance restarts.
Thereafter, add an Event Viewer plug-in for each and every BizTalk Server machine in the group. Adding Event Viewers for the SQL Server boxes and other machines in the topology may also be handy. Plug-ins for other applications, such as Internet Information Services (IIS) and Microsoft Message Queuing (MSMQ), might also be a good fit for this MMC.
Figure 16: A Truly One-Stop-Shop MMC
When done, save this console .MSC file to the desktop of a monitoring machine, perhaps the same machine used to perform the performance counter logging. This one-stop-shop console will allow you to remotely monitor all boxes from one location for application errors and identify aberrations.
Single Terminal Services Console
If you don't plan on spending your lab weeks in the confines of a server room, then using Microsoft Terminal Services (TS) is a common way to remotely administer machines in the operating topology. The Terminal Services team smartly offers its own MMC plug-in, called "Remote Desktops" which allows users to add multiple connections under one snap-in. This makes it very easy to context-switch between machines without having to repetitively open up the TS client.
Figure 17: A Terminal Services MMC
You may even want to incorporate these plug-ins into your single management console mentioned in the previous section.
SQL Server Monitoring
If you are using SQL Server 2005, then monitoring has become greatly simplified. The introduction of SQL Server Management Studio, a graphical and integrated environment for accessing, configuring, managing, administering, and developing all components of SQL Server, can be close to a one-stop-shop for all things SQL Server. The console even allows you to connect to multiple SQL Server instances so that all of your administration for the entire environment can be hosted from one box.
SQL Server Management Studio has a great feature called the Summary Page, which exists for various types of database objects. For databases themselves, the Summary Page's Reports feature is very useful. It can create disk utilization reports which show, down to the table level, the physical growth of your databases. This can be helpful in identifying bottlenecks in BizTalk Server or custom databases.
Figure 18: SQL Server 2005 Summary Reports
When problems do arise at the data tier, viewing the servers' application event logs and viewing SQL Server Error Logs can help diagnose a problem.
SQL Server Profiler is another helpful tool that can help to trace the server's function, even under high load. You can aggregate job duration times, monitor stored procedure executions, etc. Just be advised that this will have a performance impact on the SQL engine, so use this tool sparingly and only when needed for troubleshooting.
For optimizing SQL Server Performance, the SQL Server 2005 Books Online contain volumes of information on the subject, so be sure to have your DBAs read this information.
Other Resource Monitoring
Since your entire solution consists of more than just BizTalk Server and SQL Server, monitoring of other third-party systems, network resources, disk subsystems, and other components of the environment may also be required. Consult your product documentation for each of these to determine the best monitoring strategies.
Tuning for Performance
Many Microsoft developers are well versed in functional testing, but often neglect thorough nonfunctional testing before running applications in production. Conducting a well-executed performance lab is a critical component of this nonfunctional testing and is intended to uncover any problems with your current design, identify hardware limitations, and suggest stabilizing improvements to your overall architecture.
The results of each successive performance run may support decisions to debug your current test cases, deployment, application code, or test scripts. These conclusions may also support decisions to change your topology, upgrade current hardware, scale up or out, modify platform settings (e.g. .NET CLR runtime properties, IIS application pool configurations, operating system configurations), adjust BizTalk Server defaults (e.g. throttling parameters, batch sizes, polling intervals), tune disk subsystems, optimize network resources, explore other hardware alternatives, or refactor code or rewrite code. After each of these changes, the execution cycle may be restarted, returning to conduct further testing, reviewing the results, and removing still more bottlenecks.
For expert guidance on how to monitor environmental resources, detect and remove bottlenecks, modify BizTalk Server settings, and tune the platform for your applications, use the resources in the "Additional Resources" section of this paper. The BizTalk Server product group has realized the importance of providing prescriptive guidance for optimizing your BizTalk applications, but this paper is just the start. The referenced resources will walk you through the "forensics and surgery" of the performance lab and help to ensure that you conclude with a healthy platform that will support your business for years to come.
Arrive at sufficient performance lab goals.
Present final performance characteristics of the solution.
Finish the Lab Manual or Engagement Document.
Update the Executive Summary with conclusions drawn from the lab.
Conclude the engagement.
The finish line! With all of the proper planning in place, you and your team can conduct a successful performance lab with BizTalk Server 2006. When completed with the engagement, remember to present your findings to the business and celebrate with the team that made it possible!
Below are some pointers to additional resources which will help you conduct a successful performance lab engagement with BizTalk Server.
Documentation Articles
The core product documentation is always the best place to begin. Below are some articles in particular which warrant close reads.
Name | Description |
Includes a variety of resources that can help you learn to develop, deploy, administer, and use BizTalk Server 2006. | |
An entire section of the documentation is meant to address the concerns of performance and capacity planning with regards to BizTalk Server 2006. Whether you have worked with previous versions of BizTalk Server or are brand new to the 2006 product, you should become intimately familiar with this section of the docs. | |
This section provides useful tips for ensuring optimal performance for your BizTalk Server system. | |
This section describes how to plan, test, and scale your BizTalk Server system along an entire application life cycle, so you always maintain optimal performance. | |
The goal of this section is to provide a set of recommendations that will help you plan appropriately for a successful BizTalk Server 2006 development project with regards to performance. | |
This topic explains how to identify and resolve the performance bottlenecks in the BizTalk and Database tiers. | |
A technical reference for BizTalk Server performance counters, including the many newly released 2006 counters. | |
This section describes configuration settings that can affect the performance of BizTalk Server adapters. | |
The article provides guidelines for working with large messages in BizTalk Server 2006. |
Knowledge Base Articles
The following KB article is also a must-read.
KB Number | Description |
917845 |
You experience blocking, deadlock conditions, or other SQL Server issues when you try to connect to the BizTalkMsgBoxDb database in BizTalk Server 2006 or in BizTalk Server 2004. http://support.microsoft.com/kb/917845/en-us SYMPTOMS In Microsoft BizTalk Server 2006 or in Microsoft BizTalk Server 2004, you experience blocking, deadlock conditions, or other Microsoft SQL Server issues when you try to connect to the BizTalkMsgBoxDb database. |
Note |
Some free services, such as KBAlertz, allow you to subscribe to all KB articles posted by technology and stay abreast of new knowledge Base articles that are published by Microsoft. |
BizTalk Server 2006 Documents and White Papers
Outside of the core product documentation, there are some other pertinent articles related to performance and capacity planning which are worth reading.
Name | Description |
The installation instructions explain how to install BizTalk Server 2006 on Windows XP, Windows 2000 Server, or Windows Server® 2003 in a single-server or multi-server environment. | |
The SQL Server 2005 Books Online instruct you on properly installing and configuring the database management system. | |
A walkthrough for installing SQL Server 2000. | |
This white paper describes the results of a comparative adapter performance study—a set of tests that compared each adapter that ships with Microsoft BizTalk Server 2006 against its BizTalk Server 2004 SP1 counterpart under identical conditions. The test techniques used to arrive at the maximum sustainable throughput (MST) are described in detail, and recommendations for using and configuring specific adapters are provided. |
BizTalk Server 2004 Documents
Many of the BizTalk Server 2004 articles and white papers are still quite relevant to the 2006 product and illustrate universal strategies that companies should adopt. The following table lists some of the best.
Name | Description |
This document provides information about the performance characteristics of key Microsoft BizTalk Server 2004 configurations and components, such as messaging, pipeline, and orchestration. This has been updated for BizTalk Server 2006 and included in core documentation, but the 2004 paper is still worth a read. | |
This paper by Alaeddin Mohammed and Kevin Lam describes performance tuning suggestions for low-latency messaging. |
Blogs and Web Links
The following table lists Internet resources which continue to be knowledgeable and timely sources of information about BizTalk Server and performance.
Name | Description |
BizTalk Server Product Team Blogs |
Straight from the production team, these blogs present the latest and greatest resources on the BizTallk Server product. |
This site continues to be updated with scripts which help with installation, configuration, management, maintenance, and testing of BizTalk Server solutions. | |
Online resources for BizTalk Server developers. | |
Online resources targeted at BizTalk Server administrators and IT professionals. | |
This guide provides end-to-end guidance for managing performance and scalability throughout your application life cycle to reduce risk and lower total cost of ownership. It provides a framework that organizes performance into a handful of prioritized categories where your choices heavily impact performance and scalability success. The logical units of the framework help integrate performance throughout your application life cycle. Information is segmented by roles, including architects, developers, testers, and administrators, to make it more relevant and actionable. This guide provides processes and actionable steps for modeling performance, measuring, testing, and tuning your applications. Expert guidance is also provided for improving the performance of managed code, ASP.NET, Enterprise Services, Web services, remoting, ADO.NET, XML, and SQL Server. |
Webcasts and Presentations
The following table lists some Webcasts available for download on the subject of BizTalk Server performance.
Webcast Name | Description |
Implementation and Tuning Best Practices for BizTalk Server Solutions |
Learn about the development techniques used in building Microsoft BizTalk Server solutions, including common development patterns and best practices for implementing business processes in BizTalk applications. This Webcast explains how to design for operations by properly factoring your application to support versioning, best practices for versioning your artifacts, and how to optimize your orchestration design for performance. Presenter: Jeff Nordlund, Program Manager, Microsoft Corporation |
Decks and session records should be made available on the TechEd Web site. There is also an optional DVD which can be purchased which includes recordings of all of the conference's presentations. Specifically seek out "Building and Maintaining a Performant and Healthy BizTalk Solution" by Lee Graber, "BizTalk Server Capacity Planning" by Wayne Clark, and "Monitoring and Troubleshooting BizTalk Server 2006 Solutions" by Kris Shankar. | |
Hans-Peter Mayr, GROUP PROGRAM MANAGER Microsoft Biztalk Server 2004 has been architected for high performance and scalability. This Webcast dives into BizTalk Server 2004 performance characteristics and explores real-world lessons from the Joint Development and Early Adopter Programs. |
The table below lists some tools provided by Microsoft and the community to assist with different stages of conducting a performance lab engagement.
Tool Name | Description |
This tool is intended for developers and IT professionals to simulate load against BizTalk Server 2004 or 2006. Using this tool, you can simulate load to instrument performance and stress against a BizTalk Server deployment. In addition, this tool may also be extended by developers to simulate load for custom transports. This tool should be used in a test environment only, and should not be used in a production environment. This tool is provided "as-is" and is not supported. | |
This script is intended to return your BizTalk Server test environment to a fresh state with regards to the Message Box between runs. It deletes all running instances and all information about those instances including state, messages, and subscriptions, but leaves all activation subscriptions so that you do not have to re-enlist your orchestrations or send ports. Note: This tool is not supported on production systems. |
Lab Services
The following table enumerates some lab services that the extended Microsoft team provides to assist with conducting performance labs. In all cases, work with your Technical Account Manager (TAM) to apply for an engagement.
Lab Service | Description |
MSServices Lab Offering: BizTalk Server Tune & Stress |
Developing a BizTalk application, setting up the servers and databases, and tuning the application and environment needs to consider many different variables. This solution offering can help customers tune and stress their BizTalk applications to get better throughput and performance out of their systems. Speak with your Technical Account Manager (TAM) for more information. |
Microsoft Technology Centers: BizTalk Design, POC and Performance Offerings |
MTCs can help customers from all named accounts (Global, Strategic, Major and Corporate), including partners and ISVs with .NET Server revenue potential with BizTalk Server assistance and address possible pain points as follows: Target customer might need assistance with:
Possible pain points include:
Your Technical Account Manager (TAM) can help set up an engagement at an MTC near you. |
CSD Customer Collaboration Center (Redmond) |
The End-to-End (E2E) group is the home of the Connected Systems Division's End-to-End program where we focus on ensuring that BizTalk Server and all Connected System Division products and technologies meet or exceed customers' expectations during the full life cycle of their interactions with the product. The E2E group runs the CSD Customer Collaboration Center, which is a customer-focused lab used for in-depth customer and partner engagements or projects. The lab is specifically for customer-based engagements that are being run by members of the product team under the sponsorship of the End-to-End team or the Customer Programs Team. Speak with your Technical Account Manager (TAM) to submit a lab request. |
Enterprise Engagement Center (Redmond) |
The Enterprise Engagement Center, or EEC for short, is a specialized lab located on the Redmond campus. As part of the Windows Server Customer Experience Team, the EEC improves quality, drives capabilities, and accelerates the adoption of Microsoft products by capturing and testing real customer scenarios prior to product release. Customers come to the EEC to pilot deployments, upgrades, migrations, lock-downs, and enhancements. The EEC provides product groups the opportunity to listen to customers as they are setting up their environments and testing. EEC customer scenarios provide real-world input to drive Microsoft engineering excellence. The EEC has hosted hundred of customers over the last several years and has become the gold standard for customer test labs throughout the world. Contact your Technical Account Manager (TAM) to fill out an engagement application form. |
As the old saying goes, "Failing to plan is planning to fail". Conducting a successful performance lab will help to ensure a successful and predictable BizTalk Server implementation for years to come. Taking the necessary time up front to plan your performance lab's approach and methodology will save a lot of time during the running of the lab and increase your chances of success.
For more information


text:
India's Partition – Unknown Aspects
Caught between a neo-colonial narrative jointly crafted by the British and Congress Governments in India, events have a way of being losing context and substance. Jinnah as the man behind partition, is a story that is only partly true.
Three interesting incidents in that crucial period make for a counter-balance to the Jinnah-as-the-villain story that is made out.
The Gallup Poll
Over a period of at least 50 years, successive British bureaucrats and propagandists sold India the story that Hindus and Muslims cannot live together.
On April 23, 1947, the 'Amrita Bazar Patrika' featured results of a poll where it had asked if Bengali Hindus wanted a "separate homeland". An overwhelming 98.3% Bengalis voted in favour, and 0.6% voted against the division of the province. On being asked about this poll, both Dutta Gupta and Singha express concern and suspicion about this poll and many other public discourses that came to conclusions that completed neglected the voice of Hindus living in East Bengal. (via 'We can only carry India in our hearts' – Times Of India).
These surveys, were engineered by the Gallup Organization, a leading opinion-polling agency, which controlled India from UK. There was a large body of opinion and support for Muslim autonomy in Muslim majority areas – and 'Hindu' support for a Muslim Homeland was in this context. Also, must be the remembered that in polls like this, the question is more important than the answer.
And the reason for the result of this poll, was the questionnaire.
Lala Lajpat Rai asked for Pakistan
Another significant votary for Muslim autonomy in Muslim-majority areas was Lala Lajpat Rai – whose ideas are being projected as support for Pakistanand Partition of India.
The 'innocent' Indian Muslim
Just like 'Hindu' support for Pakistan is being twisted out of context, it is equally true of 'Muslim' support for Pakistan.
For another, we forget that Indian Muslims from India, Bangladesh and Pakistan did not vote for Pakistan or Jinnah.
It was a small minority, of less than 5 lakhs who voted for the Muslim League, carefully selected by the British, which was designated as representative of Muslim interests, that voted for Pakistan. From the nearly 10 crore Muslims. A fact we would do well to remember.
Indian Muslims did not chose the Muslim League. British policy in India made it seem that Indian Muslims had chosen the Muslim League. Of the nearly 10 crore Muslims, less than 5 lakhs voted for the Muslim League. Jinnah's claim and bravado sprang from the backing of half a per cent of India's Muslim Population.
Popular leaders like Sheikh Abdullah of Kashmir or the Deoband Seminary rejected emphatically Jinnah and his Pakistan theory. The ordinary Muslim had no truck with Jinnah or Pakistan. Meanwhile, Sachar Committee report notwithstanding, the 'ordinary' Muslim before Independence was behind the general population – and remains so.
Related articles
- Hindu Muslim Bhai-Bhai – End of an Era (quicktake.wordpress.com)
- Letters: Wounds of partition still not healed (guardian.co.uk)
- [Huffington Post] How Pakistan Drifted Away from Itself (kashifmd.wordpress.com)
- Hindu-Muslim divide reaches beyond the grave (seattletimes.nwsource.com)
- Snapshot of Bengal Partition (quicktake.wordpress.com)
September 30, 2011 at 5:24 am
this is irrelevant to this post, however I wanted to share a thing I read about. There is a famous tamil writer called jeyamohan, and he wrote an article about the book he read which details how the british exploited salt trade in india and how they made a natural fence out of thorns to control its trade throughout north india. the article in tamil is here. The book can be found here. -
September 30, 2011 at 4:09 pm
Covered by the post The British Salt Tax. How Damaging?
Short URL – http://wp.me/pl2xA-23X -
December 27, 2011 at 7:00 am
Interesting take on the topic and a nice unfurling of the pages of history. I myself wrote a bit relevant piece regarding the history of Pakistan that is told to the children in Pakistani elementary schools. You can view the post at my blog: http://jawadrasheedsheikh.wordpress.com/2011/12/26/history-a-pack-of-lies/
Nice sharing

subset: commoncrawl


text:
Friday, November 4, 2011
Grading: the actual slog of doing it
I'm not behind. It's just grading season. And it's going to get worse before it gets better.
Wednesday, I will get 40 annotated bibliographies from my first years. And then the grad ones. I've got at least 40 new things coming in to grade every week until the end of term. They need really good feedback because it's components of a stepped essay assignment. And so they also need to be turned around really fast.
I'm getting more efficient, and I hope effective, as I do this job longer, but I'll be honest and say that the piles of grading fill me with dread. There's just, it seems, too much of it to really do. 30 proposals in one day was a lot, and I had to do them in batches of five or six, with other tasks in between, because soon enough I run out of ways to say "a statement of commonly accepted fact is not a thesis; a thesis statement should articulate an informed opinion with which reasonable people might disagree" and "if you develop a real thesis your paper will be easier and more fun to research and write."
(And more interesting for me to read, but never mind that.)
Sometimes I grade work submitted electronically, sometimes I work from paper, sometimes I put my notes by hand on a piece of writing, sometimes I write it up on the computer and print it. I always sign my initials right by the grade, to accept my responsibility for the assessment.
I'm not sure what works best, always, but I'm overwhelmed and procrastinating so I thought I'd try to start a conversation here: how do you get through the grading crunch?
One of my tricks: clumps. If it's one- or two-page assignments, I'll grade six first thing in the morning, then do something else, and then grade another six, then a break, then grade five, then something, then grade four. I find my tolerance goes down throughout the day, so the 'clumps' have to get smaller because I burn out more quickly. By the end of the day, my 'clump' of grading between other tasks might go down to one or two. So my trick is to start hard in the morning, then lower my expectations and my quotas as the day proceeds.
What do you do?
13 comments:
I second the "clumps" idea. If possible, I also build in little rewards in an "if / then" formula, e.g. "if I grade 5 assignments, then I can X," where X might = anything from "make tea," "check in on Twitter," "do some reading," "stretch and walk around" or "swear and break something." I think it's no favor to the students for me to try to plow through huge stacks all at once: I worry that the students towards the bottom of that stack will encounter a grumpier version of me! (The exception to that for me would be short-answer exams, where I think working on larger clumps means greater consistency.) Sometimes, if I know a class well enough, I save some of the papers I expect to be strongest for later in the process.
ReplyDeleteI'm a clump person, too. I also set a time limit for myself: not to spend more than X minutes on a paper (decided by the length/purpose/etc of the paper). You could spend hours on a paper if you let yourself, so I'm pretty strict with limiting how much time I spend on each paper, then I give myself lots of breaks.
The time of dread is coming for me too. I might have five writing classes, but they are capped pretty low for this very reason. I can take more time to grade and give feedback.While i read the entire paper, I only provide line-edits on the 1st page (and the biblio) of student assignments. Each student receives a 1/4 page of handwritten comments and i try to burn thru a 1/2 class set a day (but have only a few days a week which i have set aside for marking). i also try and prioritize in-class spoken comments (in CW classes) over written commentary to model social critique of creative writing...
ReplyDeleteI do the clump approach too...and I often try to mark 1 or 2 that I think will be 'good' first and then save 1 or 2 (hopefully) good ones until the end. I am terrible about getting distracted while I grade, so doing small numbers at a time helps. I teach entirely online so my grading is all on the computer...sometimes I use a paper rubric or grading sheet and fill it out by hand (and then scan the grading sheet to return it electronically). I find being able to write on paper helps give me something else to focus on while I am grading and my students often appreciate the handwritten comments (if they are legible!). I have also started using Evernote as a way of providing students with feedback. I create an Evernote notebook for each student and share the private link with them individually. Then, I can just add comments/feedback/marks for each assignment to their notebook. This works particularly well for journal assignments or for other long term or big projects that they work on and which I give them feedback on periodically throughout the term.
I am teaching 4 courses this term and it is crunch time for me too...lots of grading will start to come in every week for the next month. I'm not looking forward to it, but I know it must be done! On that note, I must get back to it this morning!
Joanne"Clumps" of 5 or 6 at a time was the approach I took when I taught at the UofA. I also tried to group essays that tackled the same assignment option as a way of (hopefully) ensuring I was grappling with the assignment topic as well. I invested a lot of time in both copy edits and comments engaging the content as I treated the formal written assignments as an important learning tool. Writing detailed comments throughout the essay was, for me, an ongoing critical dialogue, especially when I would invite the students to submit follow-up informal responses to their marked assignments. Grading/marking is a lot of work, but I genuinely miss it.
JonathanI'm a clumper as well, usually 6-8 at a time. I collect everything electronically, but I don't spend much time inserting typed comments. Instead, I record my responses. They tend to run between 4-8 minutes. I export them as mp3 files and send them to each student.
This was slow-going at first, but once I developed a process that worked for me things moved along well. I still dread grading and procrastinate, but once I face the monster it's not so bad.
And, my students love it.I'm actually a marathoner, myself. Because I TA small sections with 20-25 assignments coming in at a time, I try to get a first read-through and initial grading done as fast as possible so that all the assignments (and thus the range, connections, general problems, strong points, etc.) stay fresh in my mind. I then scan back through my comments to assign grades.
My biggest problem this early in the game is confidence in the mark I am giving. I sometimes go back and change a grade 3 or 4 times, anxious that I'm being too hard and thus discouraging or too easy and thus not pushing them to work harder. I fantasize about a world in which I could provide detailed written feedback without assigning a number, and students would actually read that feedback and use it to work on their writing without the threat of failure dangling over their heads.I try to mark blind for various methodological reasons, so things like putting some likely good assignments near the end are ruled out.
FWIW, I think Hannah's approach is a good step towards fair marks. I do something similar. A first read through during which I put some preliminary comments in margins, sorting the assignments into roughly equivalent piles as I go along ("that's an A, that's a B-" etc, more piles for more important assignments). After I've been through all of them once I read them again: this time to see if they're sorted fairly ... is the worst B+ really any better than the best B? This stage involves a bit of adjusting, usually. I also add a final comment on the front of each paper (usually trying to be more encouraging than the more pointed stuff that went on the paper first time through). I do all this because I'm acutely aware of how often I think irrational things like "boy, they're getting dumber as I go to the bottom of the pile", and because I think some pretty good papers can suffer if I read them right after I've read a brilliant one (or a rather poor paper benefit from being read right after a stinker).
Those comments are a bit off the "how do you stand it?" question. Mostly because I have nothing worthwhile to offer on that question. I just continue to pour down cup after cup of coffee as I mark. So the business about taking increasingly frequent breaks pretty much enforces itself.I should say my clumps are compressed into the fewest number of days: so I'm not one of those people who will grade 4 essays a day for 10 days. I need to be in the headspace of that particular assignment pretty intensely.
I do that thing too of not putting numbers on the first bunch, but of sorting them out on the floor to get an idea of the range and spread and comparative accomplishment.
Once, when I was an undergrad in a third year course on the romantics, I remember one of my favourite professors, Bob Casto, handing me back a paper on Coleridge and aging and saying "I always save yours for last because they're the best" and I was totally thrilled by that, and I can, now, kind of understand the impulse to save the pleasant for the very end, but I only rarely indulge in this myself. I'm more likely to stick the likely-to-be-troublesome ones into the pile early, while I'm cheerful.I used to grade midterms and exams by section, so I would do the first section (i.e. short answer section) first, then take a break, then do the next. For the essay questions I would break the midterms and exams into groups based on the essay question the student answered. It helped me gauge the papers and to prepare adequate notes about what should be expected from that paper without having to switch gears each time I switched papers. With essays I would also form clumps based on the question they answered and sometimes I would indulge myself and mark the papers I had reviewed with students (the ones I was confident would be fun to read) first. I tend to write notes on the papers for students, but I always use pencil (when I mark late at night and haven't had my nicotine or caffeine fix I can be a bit snide so I have to edit myself). If I have time I usually review papers after marking by forming new piles according to the assigned grade and then I review each paper and make alterations where necessary.


text:
Ancient by Kitaro
Released: May 8, 2001
Format: CD / Digital Download
2002 Grammy Award Nominee Album
Take an extravagant excursion through the ancient civilizations of Egypt, Mesopotamia, the Indus Valley and China with Grammy Award winner Kitaro on his latest release, "Ancient". Kitaro manages to transport the listener to a mystical and contemplative place with the glorious textures of Great Pyramid. This magical journey also features the majestic and dramatic resonance of Nile and the eloquently evocative Unicorn, with it's airy, almost playful melodies. Ancient manages to create audio imagery with exotic, unpredictable sounds, ancient wind instruments, and among other things, the synthesizer. The result is a sound that seems primeval, yet Kitaro's artistic sensitivity makes it distinctly modern, ultimately exploring the connection between humans and the earth itself, which remains eternally beguiling and wonderously captivating in its mysteries.
02. Main Theme
03. Ancient of Wind
04. Ritual Dance
05. Water of Mystery
06. Tumba Dance
07. Wave From Ancient
08. Spirit of Harp
09. Great Pyramid
10. Mysterious Triangle
12. Unicorn
13. Crystal Sand
14. Dholavira
15. End Theme BEYOND


text:
Greece's leftist-led government has survived another parliamentary vote on a reform bill demanded by the country's international lenders. In return Greece gets 1 billion euros to pay off debts.
The bill makes changes to the public sector wage grid and opens the market for banks to sell off bad loans.
Greece's Deputy Finance Minister George Chouliarakis addressed the chamber.
"This bill serves as a solution for non-performing loans and, as a consequence, also helps liquidity and boosts the economy. It does this while – and this is its aim – it protects the households and businesses that are most vulnerable."
Greece Bailout Reforms Advance in Parliament https://t.co/rgD5pEdWkC
— 英語学習 (@study_english_5) December 15, 2015
As usual there was heated debate in the chamber where the government has a majority of only three. All of the coalition's 153 deputies voted in favour of the bill.
The President of the opposition PASOK party Fofi Gennimata, was at her scathing best when she made her statement:
"And now what are you asking? That we become your accomplices? That we vote for what you used to be against ? Or do you want us to forgive you over the awful way of thinking that led the country in this point?
After five years of austerity including 12 pension cuts, the government plans to raise social security contributions instead of slashing main pensions again. But the lenders have signalled reluctance, saying it could further damage employment.
The reform must be adopted in January prior to the first bailout review, which Tsipras wants to conclude swiftly to open the way for talks on debt relief, which he urgently seeks to convince Greeks that their sacrifices are bearing fruit.
Euro zone institutions representing the creditors and the International Monetary Fund are expected to issue a compliance report on Wednesday.
All views
Get a different perspective
Every story can be told in many ways: see the perspectives from Euronews journalists in our other language teams.


text:
Bayplay & Beyond, Bayplay Adventure Lodge, Bayplay And Beyond
- Address
- 3755 Pt Nepean Rd, Portsea VIC 3944
- Contact
- Ms Amanda Crestani
- Phone
- 03 5984 0888
- After Hours
- 03 5984 0111
- firstname.lastname@example.com
- Website
- http://www.bayplay.com.au
Click to view the news RSS feed.
Blue-green algae warning for Lake Moodemere
20 Mar 2017
Parks Victoria announced that a blue-green algae (BGA) bloom is currently affecting Lake Moodemere, west of Rutherglen. The public is warned not to swim in and to avoid any direct contact with blue-green algae affected water. Direct contact with blue-green algae can cause allergic reactions such as skin rashes or…


text:
campfire. Festival
11am - midnight, daily Fri, Aug 30 - Mon, Sep 2, 2013
Venue: Club Passim
47 Palmer Street, Cambridge, MA 02138
Contact:Passim Non-profit Arts Organisation
0 people saved this
It started as a way to fill a bad booking weekend in 1998, but over the course of more than 10 years, the campfire. festival has become the single-biggest way that Passim develops new talent and celebrates the Boston area's amazing music scene. Originally called, "On the Cutting Edge of the Campfire," the festival combined the idea of artists sitting around the campfire playing music with our commitment to bringing new talent to discerning listeners. Today, the campfire. festival is as much about the community as it is about the music. "In the round" performances with songwriters swapping tunes are as common as solo and band sets throughout the course of each day of the festival.
MA Spotlight on Dave McGillivray
Dave McGillivray, Marathon Man The 121st Boston Marathon takes place on April 17, 2017, and is one...
Search All Listings Here.


text:
Celebrating Our Final, but also Thinking Ahead to Our Next Project
Lesson 15 of 15
Objective: SWBAT to celebrate their writing by reading their classmates' research essay and giving them advice about next steps for the next project.
Lesson Opener
In my lesson openers I always have a "connect" in which I connect students' thinking about yesterday's lesson to today's lesson. I then have a "teach" in which I model for students the lesson of the day and also have them try it out. When I think about my modeling, I use three categories; skill, strategy, and process. I model by stating the skill to the students, then giving them a strategy in which to use the skill, followed by the process to try out the strategy.
Connect: I will say, "We have been working so hard on our writing, so now it is time to celebrate! When authors publish their writing, they have publishing parties. Today we are going to do just that. *If students are not completed with their final draft, I set aside the back part of my classroom for them to work on their final while the other students are in this activity.
Teach: I will say, "In order to celebrate our writing, we will read each other's essay I am going to practice the skill of giving and receiving feedback and the strategy of thinking through the rubric. The process I will use is as follows:
1) Have a peer look for a specific component of my essay*
2) Give feedback to my other peers in order to help them with their writing, but also my thinking
3) Reflect on my peer feedback
I will model for students how I read through a student's final draft (I will use one from another class and redact the student's name) and show the students how I give advice and ask questions. I want students to learn from their peer feedback but I also want to see how students are asking questions at this point in the year as well.
The will use the peer feedback column of the rubric they received yesterday.
Independent Practice
Independent Practice: I will say, "Now you are going to read over each other's writing independently and quietly. You will only travel with your pencil. You will move one seat in front of you when I say go. You have 10 minutes to read over your classmate's draft. When you get to their writing, read only for the standards of the rubric I direct you to read (they read for two parts of the rubric).
During this time students will read over each other's writing. They will go through three rotations of two standards each (7.5 and 7.7 are for teacher use only). As they are doing this I am either helping the students in the back who have not finished their essay or reading an essay with a student. The only conferencing I am doing with students is ensuring they are following the feedback format.
Here is our Writing Celebration.
Resources (1)
Resources (1)
Closing: For closing today I have students complete a reflection in their writers' notebook. I will say, "Write a reflection stating what you think you did really well and that sets a goal for their next writing project based on what standard you want to keep working on."
I have them turn in all of their drafts, their rubric and their final draft. I do not staple it because I will run their final draft through the copier for their hallway display.
When they are all completed I give them a treat. I usually buy them donuts or cookies.
Similar Lessons
Environment: Rural
Revising Previous Work
Environment: Suburban
Writing a Hook for the Introduction
Environment: Rural
- UNIT 1: Using Mentor Texts,Generating Ideas and Planning for Drafting Memoirs
- UNIT 2: Drafting, Editing and Completing a Final Memoir
- UNIT 3: Explanatory Essay
- UNIT 4: Research Essay
- UNIT 5: Text Structures Project
- UNIT 6: Presentations of Text Structure Project
- UNIT 7: Vocabulary
- UNIT 8: Using Mentor Texts, Generating Ideas, and Planning for Drafting of Persuasive Essays
- UNIT 9: Drafting, Finalizing and Celebrating Our Persuasive Essays
- UNIT 10: Engaging in Debate
- UNIT 11: Literary Essay Part One; Song the Trees
- UNIT 12: Literary Essay Part Two; reading two more stories in order to craft comparative essays
- UNIT 13: Literary Essay Part Three; drafting, finalizing and celebrating a comparative literary essay.
- UNIT 14: Poetry
- UNIT 15: Fiction Unit
- UNIT 16: Editing, Revising and Finalizing our Fiction Story
- LESSON 1: Generating Ideas for a Research Essay by Thinking About a Future Job
- LESSON 2: Gathering Evidence for a Future Job Using Print Resources
- LESSON 3: Gathering Evidence for a Future Job Using the Internet
- LESSON 4: Organize Your Research About Your Future Job
- LESSON 5: Starting a First Draft By Setting Goals and Reviewing Organization
- LESSON 6: Generate Ideas for Another Draft by Choosing Issues that Matter to Us
- LESSON 7: Researching Different Kinds of Evidence About Issues By Using Non-fiction Texts
- LESSON 8: Researching Different Kinds of Evidence About Issues Using the Internet
- LESSON 9: Organizing a Second Draft with Citations
- LESSON 10: Generate Ideas by Using Our Learning from Science and Social Studies
- LESSON 11: Independence While Using the Internet
- LESSON 12: Gathering Evidence in Non-Fiction Texts By Using Readers Marks
- LESSON 13: Putting Together A Third Draft by Concentrating on Analysis
- LESSON 14: Rubric for Research Essay
- LESSON 15: Celebrating Our Final, but also Thinking Ahead to Our Next Project


text:
Hey,I'd really appreciate it if someone could help me with my LJ layout. I think I got it pretty much how I want it at the moment,
[]Page Title - Love doesn't matter any more
[]Where would you like the entries? - (center, left, right.) left
[]Border - (Dashed, dotted, solid or none) solid
[]Border Size & Color - (1 being very thin, and 10 being the thickest.) 2
[]Link Colors -
[]Cursor- crosshair
[]Background Link - http://art-epiphany.com/gallery/gallery2
[]Background color -
[]Background color for journal entries - see threw
[]Font, font color, and font size - Verdana, white, 12
[]ScrollBar Colors - black and white, or what ever colous you think goes good
[]Screen resoloution: I don't know what this means, but if it's important, I'll provide you with an answer to it if you tell me what it is :)
[]Any thing eles- can u make the comment thing say (im just making this number up) 10 gave me a rose(for the number of people who commented).. give me a rose?(for the people who comment)
Thanks to who ever helped me..if need add