They announced the SQL Heroes contest winners at the PASS Summit keynote today. I’m very happy to say that both BIDSHelper and ssisUnit were in the top 5! BIDSHelper had a perfect score of 55 (the only perfect score), based on the judging criteria (yes, 55 was the max you could score). ssisUnit tied with Extended Event Manager, from Jonathan Kehayias, with a score of 45.
Thanks for voting, and please keep the suggestions for improvements coming in.
After I created the Batch Destination for my presentation at the MS BI Conference, I was talking with Matt Masson, who let me know that they’d been working on a MERGE Destination sample component, and would hopefully be releasing it soon. It’s out now on the CodePlex site for the Integration Services team samples. I’ve taken a look at it, and it is very nicely done.
What’s the difference between the two? The MERGE Destination has a much nicer interface, that lets you graphically build a MERGE statement. And, of course it uses the MERGE statement to perform updates and inserts in a single operation. This is nice, but limits you to using a SQL Server 2008 database as a destination. The Batch Destination executes any SQL command you give it, so it can be used on SQL Server 2005 or 2008.
I haven’t done a performance comparison between the two, so I’m not positive which one is faster. However, the MERGE Destination stores the working data in memory, so it should be more efficient at loading the data. This does require the MERGE Destination to create a type and a stored procedure in the destination database, so the appropriate permissions need to be provided. The Batch Destination uses the ADO.NET Bulk Copy functionality, so the data is persisted in a working or temporary table in the target database, and cleaned up afterward, which is likely to be slower. However, you don’t need any special permissions to create a temporary table.
This isn’t intended to be a “this one is better than that one”. I can see using either or both as circumstances dictate. I just think it’s nice to have options.
Todd McDermid (a frequent poster on the MSDN SSIS forums, and creator of the Kimball SCD component) and I have started a new project on CodePlex along with Todd McDermid, the SSIS Community Tasks and Components (ssisCTC) project. This project is intended to be a umbrella project for custom SSIS tasks and components that are released as open source, as well as provide a listing of other open components for SSIS. I’ve published the Batch Destination component that I created to the site, and intend to add some more over the coming months.
Why set up a community project around this? Primarily, because I’ve found that many single person projects get one release, and then are never touched again. Having multiple people involved helps insure that if one person gets busy, or moves on to other interests, there are still people around to maintain and enhance what’s been put out there. So, if you are interested in joining or contributing, please let me know, or get in touch with use through the CodePlex site. Also, if you have or know of a freely available SSIS component or task, let us know, and we’ll be happy to add it to the list.
David Reed, who manages the SQL Server community samples on CodePlex, has been running a SQL Heroes contest. It’s for open source applications that help improve the SQL Server experience. You can read more about it on the SQL Heroes blog.
I find myself in the interesting position of having two horses in the race: BIDS Helper (with Greg Galloway and Darren Gosbell) and ssisUnit. If you use either (or both) of these, and like them, please vote in the Finalists Survey.
If you don’t use them, why not give them a try? 🙂
Only certain cells are considered “writeable” in a PPS Plan Excel form. A writeable region is a region where the user can enter data. Here is a checklist of reasons why a region that you expect to be writeable is not.
I put this list together based on some correspondence with the PPS Team, as well as adding in everything I found on the forums… this isn’t my work. I just wanted to post it somewhere that I wouldn’t always have to go looking for it…
1. Verify your form.
1. Verify that you have authored a form in Excel that uses every dimension/hierarchy that’s in your model (as a column, row, or filter).
2. Verify that the ‘Allow Data Entry’ property is set to true for the matrix.
3. Note that you can only write to cells that match the model’s member set view for time so the form should be authored with the same time hierarchy as the model’s member set view.
4. Verify that the matrix is using the correct model for the cycle.
5. Verify that the matrix is using the correct scenario for the cycle.
6. Check that the cell style “Data Entry Cell – PerformancePoint” has distinct formatting from the cell style “Data Cell – PerformancePoint”, and type directly into a cell expected to be writeable to confirm that the add-in is preventing data entry. (Use the “Reset Default Cell Style” button in the PerformancePoint options dialog to restore default settings for the styles)
7. If you use Custom MDX:
- Verify you have crossjoined [Measures].[Value] to the columns.
- If you want annotations, you have crossjoined [Measures]. [Model_MeasureGroup_AnnotationCount].
- No level that you’re entering data into is aliased with the With Member statement.
2. Verify your cycles.
1. Verify you’ve published the form as a Form Template from Excel.
2. Verify that your form shows up under “Forms” in the “Forms and Reports” section.
3. Verify that the cycle and assignment status is started.
4. Check the Model | Summary page and note down the Current Period; this may affect the time range for the form.
5. Verify the cycle has the correct start and end dates (and that the current date/time is between them).
6. Verify the cycle has the correct scenario.
7. Verify that you’ve assigned the correct form to the Cycle and assigned the correct people as Contributors/Reviewers/Approvers.
8. Verify in Process Management | Cycle Instance | Forms Assignment that the status is started for the user.
3. Verify your security.
1. Verify that user permissions for the roles used in the assignment are set properly. This includes being able to Write data to all leaf nodes, as well as ensuring that the role is turned on for the model.
4. Verify you’re running the form correctly.
1. Verify that you’ve opened the form as a Contributor (i.e. with appropriate credentials), and have opened the Assignment and not just gone to Reports>Open.
2. Verify that you have put all filters to a leaf level.
3. Verify that you are entering in at the correct scenario at a leaf level of all dimensions (unless you have enabled input at all levels, in which case, only the filters must be at leaf levels).
4. Verify that the matrix is showing data at a leaf level for all dimensions in the measure group. Alternately, turn spreading on to see where non-leaf data entry is possible – but note spreading does not work across time.
5. If the writeable region appears for a contributor but not for an approver, check that the option “Allow the approver to edit submissions” was set on the assignment definition. Also be sure that the approver is using the individual assignment (from the review/approve dialog) rather than the grouped assignment.
A colleague came to me recently with a problem. She was implementing a Dashboard in PPS M&A, and she was seeing some unexpected dimension names. The behavior was specifically affecting her when she was creating a report using an Analytic Grid, but it was consistent inside of PPS M&A everywhere I looked. The problem seemed to be present with several other hierarchies.
Basically, her hierarchy/dimension names were not being presented to the user as expected. For example, in her SSAS DB she had a dimension named ‘Revenue Indicator’ and a user hierarchy named ‘Revenue Indicators’. In the Analytic grid, it looked like the word ‘Indicator’ was repeating… the hierarchy was being displayed as ‘Revenue Indicator Indicators’. This naming was a bit confusing, and a little unexpected, so I dug into it a little bit.
My first step was to check the Analytic Grid in question, as well as the dimension in SSAS. Not that I thought my coworker was lying to me, but I wanted to make sure that what was being displayed to the user was NOT what I expected to see. Nope, I was not being lied to and deceived… my faith in humanity can continue unabated. Some transformation was definitely going on between SSAS and PPS.
Next, I wanted to see how PPS retrieves the names of all the hierarchies and attributes to display to the user. I fired up Profiler, and captured a trace when I loaded up the Analytic Grid. I saw PPS using several Discover commands… so I fired off a Discover command based on what I saw in the trace. It looked something like this:
1: <Discover xmlns=“urn:schemas-microsoft-com:xml-analysis”>
2: <RequestType>MDSCHEMA_HIERARCHIES</RequestType>
3: <Restrictions />
4: <Properties>
5: <PropertyList>
6: <Catalog>MyCube</Catalog>
7: <Content>SchemaData</Content>
8: <Format>Tabular</Format>
9: </PropertyList>
10: </Properties>
11: </Discover>
That discover command gave me back the schema for the Cube. I took a look at the XML… here is the relevant section:
1: …
2: <row>
3: <CATALOG_NAME>MyCube</CATALOG_NAME>
4: <CUBE_NAME>My Cube</CUBE_NAME>
5: <DIMENSION_UNIQUE_NAME>[Revenue Indicator]</DIMENSION_UNIQUE_NAME>
6: <HIERARCHY_NAME>Revenue Indicators</HIERARCHY_NAME>
7: <HIERARCHY_UNIQUE_NAME>[Revenue Indicator].[Revenue Indicators]</HIERARCHY_UNIQUE_NAME>
8: <HIERARCHY_CAPTION>Revenue Indicators</HIERARCHY_CAPTION>
9: <DIMENSION_TYPE>3</DIMENSION_TYPE>
10: <HIERARCHY_CARDINALITY>26</HIERARCHY_CARDINALITY>
11: <DEFAULT_MEMBER>[Revenue Indicator].[Revenue Indicators].[All]</DEFAULT_MEMBER>
12: <ALL_MEMBER>[Revenue Indicator].[Revenue Indicators].[All]</ALL_MEMBER>
13: <DESCRIPTION />
14: <STRUCTURE>1</STRUCTURE>
15: <IS_VIRTUAL>false</IS_VIRTUAL>
16: <IS_READWRITE>false</IS_READWRITE>
17: <DIMENSION_UNIQUE_SETTINGS>1</DIMENSION_UNIQUE_SETTINGS>
18: <DIMENSION_IS_VISIBLE>true</DIMENSION_IS_VISIBLE>
19: <HIERARCHY_ORDINAL>1</HIERARCHY_ORDINAL>
20: <DIMENSION_IS_SHARED>true</DIMENSION_IS_SHARED>
21: <HIERARCHY_IS_VISIBLE>true</HIERARCHY_IS_VISIBLE>
22: <HIERARCHY_ORIGIN>1</HIERARCHY_ORIGIN>
23: <HIERARCHY_DISPLAY_FOLDER />
24: <GROUPING_BEHAVIOR>1</GROUPING_BEHAVIOR>
25: </row>
26: …
So, precisely what I would expect… but not what is coming out of PPS.
I then tried a little experiment… I added a few more hierarchies, to see how PPS would present them:
After deploying the changes, I saw the following hierarchies in my Analytic Grid:
| SSAS Hierarchy | PPS Name |
| [Revenue Indicator].[Revenue Indicators] | Revenue Indicator Indicators |
| [Revenue Indicator].[Revenue Indicator Types] | Revenue Indicator Types |
| [Revenue Indicator].[Types] | Revenue Indicator Types |
PPS is retrieving the Dimension name and Hierarchy name, then concatenating them together while removing any duplicated words from the Hierarchy name. I checked this behavior out in several places inside of PPS (not just in the Analytic Chart)… it appears to be common functionality.
This is actually pretty helpful. Most of the time when we create SSAS DB’s, they’re accessible using a variety of tools… PPS M&A for Dashboards, via Excel for power users, etc. The dimensions and hierarchies are rendered in different ways for each tool. Some will concatenate the Dimension name with the Hierarchy name, and some won’t. Some will give you a nice hierarchy, some you just get an ugly list. Naming your dimension appropriately will give you the most user friendly names in each of the tools… in this case, using ‘Revenue Indicator Types’ gives you a user friendly name in both Excel and in PPS, which is what we needed.
This is some pretty handy functionality, but I didn’t find it with a quick search of the ‘net and BOL (which doesn’t mean it’s not there). If you’re surfacing your SSAS DB through PPS, I would definitely take this into account when determining your naming conventions.
Cheers,
David
I’ve spent the past 15 months, off and on, working as the technical lead on a performance management project using PerformancePoint Server. The project was to create a SharePoint Portal where users could view the performance of a school system. The portal was initially internally facing, but the goal was to make it publicly accessible. My last project with this particular client was to implement an Internet facing version of the portal.
Since the school system in question has more than 120,000 students, scalability and performance was definitely an issue. I spent a week at the Microsoft Technology Center in Atlanta, GA testing and tuning the solution. We performed our testing in a lab with seven desktop machines (to test with) and three servers to simulate our production environment. I was joined for the week by one of the PPS M&A Architects, who helped me evaluate the solution. Everyone at the MTC was super helpful and friendly, and we got a lot of really good advice.
I want to share some of the things I learned during the performance testing of the solution.
A few good things to read before getting started on a venture like this (among all the other white papers about scaling SQL Server, SharePoint, and the like).
To performance test and tune our SharePoint site, we needed to…
Just five little items on the list… how hard can that be, right? Items #2 through #5 were done in iterations.
The application we created uses SharePoint Enterprise Server 2007 (MOSS), PerformancePoint Server Monitor & Analyze 2007 (SP1), and SQL Server 2005 (SP2 CU8). Both SQL Server RDBMS and SSAS reside on the same server. The RDBMS supports only SharePoint and PerformancePoint. Analysis Services is dedicated to the Dashboards.
The data source is a SQL Server Analysis Services DB. It uses a straightforward star schema design. All of the KPI’s that we’re using in the PPS Dashboards are surfaced using calculated measures in the cube. This is definitely a good way to go. This design makes developing the dashboards very easy, it encapsulates the logic of the KPIs, and it helps with efficient caching inside of SSAS. The cube was less than 1 GB in size for this phase of the project. Some default aggregations were built, and usage based aggregations were applied against the cube. Query performance was base lined at a few dozen milliseconds for the largest/most complex queries once the cache was warmed.
Our portal has seven dashboards. Each dashboard has several pages.
The Analytic Charts were all fairly straightforward, with a default view of a calculated measure against time. The users can drill into the charts.
The filters were primarily Member Selection, with at most a few dozen members. We have one MDX filter (for Schools), that returns about 400 members (this will come into play later).
The Dashboard was implemented using Application Security.
I enabled Anonymous Authentication for SharePoint. The site basically supports all of our Dashboards, as well as a number of Help files and some content to help people use the site and the data. I customized some of the master pages (to remove features such as SharePoint Help, Search, the breadcrumb trail, and stuff like that), but the site design was fairly trivial for this version of the site. Excel Services and other MOSS features were not used.
Our friendly neighborhood Microsoft rep arranged for us to have some time in the Microsoft Technology Center in Atlanta, GA. The provided an environment for us to test in, and they provided three servers (to mimic our production hardware) and seven desktop machines for us to run load tests on. It took a bit ~1.5 days to install/configure the software, install service packs, and deploy our solution (include a SharePoint site collection, PPS M&A Dashboards, and SSAS DB).
We tested our solution on the following hardware. Our production hardware was similar. A hardware network load balancing appliance was used for the web front ends.
Web Front End (1)
Web Front End (2)
SQL Server (RDBMS and SSAS)
We used Visual Studio 2008 (SP1) Team Systems for Testers (VSTT) to perform our testing. We used one machine as a Controller and four machines as Agents. We saved our test results to SQL Server on a separate machine.
Test Machines (x5)
This configuration let us scale to 4,000+ users without severely taxing any of the machines. Due to the network appliance being used for our load balancing, IP Spoofing was not required for our test machines. We had some issues with using Vista for the agents… it was just a little bit trickier to configure than XP. We were never able to get the counter collection working for those machines (annoying, but not really an issue since we had so much capacity and all the machines were in the same room). We didn’t run into any major issues getting our test rig up and running, but it definitely took some time.
In order to do our tuning and performance testing, we first had to create everything needed to create a load test. VSTT is a good tool for load testing, but be aware that there is a learning curve. If you don’t have any experience performing web based load testing, then this could be a significant hurdle. Luckily, in a previous life I was a Load Test Architect, and I had experience with the tool.
I first identified several use cases that I thought would be common for users of our portal. These consisted of actions such as viewing the top level summary Dashboards, using filters to change the view of the scorecards, clicking on analytic grids, and things like that. I created a mixture of coded and graphical Web Tests for each small work flow (such as changing a filter four times on a certain Dashboard, or clicking through eight charts on a Dashboard). I then used Web Tests that call other Web Tests to build up my use cases. The use cases were then combined in different ratios in each of my load tests so I could simulate a variety of user populations.
Designing your tests correctly is crucial. If you’re way off on what the users will be doing, all of your performance tuning could be for naught. I would recommend using a pilot group, or at least some test subjects, to figure out how people will use your portal.
Microsoft Consulting Services provided a test harness for PPS. The test harness is a coded web test that can parse the XML snippets used by PPS, and perform actions such as changing filter values, activating charts, etc. It’s a pretty cool tool, and was very helpful. Unfortunately, it is proprietary, so I can’t share it… you’ll have to get engage MCS if you want to use it. I did make some modifications to it to change the way it would use filters, to make it work when Web Tests called other Web Tests, etc. If anyone is using this test harness (or if it does become publicly available), I can share the (minor) modifications that I made.
I constructed all of the visual web tests using Fiddler 2 (in conjunction with a home grown helper application to insert comments, and do a few other useful tasks). Thanks to the MCS test harness, a few extra tools, and the way the web tests were constructed, the actual test generation was very straightforward.
One of the key elements to consider when performing a load test against PPS is that, due to the architecture, the process of loading a single page may involve dozens of calls. For example, a dashboard that has 15 filters, two scorecards, and two charts would actually make 20 http requests… so if each request takes 1 second, it takes 20 seconds to load the page. I was primarily interested in the time to last byte for each page, so I used comments while recording my tests to know where to place the transactions, so I could analyze those instead of individual calls.
I implemented reasonable timing and pacing for the individual steps in each of the tests, and made sure to gradually ramp up my users when applying the load. Testing was slightly weighted towards the Dashboards that were the largest and would have the heaviest usage, though another use case was used to randomly hit every part of the site to bust the cache if possible.
We tuned a few things, or at least reviewed the settings, out of the gate. During our testing we continuously monitored the servers (and test machines), identified bottlenecks, tweaked settings, then did it all again.
During our initial testing, we found SSAS to be the bottleneck for our solution. I suspect that our web front ends (SharePoint and/or IIS) could be tweaked a little more, but it wasn’t really necessary in our scenario.
We started tuning ASP.NET with some of the suggestions in the article Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications. In the end, I found the performance to be good using the autoConfig=”true” (the formulas listed in the article are automagically applied) with a few tweaks. I increased the number of threads available significantly… that was a major bottleneck for awhile. I also increased the minWorkThreads to 50 (otherwise SharePoint stalled after adding a few hundred users while spinning up more threads, even when ramping users up fairly slowly). I also increased the minFreeThreads and minLocalRequestFreeThreads. I increased the number of connections to the DB server. Don’t just blindly apply any of these settings… your mileage will vary. I went through a number of test iterations carefully monitoring each of the servers and testing these settings.
I made the following change to the machine.config (on all web front ends):
1: …
2: <system.web>
3: <processModel autoConfig=“true” maxWorkerThreads=“400” maxIoThreads=“400” minWorkerThreads=“50” />
4: <httpRuntime minFreeThreads=“352” minLocalRequestFreeThreads=“304” />
5: …
6: </system.web>
7: …
8: <system.net>
9: <connectionManagement>
10: <add address=“10.1.11.11” maxconnection=“48”/> ? Database server ip address
11: </connectionManagement>
12: </system.net>
13: …
14: </configuration>
I adjusted the application pool (for both the Performance Management site as well as the Central Administration page). Pinging and Rapid Failure were turned off on the Health tab. I did NOT use web gardens in this configuration, even though I have seen it recommended. I did not see a difference in performance between using them and not, and was advised by one of the local IIS gurus not to use them.
We updated SQL Server to Service Pack 2 – Cumulative Update 8 (build 3257). Before applying the CU, we ran into some significant performance issues. SSAS did not like some of our very small dimensions, and performance was severely degraded. The CU resolved the issues.
Data files, transaction logs, and the Temp DB were spread out over multiple disks. Our usage of the RDBMS was very light, so we needed minimal tuning here.
I updated the Query Max Threads element of Analysis Services to 20 to provide additional threads for querying. Adjusting this element needs to be done carefully, as it can improve the performance of the web front ends at the expense of maxing out SQL Server. I actually ramped this number up quite a bit during testing (with good effect), but found 20 to be adequate after resolving some other issues. I suggest monitoring the queued requests in IIS along with the queued and active threads in SSAS to determine a good balance here. I initially found a lot of queuing in the Long Parsing Jobs and Short Parsing Jobs as well, due to some filters.
OK, this is important. Since we Internet facing, we’re supporting anonymous users… a decent number of them, in fact. I updated the stored procedure [PPSMonitoring]. [dbo].[ParameterValuesCreate] to comment out a section that is not needed for an anonymous site, but that has an extremely negative impact on performance. This is the piece that stores the current filter selections. In addition to not being necessary, it was totally thrashing our transaction log.
I made the following change to the [PPSMonitoring]. [dbo].[ParameterValuesCreate] sproc:
1: — init
2: SET @TransactionIsOurs = 0
3: IF @@TRANCOUNT = 0
4: BEGIN — only if @@TRANCOUNT is 0, we do BEGIN TRAN
5: BEGIN TRANSACTION
6: SET @TransactionIsOurs = 1
7: END
8: — DD – 20080821 – Commented out the following section to increase performance
9: — –If this parameter value already exists (for this login), update. Otherwise, insert.
10: — IF(EXISTS(SELECT * FROM [ParameterValues] WHERE Login = @Login AND [ParameterUniqueName] = @ParameterUniqueName))
11: — BEGIN
12: — SELECT 1
13: — UPDATE [ParameterValues]
14: — SET
15: — [LastUpdated] = GETDATE(),
16: — [SerializedXml] = @SerializedXml
17: — WHERE [Login] = @Login AND [ParameterUniqueName] = @ParameterUniqueName
18: — IF @@ERROR <> 0
19: — BEGIN
20: — RAISERROR (5580001, 16, 1, @tErrMsg, 7, N’ParameterValues’) WITH LOG
21: — SET @ReturnCode = -1
22: — GOTO exit_label
23: — END
24: — END
25: — ELSE
26: — BEGIN
27: — –Insert record
28: — INSERT INTO [ParameterValues]
29: — ([Login], [ParameterUniqueName],[LastUpdated],[SerializedXml])
30: — VALUES
31: — (@Login, @ParameterUniqueName, GETDATE(), @SerializedXml)
32: — IF @@ERROR <> 0
33: — BEGIN
34: — RAISERROR (5580002, 16, 1, @tErrMsg, 8, N’ParameterValues’) WITH LOG
35: — SET @ReturnCode = -1
36: — GOTO exit_label
37: — END
38: — END
39:
40: IF @TransactionIsOurs = 1
41: BEGIN
42: COMMIT TRANSACTION
43: END
44: RETURN 0
There is a lot of tuning that can be done to SharePoint; tuning SharePoint was not a focus for us. We did perform a few changes.
Allowing the SharePoint Server worker process to consume large amounts of memory can decrease performance. For computers that have more than 4 GB of RAM, the ASP.NET cache size can be constrained with the privateBytesLimit attribute, set on the cache element of the Web.config file. By setting privateBytesLimit=”2576980378” (that is, 60% of 4 GB), you can avoid a scenario in which a server that has more than 4 GB of memory creates an oversized cache.
For a machine with 8 GB of RAM with a limit of 60% of the memory, we would add the following to the web.config. The private bytes limit number is calculated via the formula (<gigabytes of RAM available> * <percentage of RAM to use>* 1,024^3).
I made the following change to my web.config file for the SharePoint site:
1: …
2: <system.web>
3: …
4: <caching>
5: <cache privateBytesLimit = “5153960755” />
6: </caching>
7: …
8: </system.web>
9: …
Overall, I was expecting to be able to support about 500 concurrent users on each of the front end servers. I expected the WFE’s to be the bottleneck. With the original implementation of the Dashboard, I found we could support up to about 2,000 users… as long as they weren’t using our Comparison and Look Inside the Data pages.
When testing those pages, SSAS was getting slammed. I was able to support 1,000 users… but SSAS was at 80% utilization constantly, with occasional spikes and severe performance degradation. Not a really good situation.
Through testing and profiling, I identified the culprit… it was the School filter.
The School filter is an MDX filter, and it looks like this:
1: FILTER(
2: DESCENDANTS(
3: [Entity].[Entity]
4: ,[Entity].[Entity]
5: ,SELF_AND_BEFORE
6: )
7: ,[Entity].[Entity Type] = [Entity].[Entity Type].&[SCHOOL]
8: )
No big deal, right? Except… each time it is loaded (i.e., a lot) it fires off a few other MDX statements. They look like this:
1: SELECT
2: { [Entity].[Entity].[All]
3: ,[Entity].[Entity].&[School A]
4: ,[Entity].[Entity].&[School B]
5: //…about 400 more
6: } DIMENSION PROPERTIES MEMBER_TYPE on 0
7: FROM [MetricsDatamart]
8:
1: SELECT
2: {
3: IIF([Entity].[Entity].[All].Parent IS NULL,[Entity].[Entity].[All],[Entity].[Entity].[All].Parent)
4: ,IIF([Entity].[Entity].&[School A].Parent IS NULL,[Entity].[Entity].&[School A],[Entity].[Entity].&[School A].Parent)
5: // … about 400 more
6: } DIMENSION PROPERTIES MEMBER_TYPE on 0
7: FROM [MetricsDatamart]
8:
These are fairly long statements, and they are expensive to run. SSAS was having to queue dozens of these statements just to parse them when under load. They are fired for each page load, even though our data is static (i.e., no caching is occurring). All those inline IIF’s did horrible, terrible things to SSAS. SSAS was getting very backed up, which caused IIS to queue, which caused extremely long waits on the front end.
To fix the problem, I switched that filter to use a SQL Server RDBMS source. The data was static, so no big deal there. I did find that using more than 1 tabular source gave me an error in PPS… I wasn’t able to resolve that on our timeline, and I was able to fix the performance issue anyway.
After that one change, the performance of the whole system skyrocketed. With our heaviest test case, I was able to run 1,500 concurrent users. The WFE processor was at ~70% utilization, averaging 300 requests per second with no contention or queuing. The database server was at ~20 utilization, no issues. Responses were < 1 second, with an average response time of ~.3 seconds. User experience excellent. Even when the response times would increase, page load times were still reasonable (under 10 seconds for pages with more 15 objects).
We got everything pretty much humming for this phase of the project… but we’re building a much larger version for our client in the very near future. Here are some thoughts on making our solution bigger, faster, better.
We can tune SharePoint quite a bit to increase performance. This includes lightening some of the templates and base pages, optimizing images and web pages, and making sure all the user supplied content is fairly lean (i.e., not using a 300kb file produced by Word when a 20kb html file could be used). We can use some of the caching features available in MOSS to improve the performance on the web servers.
OK, I saw our filters as a bit of a bottleneck. For a large installation, I think performance could be significantly improved by building a custom filter using the Monitor SDK. Some of the key features would be enabling caching and perhaps using XMLA discover queries instead of some of the MDX. I’d also make the ordering of the elements a little more configurable, and perhaps try and implement a way to create a ‘global filter’ (I find I use a single filter on many different Dashboards… and I’d like to reduce the maintenance/development time/improve consistency.
Scaling out the web servers and scaling up the SQL Servers looks like a fairly effective strategy here. Coupled with some custom components and a well thought out design, this looks like an effective strategy with fairly predictable performance characteristics. We could easily double our capacity right now by snagging two extra WFEs. To scale by a factor of 10, we’d probably need an extra SQL Server and some minor changes to our strategy.
Our testing went well, and we were able to exceed the performance we were expecting. Here are a few key takeaways from this exercise.
Happy PerformancePointing…
David
The SSWUG Business Intelligence Virtual Conference is just two weeks off now. They’ve made a 10 minute preview of my session on SSIS configurations available here: http://www.vconferenceonline.com/speaker.asp?id=Jwelch, if you are interested in getting a sneak peak. There are a few other SSIS previews available:
Matthew Roche’s session on scripting in SSIS: http://www.vconferenceonline.com/speaker.asp?id=mroche
Matt Masson’s session on advanced Lookup scenarios: http://www.vconferenceonline.com/speaker.asp?id=mmasson
If you’d like a $10 discount on the conference fee (making it $90 – a bargain 🙂 ), you can use this code when you register – VCTAF167753-174.
At the Microsoft BI Conference, I did a chalk talk on creating custom components for SSIS. It seemed to go pretty well, as I got a lot of questions and interaction from the audience, which is the point of a chalk talk. As part of it, I demonstrated a component that can be used to perform a Merge (or any other batch oriented SQL statement) in the data flow. This is a pretty common request / complaint about SSIS, as evident from this post on Jamie’s blog.
There’s a pretty common pattern in SSIS for for performing updates from the data flow. You can use the OLE DB Command, but it processes data row by row, meaning that performance is not great. To get better performance, you can write the rows to be updated to a working table using an OLE DB Destination in the data flow, and then use an Execute SQL task in the control flow to perform a batch UPDATE against the true destination table. The same concept can be used with the new MERGE statement in SQL Server 2008, as shown in Using MERGE from SSIS. However, since by default SSIS will drop connections after each task completes, you can’t easily use a temporary table as the working table, so you have to create and clean up “permanent” tables, either in the control flow each time the package runs, or by just leaving them in the database.
Clearly, there are some drawbacks to this. You probably don’t want permanent tables in your database that are there only to support a back end process, and it would certainly be simpler to not have to create and delete the table in each package that needs to make use of them. To work around this, I created the Batch Destination component.
Basically, the component works by reading the metadata from the input columns in the data flow, and creating a working table in the target database. It then loads all the incoming rows to the working table. After all the incoming rows have been received and saved in the working table, it executes a SQL statement supplied by the developer. This SQL statement could be a MERGE statement, an UPDATE statement, or pretty much any other DML statement you’d like. After executing the SQL statement, it deletes the working table.
The user interface for the component is shown below. You provide an ADO.NET connection manager to a SQL Server database, a working table name (this can be a temp table, just use # in front of the name), and the SQL command to execute. On the Input Columns tab, you select the columns that you want to include in the working table.
There are a few limitations in this component. One, it only works with SQL Server through an ADO.NET connection manager currently. Two, it performs very little validation right now, so you can easily add a SQL command that is not actually valid, and you won’t find out till you run the component. Three, it’s written against the SQL Server 2008 API, so it won’t work in 2005.
I’m planning on making the source code available on CodePlex, but in the meantime, you can download a compiled version from my SkyDrive. To install it, you need to put the .DLL in the GAC, and copy it to your C:Program Files (x86)Microsoft SQL Server100DTSPipelineComponents directory. To add it to the toolbox in BIDS, right-click on the toolbox, select “Choose Items…”, select the SSIS Data Flow Items tab, and select the BatchDestination item in the list.
Last post on presentations for a while, I think / hope.
I’ll be presenting on Unit Testing in SSIS at the PASS Summit 2008, occurring in Seattle, WA from Nov. 18-21. There’s lots of great content planned at PASS this year, and it’s definitely worth attending. If you are there, drop by the session and say hello.
