The SharePoint community have a number of useful tools that can aide you in your performance testing of MOSS. The tool that comes to mind is the SharePoint 2007 Test Data Population Tool, this tool can bulk load data into SharePoint. If you click on the Releases tab you will see a release: MOSS Performance Load Tests. This is a series of web tests that can be loaded up into visual studio team system: 
The visual studio load testing features can simulate multiple users over a period of time all running a defined test mix. In the above image the homepage is hit 9% of the time, whereas the general PageView test which is a broad selection of pages makes up 28% of the test mix. Your test mix will depend on how you perceive your users using the site. Visual studio has a number of options that you can tweak such as: - Browser mix – provides a way to simulate multiple browser types i.e. mobile devices, firefox, IE etc ..
- Network mix – your test network might not be the same as production, this allows you to test with network limitations in place
- Load pattern – Constant, Step or Goal based, depending on what your testing, you could hammer your server with a constant load, or you could build up in a controlled manner.
- Warm up time – You can warm the server up to avoid the initial compile times from impacting your results.
In the example above I’m using the test mix from the Microsoft document: Estimate performance and capacity requirements for portal collaboration environments, you can find other documentation for different portal types here.
MOSS 2007 has the option to use a dedicated web front end server for crawling content: 
Why would you want to do this: Advantages: - Search doesn’t compete with the end users – Large environments that need to crawl constantly can cause more traffic than normal user load, you don’t really want your users to experience slow pages just because your doing an index? By using a dedicated web front end that isn’t part of the load balanced cluster, your indexing won’t impact your users as much (I say as much, because you still need to think about the impacts of the database server).
- Easy to move the WFE into the load balanced cluster – It’s a rather crude disaster recovery method, but it’s not that hard to move this box into the load balanced cluster if you really need the extra capacity or if one of your other servers fail. After all it’s just a normal web front end, but one that is reserved for the indexer.
- Perfect place to run a backup central admin – You should always try to have more than one server running central admin (on a large farm anyway), that way if your main central admin server goes down, you still have a way to manage the farm.
Disadvantages: - More hardware – The obvious disadvantage to having an extra machine is the requirement of more hardware, which also means:
- More cost – New hardware is an additional cost, but now that you have an idea of the advantages it brings, you can make a more informed decision.
Joel has some other tips such as adding a robots.txt to servers that you don’t wish to participate in the indexing process.
The next integration method that I want to discuss is the collection of data. As a web developer you’ve no doubt been asked to create a form that does X a number of times, you might even have created some tools to aide in this, it’s pretty common. So now that you’ve moved across to the dark side of MOSS development we need to break your thinking, if you want to create a form, first have a look at Microsoft InfoPath, InfoPath files can be published to MOSS running the InfoPath Forms Service. The benefits to this approach are: - Less development – I won’t go as far to say that even the worst coder on your team could use this tool, that guy can’t do anything, but for simple stuff it’s not too hard to get your head around.
- Central management of forms – You can easily keep track of your forms, how many times have you written a form that has already been developed? But seriously because each form is a content type, you can manage the metadata of a form from a single location, regardless of how many libraries you’ve added the content type to.
- Can easily use existing MOSS features - This is the biggest feature, you can easily add workflow capabilities or publish your results to a list, I bet most of your forms currently just send an email and get written to a database.
The disadvantages are: - It requires a different way of thinking - This might not be a bad thing, but some large organisations have teams of programmers who spend 90% of their time doing some sort of forms based programming. It might be a hard sell for these guys.
- Anonymous access might cause some issues – I’ve seen a few issues around anonymous access to forms, it’s by no means a show stopper, but you should think about this before you deploy.
I think the benefits far out weigh the disadvantages, in any case hopefully the next time you hear a developer say they’ll create a web part for a form, you’ll think about it a little more carefully.
I previously posted about a simple integration pattern that used the Page Viewer web part. The approach I’m going to discuss today again does not involve any custom coding, but will have a huge impact on your end users. If your goal is to make your corporate data more available this is an easy option. I’ve posted about this diagram before:  This is the Business Data Catalog (BDC). It can source data from either a database or a web service, once you have built an Application Definition File (the only development work needed), your data can then reach custom lists, profile information, search and custom solutions. The benefits to this approach are: - Reach – You’d be hard pressed to develop a feature that has more end user impact. Firstly your data can be searched, secondly your data can now be used in ways that couldn’t be foreseen. This might be a scary prospect for a lot of organisations, but this will change over time, I plan to discuss this further in another post.
- Searchability – The younger generations have grown up with the web and expect to be able to do everything via search, you’ll probably find that your search engine is the most popular MOSS feature, why not plug more data into it?
- Fits with a SOA – Yes, it’s buzzword compliant, don’t forget that the BDC in MOSS can call web services, so if your organisation has a Service Oriented Architecture, this will likely be an easy sell.
The disadvantages are: - Doesn’t work well for complex data – It really only works well if your data is simple, for example if your trying to expose a product list or the locations of your stores.
- Read Only Data – Indexing and Searching are read only operations, as simple as that. If you want your users to rate your data or tag it, then your going to need a different strategy.
I’ve been doing some thinking around how MOSS can be integrated into a large and complex organisation, an organisation that has many disparate applications which act as an information silo. Most developers who are not intimately familar with MOSS will suggestion just using the page viewer web part if the external system is web based. The page viewer web part is basically an IFrame, so MOSS is in effect a window to the external application. The benefits to this approach are: - Low Cost – The external system has already been developed, so it’s not going to cost you anything significant in terms of developer hours. This is assuming that no technical hurdles exist in simply referencing the application via a page viewer. I’ll discuss the authentication issues in the disadvantages section.
- Quick – Its quick and easy to do, if you plan to redevelop your system to be MOSS aware, this is a good interim measure.
The disadvantages are: - Systems remain isolated – You still have to maintain that existing system, this might be OK but, it’s likely to be mature and stable.
- The information is still in a silo – This continues from the last point,MOSS isn’t taking full advantage of the system, you can’t personalise the information from the system, you can’t drop a filter web part on the page and get the exact data your looking for. Sure you might be able to crawl the external site and provide it via the Search Centre, but can your users build a custom list and use this information in a way that makes sense to them?
- Authentication – How is your authentication handled, MOSS is just providing a window to the external application, your external system has to do all the heavy lifting in terms of authentication and authentication.
- Inconsistent User Experience – Your external system probably has its own navigation, style and theme that probably isn’t the same as the MOSS implementation that your trying to sell to your users. It has gives off this feeling that its all held together by sticky tape.
I think this approach is fine if you fully understand what your doing, I plan on discussing some of the other approaches in some upcoming posts.
I’ve previously posted a demo that made use of a tag suggestion web part, as you type the web part will make an ajax call which will return the tags that match the current input. The user can click on the suggestion tag and it will populate the textbox, multiple tags can be entered into the textbox. 
The most interesting part of this web part is the server side call, which I’ve implemented as a HttpHandler in the Tags.ashx file: public class Handler : IHttpHandler {
public void ProcessRequest(HttpContext context)
{
context.Response.ContentType = "text";
I’ve made use of the System.Web.Extensions JavaScriptSerializer to render the string array of tags to JSON:
1: List<string> tagList = new List<string>(); 2: 3: //add all the tags to a collection, JSON serialize the list 4: 5: System.Web.Script.Serialization.JavaScriptSerializer serializer = new System.Web.Script.Serialization.JavaScriptSerializer(); 6: 7: context.Response.Write(serializer.Serialize(tagList.ToArray())); 8:
I’ve put this handler in the /_vti_bin/ directory of SharePoint which maps to the ISAPI folder under the 12 hive.
I’ve used the same code to generate the tags as I did with the tag cloud web part, so once again the generation of these tags won’t scale to large lists, this is just an example of how to implement a JQuery based Tag Suggestion web part.
The source code for this web part can be found here.
Just a quick tip, if your crawling external sources with the MOSS (or Enterprise Search), you might find that your crawl doesn’t finish or hangs, it might be worthwhile checking to see if the site you are crawling has a calendar with links: 
You will need to determine the URL and then add a crawl rule to exclude that path, the crawler will see an infinite number of pages (it thinks each date and next link is a separate page).
|