Hi,

yesterday I have upgraded my production server from DNN 2.1.2 to DNN 3.0.12 with no problem.
The only thing that worries me is that when I edit the settings of a module, it takes about 30 second to return to the page, after I have clicked on the "update" link :-(

A fresh clean installation of DNN 3.0.12 on the same machine is not showing this problem.

Therefore this effect must be related to the upgrade process of DNN 2.1.2 to DNN 3.0.12. Is there something which I can do to resolve this problem, because it hampers the working on the website a little bit.

Cheers,

DocHoliday

I was wondering the same thing, and was suspecting perhaps a solpart issue in terms of the caching of icons??

I have nothing to back this up whatsoever, but I only really noticed it after adding icosn to a number of our menus..

Hi,

in "Host Settings, Advanced Settings, Other Settings" I reconfigured the followings items:

1. Site Log Storage: from Database to File System
2. Performance Setting: Heavy Caching
3. Enable Event Log Buffer: Yes
4. Use Friendly Urls: disabled

No change of behavior.

Anyone having a good suggestion?

Cheers,

DocHoliday

Doc,

I tried upgrading from DNN2 to DNN 3.0.13 and encountered the same issue. When I would access parts of the administration DNN would hang anywhere from 30 seconds to a couple minutes. I looked at processes in Task Manager (Win XP Pro) and discovered that SQL Server was churning away sucking up 99% of the processor.

I then ran SQL Server Profiler and clicked Update on the Site Settings page and SQL server churned away for about 8 minutes logging about 4500 lines in the Profiler. Whoa.

I uninstalled dnn3, restored my database and tried upgrading again. Same result. Did I solve it? No. My opinion is that there are some significant bugs in the upgrade process. I almost decided to scrap DNN3 altogether. However, I decided just to do a fresh install of DNN 3 to see how that went. It worked like butter. I have now got my primary skins finished and so far, I am happy with DNN 3. I will just have to migrate the data from the DNN 2 database myself.

I know this doesn’t help but it lets you know your not alone in the dark. In addition, I have read others have had this problem but I have not seen a solution.

jwadsworth,

thanks for showing solidarity. I'm still stuck with this elflock-stricken upgrade. Unfortunately even exporting and re-importing the portal to a clean installation does not work, either.

Chees,

DocHoliday

Hi

Have the same problem. Please report if you find any solution.

I have this problem on localhost ..  but not on the shared hosting server ...   no idea if it is related or not.

Do you have the problem with things like clearing cache too?  I do...

Can I ask if you were running any modules apart from what came with the standard dnn installation.  I know that part of the testing the guys in the core team do is alot of work to keep the upgrade process in tact.  And I know that the dotnetnuke site has always been upgraded, bit by bit - flaws and all, and I thought that was about the biggest test you'd give a site - one that is so heavily visited.

Can you check that you were not running any other modules - If you are, then you need to uninstall them, or, move them to a page and not access the page until you have put in the upgraded module.

I do know that it's difficult as I had to ditch my upgrading efforts earlier this year before dnn was relased in a more stable format, but I also have seen several developers who have upgraded successfully.

And glad you backed up your data and were in  a postition to roll back because I know of a few people who forget that really important step.

This isn't a solution, just another avenue of thought.

Nina Meiers

Nina

I was not running any custom modules. I did however make a few changes to core modules. I believe they were minor though. Below are the only changes I made to the core framework. I documented every change I made to help me with upgrades.

Portals\_default\Containers\_default\notitle.ascx
Line 3:	Changed the cellpadding from 2 to 0
Portals\_default\Containers\_default\default.ascx
Line 6:	Changed the cellpadding from 2 to 0
DesktopModules\Announcements\Announcements.ascx
Line 2:	Changed the <asp:DataList CellPadding to 5, CellSpacing to 5, Width to 100% / <ITEMSTYLE Width to 100% /
Line 11:	Added (>>) characters in front of the Description dataitem
Line 3:	Added a CssClass tag referencing the my custom class "Announcements" which controls the DataList
Line 13:	Changed CssClass to AnnouncementsDescription
DesktopModules\Documents\Document.ascx
Line 9:	Removed -HeaderText="Title" from the Title TemplateColumn. Removed -HeaderText="Owner" from the Owner BoundColumn. Removed -HeaderText="Category" from the Category BoundColumn. Added Visible="False" to Owner column and Category column. Added width="100%" to Title ItemTemplate.
DesktopModules\Links\Links.ascx
Line 5:	Changed some html formatting (clipped the html that was changed)
DesktopModules\Links\Links.ascx
Line 10:	Added an <ASP:Image tag - Put the image and the link in a table.
SPROC - GetDocuments
Change	changed ORDER BY Title (to) ORDER BY ItemID
TABLE - Links
Change	Title field size from 100 to 250
SPROC - AddLink
Change	Title field size from 100 to 250
SPROC - UpdateLink
Change	Title field size from 100 to 250

I also have this problem. Same facts and everything.

I thought I'd update this and let you know that yesterday, I noticed there has been some further testing on the behaviour of upgrading to 2.1.2 >> 3 - I believe Scott is using either the 3.013 or the latest build currently being tested and found a few areas that needed modifying when being debugged so these are also being addressed.

Thanks for posting what you found, I'll point this out to ScottW (mrswoop) in case there is more that he may not have picked up.

It's really appreciated that everyone chips in and detail these errors, because it's sometimes difficult to pickup everything.

Thankyou

Nina Meiers

That's very interesting. The upgrade that is not working for me is from 2.1.2 to 3.0.13.

I just want to add that I'm having the same issue with upgraded portals. I've faced the wrath of some clients over it.

I've seen some real performance issues on the admin side of DNN3.xx . I know several members of the core have really defended it, but there are way too many of us out there having speed issues on both clean installs and upgrades.

The logic presented in other posts always goes down the path that "There are 3rd party modules" or your SQL server's slow or whatever. I'm running my own dedicated boxes that aren't overloaded and are maintained well.

Some Core folks need to really address this, not just give pat answers. There are postback events on the host menu that can take 60 seconds to clear my server. It's too long and it's not the servers fault. 

I say this pointedly and yet with great respect. I've built my business on DNN and hope to continue to do more. I'm very thankful for this gift the open source community has given. It's just quite threatening when my flagship product has issues I can't control for my clients.  

For all you folks out there - one thing I've done that has helped speed things up is change the schedule on the search indexer down to just a few times a day. Before I did this my box would go to crawl every 2 hours or so while the indexer did it's thing. It feels like and intermittent problem you can't ever track down. Now it indexes late at night and my page loads are fairly consistent.

 

 

Hi Will, that is interesting the suggestion you post here to help speed things up in reference to the search indexer, and I thought I'd have a look at some of your work and see how the sites pull up.. because I've found that DNN3 is much faster, not just a bit, but much faster in how it performs.  My clean install of DNN3 is fast, but  I have not attempted a global update of my DNN2 portals t0 3 yet.

On your site, I notice your beautiful menu - and viewed the source on it,  Have you tried running these sites without that menu? Before I was in the dnn space, I used to use those funky menus, until I saw the weight of the page. There was sometimes up to 60 - 80k of menu JS and in the end I decided for heavily accessed sites, this was not the way to go - just to have a nice looking menu. So while you may not have any other modules, I'm wondering if the size of the menu could affect the performance.

Had a look a couple of your sites - (quite lovely by the way)

http://www.fellowshipchurch.com/fcweb/home.aspx  and http://www.fellowshipchurch.com/FCWeb/events/blog.aspx?pgId=348  took little longer to load than http://www.megansmission.com/Home/tabid/135/Default.aspx which is a DNN site - but I noticed in this one, there is no large menu source.. in fact it loaded in a very reasonable time.
http://www.brcc.net/Ministries/30SinglesMinistry/tabid/333/Default.aspx took a while and refreshed once, and there is either an iframe or applet running.. so load time on that would be slightly more which would be expected.

Have you tried to apply a skin that uses the standard solpart menu and see what the performance results are. At first glance, it appears there is alot going on with the menu on your sites that perhaps could be addressed and this is just a suggestion, having done many sites over the last year or so.

I run my own servers too, and they aren't overloaded either, and found that a standard installation of DotNetNuke is extremely fast, and yes, there is always room for improvements like any application.  The DotNetNuke website runs on a standard installation with over 1million page views each month so it gets it's fair share of traffic with over 400 people registering every day on average, it's fair to say it performs pretty well.

Also there is information around on optimisation, tweaking, and things you can do to speed up the sites, but not sure if that's for 2 or 3 - I know that Patrick Santry did some optimisation on his site due the load of traffic.

Performance issues are just as important for the core team developers, as is security, enchancements and such and I'm not going to defend them, but sometimes it's hard to gauge any problems until it's been put out, and the next release sees the fixes and updates.  If there are issues that you can pinpoint and isolate, and then posted on forum, they are generally logged into the support forum, by one of the core team and it's addressed from there.

These comments put here, are not meant to antagonise or make excuses, they are just my thoughts as I go through and see how other people use DNN and what their level of expectations are by comparison to developing in a Non DNN environment.  I'm convinced that a clean install of dnn3 is the fastest that's been developed to date, as I'm running several sites, and it runs smoothly atm with one portal and 40 child portals atm.  But all have standard menus or the flash headers.

Thanks for the post and comments - Nice looking work you've done!

Nina Meiers

I have the same issue, module updates and page setting updates. Made a post about it a month or more ago and nobody responded so I thought it was my problem. CPU usage goes to100% every time. Portal performance has been good, it's just during the updates. The big problem is if you get several people doing updates at once it brings the server to it's knees.