Have you built a DotNetNuke site and now want to move DNN to production? Or, are you simply moving a DotNetNuke website from one server to some other server? Over the last month I have seen several searches in the logs from people trying to find instructions on moving a DotNetNuke website from development to production, or simply from one server to another. After looking around for similar detailed instructions, I really did not see anything out there that really explained how to setup a IIS box for DotNetNuke, optimized and ready for production. So, I decided to provide instructions on how we do it…

The following instructions are provided to minimize any downtime of the production domain/website, assuming there is an existing website running. However, the same instructions can be applied for a brand new domain/website that does not have a critical execution plan. These instructions will have a basic assumption that you understand how to manage IIS, DNS, and DNN. While we do not provide any guarantees to your particular setup, the following has worked well for us, managing the release of many DotNetNuke websites from our development environment to our production environment, while allowing continued development during the process.

DNS and Subdomains

First, we need to create subdomains. For this example, we will use dev.domain.com and prod.domain.com. Assuming the development environment you are currently working on is using just localhost, adding a subdomain for dev.domain.com may not be neccessary, but provides an easy way to work with multiple domains and projects. Point DNS for dev subdomain to the IP address of your development box and point the prod subdomain to your production box IP. Leave, www.domain.com pointing to where ever you have it pointing currently, but turn your TTLs down to 5 seconds. If this is a new website, you may already be pointing www.domain.com to your dev box, you can leave it there for now. For those who do not know what DNS is, see How Stuff Works.

We use the service of DNS Made Easy. Hands down, this is the best business decision we have made concerning management of DNS. While their site is unfortunately not a DNN site, it provides the interface to get the job done quickly and easily. We use their Business Membership plan that allows us to turn down our domain TTLs to 5 seconds. They offer 100% uptime and have servers globally to handle DNS request. They also provide services for MX backup (your domain will still receive emails, even if your email server is down) and site monitoring (pings your site to ensure it is up, sends notification if down). We have never had a problem, they have excellent support, and great prices for their services.

Once you have the new subdomains created, make sure they are working by pinging from the server(s) or use something like DNS Stuff. If you cannot ping, make sure your firewall is setup correctly to accept and route HTTP traffic to the correct server.

If it’s working, then you are ready for the next step…

The Development DNN Installation

Login as Host and go to Host > Portals > Edit Portal > Portal Aliases > Add New HTTP Alias

Add the following aliases, assuming localhost is the only one created:

1.      domain.com

2.      www.domain.com

3.      dev.domain.com

4.      prod.domain.com

Copy the entire DNN folder on development box to the location on your production box where DNN will reside.

SQL Server Database on Development and Production

Go into Enterprise Manager or SQL Server Management Studio, development database server, and find your DotNetNuke database. Right click and go to Tasks > Detach. Clear the connections if you have to. Once the database has been successfully detached, go to the folder where the database files live (.mdf and .ldf files) and make a copy of your DotNetNuke database and transaction log. If you simply made a copy of the file in the same folder, you can now reattach the database (Tasks > Attach) so development can continue if other developers are working on your project, minimizing development downtime, plus have a backup of development database in case of unexpected issues. If you have a very small database, it may not be an issue just to copy and paste the files to the production server, assuming you are on the same network. However, our “development DNN database” is almost 3 Gb and takes a minute to move over to our production box. So, however you decide to do it, copy the .mdf and .ldf file to production database server. Rename them if necessary and Attach the database similar to the way you detached. Refresh database view if necessary and ensure the database is accessible. If you want to create a custom SQL Server login on production for security reasons, now is the time to do it.

IIS on Production Box

Create a new website in IIS. Map the website to the DNN folder you created on Prod. For the initial host header, use prod.domain.com.

**Note** DNN Documentation show creating Virtual Directories. We have had great success with configuring and managing DNN websites as actual websites, instead of virtual directories and would recommend this route for anyone who is planning on running this in a production environment to reap the benefits of IIS, especially IIS 6 and performance as discussed further down…

If this site is NOT replacing an existing and running domain/website, go ahead and add domain.com and www.domain.com host headers from Website Properties > Web Site Tab > Web site identification > Advanced Button. If you use internal IP addresses (Firewall routes the HTTP traffic), make sure you have the right IP addresses and port specified. By default HTTP traffic runs on port 80.

If this is a DNN 4 install, make sure you change ASP.Net version to 2.0 from the ASP.NET tab in Web site propoerties.

For performance enhancements, and as a necessity if you are running both ASP.NET 1.1 AND ASP.NET 2.0 websites, create a new application pool for the website and a web garden as described in the following entry on IIS 6 Horticulture.

Production DNN folder

Within Windows Explorer, go to your production DNN folder, right-click and select Properties > Security and make sure Network Service has the proper permissions. Now, modify the web.config’s database connection string(s) (2 of them for DNN 4) to the production database server and production database. If you created new SQL Server accounts for access, you will want to update the id and pass as well.

Testing it out…

First, open up a command prompt and make sure you can ping prod.domain.com and dev.domain.com. You should get the production IP address for prod.domain.com and the development server IP address for dev.domain.com. Now try to navigate to prod.domain.com in a web browser. If you get a successful page load, you now can do your testing to ensure everything is there and working. Since you created a subdomain for dev.domain.com, you can do your development as needed, test, and when ready, move to production. Periodic replication of the database from Production to Development allows you to keep a development environment that closely resembles your production environment. If you have tested everything and are sure the prod.domain.com is working correctly, you are ready to go live…

Going Live with DotNetNuke 4

Okay, so you have tested and are confident that the site is ready for primetime. First, go ahead and change your DNS settings to point domain.com traffic to the production server IP address. With IIS Manager open, stop the old website if one was running and add www.domain.com and domain.com to the host headers to the new website if necessary. Try www.domain.com and it should work. You now have a live DNN site. Assuming all went well, you can turn your TTLs back up in DNS for better caching.

Updates to this post

I hope you have found this useful. If you have any suggestions, please write a comment and share your experiences. I will try to keep this entry updated if I come across any other tips or updates and eventually may even get around to adding some pictures for futher help. Stay tuned!

We had to create a DotNetNuke module that would enforce that the user agrees to the Terms and Conditions of the website before being able to login, to satisfy a legal and SEC requirement for a financial company's client portoflio access. The module has been in use on the site for over 9 months now and we recently upgraded it to support DotNetNuke 4.x.

The Venexus SignIn module is free for download. As a "filecasting" test, I will be including the DNN 4 version of this module as an enclosure to this entry. It will be interesting to see how RSS/ATOM news readers interpret the enclosure. More on this later... To download the DNN 3 or 4 version, if you are not reading this by a news reader, create an account on the Venexus website and go here. Registered users will be able to download.

To use the module, backup your DNN installation and install as you would any other module. Drop the Venexus SignIn module on a page and go to the Settings. You can specify your custom, or existing Terms of Use page within Edit Terms and Conditions Settings.

Currently the sourcecode is not available until we have time to write some comments. If you have any suggestions for future releases feel free to comment here and we might get around to adding them

I noticed something new that I have not seen in previous versions of DotNetNuke...both, web.config and siteurls.config are backed up to the Config directory. With each change, a folder labeled "Backup_YYYYMMDDTT" is created and a copy of the original files are placed within. I am assuming this is the cached version that gets backed up during the application restart. I have always been careful and made a copy of the web.config file before making the change, but it is nice to know that there is another copy stored in the Config folder just in case. If anyone has any information about how this process works, I would be interested in knowing more details. Please share!

A lot of DotNetNuke developers/webmasters forget the importance of traffic derived from their blogs or RSS feeds. Any seach engine optimization plan should include submitting links to  popular blog/news feed directories.

For those who are unaware, you can enable syndication within several DotNetNuke modules. For example, in the Text/HTML module Settings > Page Settings > Basic Settings is Allow Syndicate checkbox. If this is enabled, a XML icon will appear on the rendered page.

There are also many DotNetNuke modules that provide RSS feeds for syndication. A couple of my favorite modules are Orizonti's NukeNews and Scott Schecter's NukeSyndicate. Both of these modules provide a RSS feed for consumption. NukeSyndicate allow for posting audio and video files, know as podcast and vodcast...more on this later

Recently I spent a few hours submitting this blog to many directories. Most of the links below do not require reciprocal links, but in order to satisfy those who do and to provide a resource for others, here is the list I submitted our RSS feed to:

Blogs for Small Businesses Chordata Complete RSS Easy RSS Every Feed Feed-Directory Feeds Farm Feedster Feedzie Findory

Fyber Search GoBig Network IceRocket Jordo Media News XS Newzfire Nooked Plazoo PubSub Press Radar  Read A Blog Redtram RSS Feeds RSS Network Yahoo! RSS

If you have any other suggestions, please do tell! Check back for updates....

I ran into an issue with a DNN site we are developing in DotNetNuke 4 and the ability to install modules from Host > Module Definitions > Add New Module. After selecting the module and clicking Upload, I was immediately redirected to the Module List page, without installing the module. The weird part was that it did not cause an issue with all of the modules I was uploading, only a few of them. Without turning debugging on, and finding the true root of the problem, I simply did the following:

1. Dropped the modules I wanted to install into the \Install\Module directory.
2. In a browser, navigate to http://www.domain.com/install/install.aspx?mode=installresources

DotNetNuke will then install the module and you are able to continue with your development. Yay!

Most likely you are reading this because you are frantically trying to figure out how to login into your DotNetNuke portal because you have found yourself locked out. You may have even received a password reminder with a blank password. Having fun yet???

When we were first testing DotNetNuke in the DNN 3 beta days, we had a problem with not being able to login into the host account. I fixed the issue by overwritting the host Password and PasswordSalt fields in aspnet_Membership table. Recently, the same issue arose and I had to do this again. So, I decided to jot down a few notes that I hpe will help you in solving your issue. Read on....

Before I explain, lets check to make sure it is not one of the other issues related to not being able to login.

1. Clear your cache and cookies and retry to login
2. Did you recently upgrade your DotNetNuke site or change the web.config? If so, the passwords are encrypted and stored in the membership provider tables using the machine validation and decryption key strings. They are located in the web.config below the server connection string. You can now thank <insert favorite God> you backed up the DNN installation before upgrading, because you can go back to the old web.config and use the machine keys to upgrade your new web.config file. Look for something like this:
                        
     <add key="MachineValidationKey" value="extremelylongrandomlookingstringofcharacterswouldgoinhere" />
     <add key="MachineDecryptionKey" value="anothersetofextremelylongrandomlookingstringofcharacterswouldgoinhere" />
3. Did you accidentally change the Login page in Admin > Site Settings > Advanced Settings? You can do the following: **NOTE** Make sure you change your PortalID appropriately.                         
   From SQL Server Management Studio or Enterprise Manager, run the following statement:                     
                     
   SELECT TabID, TabName FROM Tabs WHERE (TabName LIKE '%Login%') AND (PortalID = '0')

          Find the Tab?
        If you get a result, and are sure it is the Login page, run the following SQL Statement to update your settings:
          **NOTE** Make sure you have the correct  TabID and PortalID!
          
        Update Portals Set LoginTabID = '123' WHERE (PortalID = '0')
                    
        You should now be directed to the login page of your portal....

          Didn't Find the Tab?
        If you did not get a result to the first query and deleted the Login page, you are screwed...just kidding. John Mitchell's Blog         provides the solution.

None of those work for you? Join the club!

The solution:
Assuming you have more than one account for your portal (some lowly user account will do), run the following SQL:

SELECT     aspnet_Users.UserName, aspnet_Membership.Password, aspnet_Membership.PasswordSalt
FROM         aspnet_Membership INNER JOIN aspnet_Users ON aspnet_Membership.UserId = aspnet_Users.UserId
WHERE     (aspnet_Users.UserName = 'host') OR (aspnet_Users.UserName = 'someusername')


You should now be able to see the Password and PasswordSalt row you need to use to replace your host account Password and PasswordSalt.

UPDATE    aspnet_Membership
SET         Password = 'someusernameencryptedpasswordstring', PasswordSalt = 'someusernameencryptedpasswordsaltstring'
WHERE     UserID = 'youraspnetuseridforhost'

Now, go to the login page and request your password reminder. You should now have the information you need to login into your portal.

Hope that helps!

UPDATE 3/12/2006:

It may be neccessary to change the ApplicationID to match the portal in use.

Working from IIS 4 days to IIS 5 was a huge improvement, but I am constantly amazed with the new IIS 6. There are so many goodies I keep finding that were not in IIS 5 that help with administration and performance. The latest one I discovered a couple of weeks ago and have been playing with is Web Gardens. I'm not talking about web farms here, but the horticulture of worker processes. From my testing, I conclude a little web gardening in IIS will definitely help DotNetNuke performance. So, the nest time your DotNetNuke website is getting pounded with traffic and you start seeing delays in page load time, a few extra worker processes can handle the extra load...read on

Too help with performance, each domain should be in its own Application pool within IIS.

"IIS versions earlier than 6.0 use the ASP.NET process model (Aspnet_wp.exe). Under the ASP.NET process model, each unique application version automatically runs in a separate process at run time. All applications that target the same version of the runtime share the same process (or processes in Web garden mode). However, IIS 6.0 uses the IIS 6.0 process model (w3wp.exe) and introduces a new isolation feature called application pooling. Application pooling allows applications to run together in one or more processes, as long as they share the same pool designation. Applications that are assigned different application pools never run in the same process." - MSDN

To create a pool designation in IIS 6.0

1. Open the IIS management console and expand the local computer by clicking the plus sign.
2. Right-click the Application Pools folder, point to New, and then click Application Pool. The Add New Application Pool dialog box appears.
3. Enter the new pool designation in the Application pool text box, and then click OK.

To assign a pool designation to an ASP.NET application in IIS 6.0

1. Open the IIS management console, expand the local computer by clicking the plus sign, and navigate to the folder that contains the ASP.NET application.
2. Right-click the application and then click Properties. The application's properties dialog box appears.
3. On the Directory tab, select the desired pool designation from the Application Pool list.

Since IIS is running in worker process isolation mode, Web gardens become an option.

"In IIS 6.0 worker process isolation mode, application pools enhance Web site or application reliability by isolating applications and the worker processes that service those applications. For even greater reliability, you can configure an application pool to be supported by multiple worker processes. An application pool that uses more than one worker process is called a Web garden. The worker processes in a Web garden share the requests that arrive for that particular application pool. If a worker process fails, another worker process can continue to process requests." - MSDN

To configure a Web garden by using IIS Manager

1. In IIS Manager, expand the local computer, expand Application Pools, right-click the application pool, and then click Properties.
2. Click the Performance tab, and under Web garden, in the Maximum number of worker processes box, type the number of worker processes that you want to assign to the application pool. (You must type a number greater than 1 for the application pool to become a Web garden.
3. Click OK.

How does this help for performance?

First and foremost, under heavy load (web traffic), a worker process can get tied up with a request. If this happens, there is another worker process available to take the load. Utilizing this has definitely helped during peak traffic times. Also, when traffic is steady, each new connection is passed to a different worker process in the Web Garden, in a round-robin scheme. This smooths out the load, instead of  fighting for resources bound to a worker process.

All for now...I have a garden to tend.

The GetSchedule() timeout error:

Error: Schedule is currently unavailable.
DotNetNuke.Services.Exceptions.ModuleLoadException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlDataReader.ConsumeMetaData() at System.Data.SqlClient.SqlDataReader.get_MetaData() at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method) at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(SqlConnection connection, SqlTransaction transaction, CommandType commandType, String commandText, SqlParameter[] commandParameters, SqlConnectionOwnership connectionOwnership) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(String connectionString, CommandType commandType, String commandText, SqlParameter[] commandParameters) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(String connectionString, String spName, Object[] parameterValues) at DotNetNuke.Services.Scheduling.DNNScheduling.SqlDataProvider.GetSchedule() at DotNetNuke.Services.Scheduling.DNNScheduling.SchedulingController.GetSchedule() at DotNetNuke.Services.Scheduling.DNNScheduling.DNNScheduler.GetSchedule() at DotNetNuke.Modules.Admin.Scheduling.ViewSchedule.Page_Load(Object sender, EventArgs e) --- End of inner exception stack trace ---

The temporary fix:

Cleaning out the ScheduleHistory table fixes the problem until it gets too full again...

Delete From ScheduleHistory where ScheduleHistoryID > 1

Make sure you backup your database before executing this SQL statement.

I need to investigate more on how the code for GetSchedule() works and how to cleanup the ScheduleHistory more often. Also, we are working with Microsoft on a different issue, they have voiced concern on the performance of the stored proc GetSchedule. I will post any suggestion here when they surface.

 

Working on the DNN FIND project, I thought I would kick around a few ideas about building "importance" into a URL based on user interaction. In a old pre-DNN project, I simply had a page that processed the link click similar to the way DNN Links Module works by using LinkClick.aspx and parameters for the link information, before redirecting to the site. However, I would prefer a solution that went directly to the site, so that the Back button could be used (pressing Back would go back to the redirect page that sends you forward). Plus, I wanted something that would show the real URL in the window status, without setting it using JavaScript. So, this is what I came up with...

The following script is dynamically generated on the Search Results page to include the searchID (every unique search performed against the database has an ID):

<script>
<!--
function DNNFclk(urlID,curRank){
 if(document.images){
  var u="";
  if (urlID) u="url="+u+"&searchID=123456"+"&rank="+curRank;
  new Image().src="/DNNFindClick.aspx?"+u;}return true;}
//-->
</script>

The HTML for the link in the search results looks like this:
<a href="http://www.venexus.com" onmousedown="return DNNFclk('7890','1')">Venexus</a>

How does it work?

When a user clicks a link in the search results, it fires off a JavaScript to fetch an "image", passing in the ID for the url and search results rank. This "image" is really a page that collects the information from the user. On the page that processes the click, basically the curRank and searchID is used in the algorithm that computes the new URL importance. This allows us to track what the user clicks on in order to update the URL ranking.

I have not had the chance to add this to DNN FIND yet, but it should be a great improvement.

Ideas for DNN FIND:

By also tracking the user session, we could check the timeframe from one click to the next. If the timeframes are too close, we could DECREASE the rank. Close timeframes represent bad search results because the user did not spend any time on the site for the link they clicked.

While working with Microsoft concerning the DNN SQLDataProvider and 64-Bit SQL Server 2005 Issue, it was suggested that there was a performance issue with GetTab. While this does not help the issue we are having, it did help with performance...

"There are some implicit converts happening even though you have explicit converts in the statements"

Current GetTab SQL:

select TabID,
TabOrder,
Tabs.PortalID,
TabName,
IsVisible,
ParentId,
[Level],
DisableLink,
Title,
Description,
KeyWords,
IsDeleted,
'Url'= case when F2.FileName is null then Tabs.Url else F2.Folder + F2.FileName end,
SkinSrc,
ContainerSrc,
TabPath,
StartDate,
EndDate,
'IconFile' = case when Files.FileName is null then Tabs.IconFile else Files.Folder + Files.FileName end,
'HasChildren' = case when exists (select 1 from Tabs T2 where T2.ParentId = Tabs.TabId) then 'true' else 'false' end,
RefreshInterval,
PageHeadText
from   Tabs
left outer join Files on Tabs.IconFile = 'fileid=' + convert(varchar,Files.FileID)
left outer join Files F2 on Tabs.Url = 'fileid=' + convert(varchar,F2.FileID)
where  TabId = @TabId

 

The FIX:

select TabID,
TabOrder,
Tabs.PortalID,
TabName,
IsVisible,
ParentId,
[Level],
DisableLink,
Title,
Description,
KeyWords,
IsDeleted,
'Url'= case when Files.FileName is null then Tabs.Url else files.Folder + Files.FileName end,
SkinSrc,
ContainerSrc,
TabPath,
StartDate,
EndDate,
'IconFile' = case when Files.FileName is null then Tabs.IconFile else Files.Folder + Files.FileName end,
'HasChildren' = case when exists (select 1 from Tabs T2 where T2.ParentId = Tabs.TabId) then 'true' else 'false' end,
RefreshInterval,
PageHeadText
from   Tabs
left outer join Files on Tabs.IconFile = 'fileid=' + convert(nvarchar,Files.FileID)
and Tabs.Url = 'fileid=' + convert(nvarchar,Files.FileID)
where  TabId = @TabId

Running SQLDiag.exe confirmed the modification helped improve performance. More details later...

I'll post this to the DNN Bug Tracker shortly...

Update 1/25/2006:

Now in Bug Tracker: 2404

I made the following post on the DNN Forums, and decided to post it here in case someone reads it here first...

This is all related to: Upgrading DNN from local SQL Server 2000 to Remote SQL Server 2005

We are experiencing an issue with DNN and a 64-Bit SQL Server 2005 database server that seems to be related to the SQLDataProvider. We are currently running a production web server (Server A) that has an instance of SQL Server 2000 running locally. We have a mixture of DNN3 and NON-DNN sites running on Server A. All DNN sites are fast and run smoothly, only experiencing a few issues during peak traffic times regarding the local SQL Server 2000. Previously we had a separate server for our production SQL Server 2000 databases. However, we recently acquired a very fast 64-Bit server that came from Overture.com (Server C) and had to make room in our rack by decommissioning the old database server after moving all databases to Server A. Now, we are in the process of moving all Server A databases to Server C , so we can go back to using Server A as web server only. We have been testing and planning our database move utilizing our development server (Server B).  Our goal is to move ALL Server A databases to Server C.

Server A:
Dell 2850
Dual 3 Ghz Xeons
2 Gb RAM
32-Bit
Windows 2003 Standard Edition
SQL Server 2000

Server B:
Dell 1550
Dual 1 Ghz Pentiums
2 Gb RAM
32-Bit
Windows 2003 Enterprise Edition
SQL Server 2000 Standard Instance
SQL Server 2005 Enterprise Instance

Server C:
Dell 7150
Quad Itanium Processors
12 Gb RAM
64-Bit Windows 2003 Enterprise Edition
64-Bit SQL Server 2005 Enterprise Edition

We began testing the NON-DNN site and DNN site databases against Server B, all with success. We also setup DNN instances on Server B that used Server C as database server. Testing was successful, but all DNN databases tested were less than 100 Mb. We noticed that the DNN sites on Server B that talked to Server C DNN databases were slower, but dismissed it as being on the slower Server B when compared to Server A.

So, after much testing for NON-DNN sites, we moved all NON-DNN databases to Server C. All NON-DNN sites use the SQLOLEDB Provider. Our largest NON-DNN database is over 3.5 Gb. After the move, the site with the largest database experienced great performance/speed improvements. Some larger data transactions were executed in almost half of the time. We were very pleased with the results.

After successful NON-DNN databases move from Server A to Server C, we began moving the DNN databases to Server C.  The first 3 were very small databases. However, the largest of the 3, we noticed a difference in speed. Concerned, but determined to move on, we moved a 2.5 Gb DNN database to Server C and gave it a try... The speed was horrible taking as much as 15-45 seconds to deliver a page. We quickly backed out of the upgrade and began our investigation…

Doing a little research, I dug into the DNN documentation for Data Access and looked at the code to see DNN uses System.Data.SQLClient as the provider. Why would SQLOLEDB be fast and the DNN SQLDataProvider be so dreadfully slow and only when on a 64-Bit server? I really have no desire to change any of the core DNN code to use the System.Data.OleDb as the provider to test and see if there is a difference, so any recommedations and/or suggestions are appreciated. 

I know there are a few issues with 64-Bit SQL Server 2005 tools running slow: You may experience slow performance when you run 32-bit SQL Server tools on 64-bit operating systems. But, this should not be related to the issue since this concerns just the tools, or does it?

I plan on burning a support call to Microsoft, but would like to gain any insight others might have before I make the call.

After working with different http components from my ASP/COM/VB days , I was pleased to find the .Net classes for web request and response in the System.Net namespace. There are lots of goodies in both that would have required lots of extra code in the past, especially for parsing out header responses.

HttpWebResponse Class
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemnethttpwebresponseclasstopic.asp

HttpWebRequest Class
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemnethttpwebresponseclasstopic.asp

Here is a few snippets of code I pulled out of the DNN FIND Spider to show some of the basics of both classes with comments and ideas for those who may try to use this:

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

'Create the web request object and pass in a URL to process
Dim webReq As HttpWebRequest = HttpWebRequest.Create(sURLToProcess)

'You can specify your own useragent using the UserAgent property
webReq.UserAgent = g_sUserAgent

'Create the web response object by retrieving the web request response
Dim webResponse As HttpWebResponse = webReq.GetResponse

'Check to make sure we get a 200 status response
If webResponse.StatusCode = HttpStatusCode.OK Then
 'We can grab the content type of the document
 sContentType = webResponse.ContentType.ToString()
 'We can check the size of the document
 lContentLength = webResponse.ContentLength
 'We now know what type of document this is, we could add code to
 'decide what we want to parse or save the data  

'We can stream the data (requires System.IO).
 Dim receiveStream As Stream = webResponse.GetResponseStream()
 'Using the stream instance, we could pipes the response stream to a
 'higher level stream reader with the required encoding format
 Dim encode As Encoding = System.Text.Encoding.GetEncoding("utf-8")
 Dim readStream As New StreamReader(receiveStream, encode)

'From here we can save or parse the data as needed...

Else
'If we did not get a 200 status, we could process the status response and
'return a friendly error message, or just ignore the document
End IF

' Release the resources of the response.
webResponse.Close()

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

**PLEASE NOTE** - The above code is just a few snippets of the Spider class for DNN FIND Spider that I jotted down from memory. Make sure you declare your variables as the above is provided just to give you ideas for utilizing and understanding HTTP Web Request and Response classes.

I keep wondering why I waited so long to move to .Net, especially after reviewing some of the old code I had for a web crawler in VB and seeing how much less code that was required to do the same thing. Just thinking about that old code makes me nauseous.

Yesterday, we attempted to move a few DNN installations from using a local SQL Server 2000 database to our new SQL Server 2005 server. First, we have a few non-DNN sites that are from pre-DNN days and are using the SQLOLEDB provider. After moving the largest database of 3.5 Gb, testing the site showed remarkable improvements of speed and performance. On pages with heavy data interaction, some loaded almost twice as fast. We then moved a few of the databases for smaller DNN sites to the new server. These sites were really small and a huge difference in speed could not really be determined without some page execution code being added. Then we tried moving a 2.5 Gb DNN database. The move went smooth, but the speed was horrible!

So, this had me thinking about incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect error again. Could an issue with the default provider for DNN and SQL Server 2005 be causing trouble? Oddly enough, when monitoring the remote SQL server, there was a huge spike on all 4 processors while processing the page. Well, I am going to find out tonight. I am going to test speed from a remote SQL Server 2000 server and see if there is any difference in speed. I'll post my results here...

UPDATE:

What a surprise. Checkout the results...

 

 

So, it looks like this is a 64 Bit and default DNN data provider issue. As I mentioned above, the old non-DNN sites using SQLOLEDB for the provider were super fast.

Could this be related: You may experience slow performance when you run 32-bit SQL Server tools on 64-bit operating systems

Look like a call to MS Support is in order. I just need to do a little more reseach on the DNN data provider. More details coming soon....

Update 1/4/2005:

After looking through the DNN documentation, I found the following: DotNetNuke Data Access.pdf (428.91 KB)

Let’s recap the 2005 year of DotNetNuke and Venexus.