DotNetNuke

[Y] DNN 3.1.1 Re: Updating module settings is fast, again

DocHoliday — Mon, 22 Aug 2005 09:02:46 GMT

Hi Core Team,

I just want to congratulate you on the release of DNN 3.1.1. The nasty problem mentioned at the start of this thread has vanished after the update.

Cheers,

DocHoliday

Re: Updating module setting takes ages

mathisjay — Thu, 09 Jun 2005 13:11:11 GMT

Hmm, very interesting... I hadnt thought to check that but I know there are some tabs with duplicate names. I had noticed that the search indexer was spinning out of control but I thought it was just because it was the first time and nothing had been indexed yet. I actually disabled it until I am sure everything else is working right.

Re: Updating module setting takes ages

DocHoliday — Thu, 09 Jun 2005 12:58:47 GMT

I shrinked the DNN database log file from 8.207.000 KB to 10.000 KB. It made unfortunately no difference.
I renamed all tabs which had identical names.

Tab Structure (extract):

2005

december
november
october
september
august
july
june
may
april
march
february
january

2004

december
november
october
september
august
july
june
may
april
march
february
january

2003

etc..

I believe that the repeated tab names confused the search indexer.

Cheers,

DocHoliday

Re: Updating module setting takes ages

DocHoliday — Wed, 08 Jun 2005 15:46:22 GMT

Update on search re-index problem:

I deleted the records of the SEARCHWORD and the SEARCHITEM tables with:

1:   delete from searchword
2:   delete from searchitem

After that I let the seach scheduler reindex the site.

Now all the modules, inclusive those that are newly added, are being displayed in the search results .

1 big problem solved.

Cheers,

DocHoliday

Re: Updating module setting takes ages

josun — Tue, 07 Jun 2005 13:12:41 GMT

Sawasdee Kap:

I have been through everything that everyone here is mentioning! (Maybe not everything - do not mean to sound arrogant!)

There are a couple previous posts from me:

Very Loyal - BUT Rapidly Becoming NUMB and,

Very Loyal - Rapidly upgraded to Happy

DNN 2.X to DNN 3.X - Upgrade:

Everything that everyone is mentioning occurred with me and the upgrade. I tried everything (Deleting Tab Entries based on ISDeleted, HTTP Compression, etc., etc.) - performance of the upgraded DNN3.X site was even worse than some people in this forum have experienced. Far worse, up to five (5) minutes and I would get a Win2003 Sign On Screen, sign-on and them DNN "Time Out" or "Not Authorized" error messages would be displayed, on and on and on!

So I "Bit" the "mortar" -

Before I did the "Clean" install of DNN 3.x I exported the TABS table to an Excel file.

Clean Install of DNN3.X -

Found all duplicates (Tab ID, etc.) and cleansed the Excel spreadsheet. There were entries that I deleted months and months ago but were still within the Tabs (Links, etc. Table.

Took me a little tweaking in DNN 3.X - but I removed the dependicies of TABS - uploaded the "cleansed" excel spreadsheet and then associated the dependicies back to the TABS module - some other things I had to do as well - cause this was not a simple as I am writing.

Brought up my DNN3.X site and "voila" everything seems to run really good!

I posted some performance stats (we used a test tool after clean install and re-importation of tabs, etc.) and everything runs pretty darn good. I am happy!

Yes, even after a clean install - we have added some additional TABS since - but the longest I have experienced is about 10 seconds and once again, we have over 400 tabs (call external URL links) - but seems pretty solid to date.

A couple of issues with TABS in fresh install - when we move a GROUP it takes a while but we hardly ever do - so no complaints there.

Group - Being

Heiarchy 1
   Sub Option 1
   SUb Option 2
   Sub Option 3

When we move Heirarchy 1 up or down the pages list - it drags - but ok!

Overall, it was worth the effort in that working with the upgraded DNN3.X site - was just "un-workable" so at the end of the day for us there was not other option other than performing a "clean" install".

I know that this does not answer everyone's questions - but "I just had to do something" - I received a lot of help from the members on the forum!

Just bite the bullet and do a fresh install - yes, there is going to be some work - but that is why we go to work!

Best regards,

Joe

Re: Updating module setting takes ages

mathisjay — Tue, 07 Jun 2005 12:50:16 GMT

How long shoud it take to "Clear Cache" on an installaiton that has around 50 portals? Mine is taking over a minute on the remote host, but only a few seconds on localhost.

Re: Updating module setting takes ages

DocHoliday — Tue, 07 Jun 2005 08:36:34 GMT

I got it, I got it, I got it......almost . Finally I could re-import the site and and the content of my defect portal into a new install of DNN with the Wizard. Thanks a lot to a hint of Vladan Strigo in another post. My template file was quite big 183MB and with the additional setting in the web.config:

<httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="8192" executionTimeout="9000" />

I no longer received a timeout error during the import process.

This means: I have now a new install with the old content (unfortunately not also the users).

Two points:

1. Search is still not displaying in the search results newly added and indexed Text/HTML modules .

2. Updating module settings now takes about 25 seconds. 5 seconds less . I tried to delete some security roles (I had added 17 security roles with old portal), but it had no impact here.

Cathal, what you have suggested, does this work also when one starts with former upgrade portal of 3.0.13?

Cheers,

DocHoliday

Re: Updating module setting takes ages

cathal — Mon, 06 Jun 2005 21:53:55 GMT

All,

I've continued my investigation and found a few further problems in the database I was provided. All of them were caused by some 3rd party triggers ( trgUpdPortal and trgInsUserPortals in this case). The main problem was with trgUpdPortal being incorrectly coded. When the upgrade happens, the following statement (update Portals set AdminTabId = ( select TabID from Tabs where Tabs.PortalID = 1 and Tabs.TabName = 'Admin' )) is ran as part of the 02.02.00.SqlDataProvider script, and fails with a "Subquery returned more than 1 value. This is not permitted when the subquery follows" error. This is at the heart of all this users future defects, as the admintabs aren't set, causing later script errors. These then translate into incorrect data and duplicates, which caused various loops and problems. I don't know where these 2 triggers came from, but we never use triggers in DNN, as they are database specific objects. I can see the second one points to a userportals table, so it looks like some 3rd party module that never got cleaned up. I'd suggest anyone having problems, makes sure they aren't using any triggers or constraints added by 3rd party modules, as these may not be coded correctly, and may be causing issues.

Can anyone who is having a problem please try the following (starting from their 2.12 installs)
(1) delete the dnn.config file in the install folder (if it exists)
(2) delete any *.log files in the Providers\DataProviders\SqlDataProvider folder
(3) copy across the 3.0.13 files, and amend the web.config file
(4) hit the site to do the install
(5) check the Providers\DataProviders\SqlDataProvider folder, and examine all the *.log files numbered 02.02.00.log and above. If theres any upgrade errors they'll be listed, so you can see if any 3rd party installs are causing issues.

Thanks,
Cathal

Re: Updating module setting takes ages

mathisjay — Sat, 04 Jun 2005 21:03:35 GMT

Regarding the scheduler, I also noticed that when I first tried upgrading, I had some settings that worked OK in 2.1.2 but caused an endless loop in 3.0.13. I don't remember what they were now, but I found it by tracing the code and watching it get stuck trying to start the scheduler over and over. To fix it, I manually edited the scheduler table to look exactly like a clean install of 3.0.13.

Re: Updating module setting takes ages

cathal — Sat, 04 Jun 2005 20:41:55 GMT

DocHoliday,
FYI: the log.xml.resources file is not used by the sitelog, it is used to log portal events such as user created, tab updating etc (see the LogConfigTemplate.xml.resources for the current events logged). A 10MB file is still very large, I'd recommend that you use the log viewer itself to manually clear down some of the events (use the clear log button to else clear selected events)

Cathal

Re: Updating module setting takes ages

DocHoliday — Fri, 03 Jun 2005 08:14:50 GMT

Hi Cathal,

the size of my scheduler.xml.resources is 297KB, that of log.xml.resources 10MB. I have changed the site log storage back from file system to database.

I looked again at the scheduler. I found out that the frequencies deviate from a clean install. Please check the values of my upgrade install:

Type	Enabled	Frequency	Retry Time Lapse
DotNetNuke.Entities.Users.PurgeUsersOnline, DOTNETNUKE	Enabled	Every 1 Minute	Every 5 Minutes
DotNetNuke.Services.Log.SiteLog.PurgeSiteLog, DOTNETNUKE	Enabled	Every 1 Day	Every 2 Hours
DotNetNuke.Services.Scheduling.PurgeScheduleHistory, DOTNETNUKE	Enabled	Every 1 Minute	Every 5 Minutes
DotNetNuke.Services.Log.EventLog.PurgeLogBuffer, DOTNETNUKE	Enabled	Every 1 Minute	Every 5 Minutes
DotNetNuke.Services.Log.EventLog.SendLogNotifications, DOTNETNUKE	Enabled	Every 5 Minutes	Every 10 Minutes
DotNetNuke.Services.Search.SearchEngineScheduler, DOTNETNUKE	Enabled	Every 15 Minutes	Every 10 Minutes
DotNetNuke.Modules.Admin.ResourceInstaller.InstallResources, DOTNETNUKE	Enabled	Every 1 Minute	Every 5 Minutes
DotNetNuke.Services.FileSystem.SynchronizeFileSystem, DOTNETNUKE	Enabled	Every 1 Hour	Every 2 Hours

Cheers,

DocHoliday

Re: Updating module setting takes ages

cathal — Fri, 03 Jun 2005 00:10:24 GMT

An individual was good enough to let me download a copy of their failing 2.12 ->3.13 upgrade, and I've been looking through it, and have some observations. Not all of these may apply to the problems people are having, but hopefully some might.

(1) please check the size of your log files i.e. the Portals\_default\Logs folder. The install I looked at had a Log.xml.resources file that was nearly 60MB. As xml files are loaded into memory when they're being altered, every time an event is logged it causes the whole file to be loaded into memory, which is probably triggering application recycles unnecessarily. Their Scheduler.xml.resources was also large (about 1.5mb), [this was mostly as every time it tried to clear down the Log.xml.resources using one of the purge scheduled tasks it failed]. I'd recommend you delete both of these files, and then recycle the application. When the first events are logged these files will be recreated. During the normal running of the portal, these large files will slow things down, but during an upgrade, as so many events are logged it will make a massive difference to the speed [note: in the next release of dotnetnuke, there is a database version of the logging provider, this will help manage issues such as this, and various permission problems people have]

(2) following a suggestion @ http://forums.asp.net/ShowPost.aspx?PageIndex=2&PostID=924091#924091 , I checked for tabs that had parent tabs that were marked for deletion (this site had 2). I actually did a "delete from tabs where isdeleted=1" query to get rid of all the tabs in the recyclebin for all the portals, and when I then did an upgrade it went through in sub 20 seconds, rather than grinding along for hours.

(3) I checked for circular references amongst tabs (see mrswoop's script @ http://forums.asp.net/ShowPost.aspx?PageIndex=2&PostID=938726#938726), in this case there were none, but I know this has been an issue for some.

After upgrading there were still some database issues around tabs with null portalid and parentid's, I have to go out of town for a few days, so thats all I can do for now, but when I get back I'll examine these and see if I can determine the issue around them.

Cathal

Re: Updating module setting takes ages

cathal — Mon, 23 May 2005 21:55:54 GMT

A number of hosting providers set up their shared hosts in a dual-server webfarm system. This allows them to hit their service level agreements, as they can independantly reboot the machines at different times. The disadvantage of this is that a user can be going to the same server a number of times, and then the load balancing algorithm sends them to the other server, which then has to do an application compile before serving the request. Perhaps this is what is causing some of the speed issues. I've seen a few people on this post : http://forums.asp.net/934376/ShowPost.aspx , state that adding a session instruction made their sites speed up. As many webfarms ignore their balancing algorithm in cases where they need to support session affinity, perhaps a few of you could try this and see if it helps.

BTW, no-one has sent me a copy of their site & db as yet, if anyone is willing please use the private message (PM) function to send me a note to arrange it.

Cathal

Re: Updating module setting takes ages

wpballar — Fri, 20 May 2005 22:07:20 GMT

Thanks for the kind post. I work hard and have some wonderfully talented clients.

The kicker about the menu is that many of my clients have their own graphic design departments. They all run Macs and demand Mac compatibility. Solpart Menu falls way short on cross browser (it fails on Safari which seems to be the default Mac browser).

I'm using the new Component Arts Beta and it does add a lot on postback. However one of my sites www.aroundthecreek.com hums along fairly fast with it. It's DNN 3.0.12 and I'm afraid to upgrade for fear of slowing it down.

One of my problem portals is www.westchesterchurch.org and it's on the solpart menu. It runs pretty good until you login as admin, and then it slows way down. It was an upgrade from DNN 2.xx and I've had to disable the scheduler entirely. The scheduler can literally bring the machine to it's knees. I don't know how to fix it (and I'm a fairly capable programmer).

This goes back to the point - many of these issue are only occuring in admin mode. The other thing is the problems are quite intermittent. You may click on a page 30 times and it be just fine and then hang the 31st for minutes.

It's frustrating to my clients and it's seemingly impossible to troubleshoot. I've been trying to track it down for a month (and I've witnessed it as I waste hours plinking around my sites).

I know I'm not alone because I see the other posts. I must say I'm beginning to question my sanity.

Re: Updating module setting takes ages

DocHoliday — Fri, 20 May 2005 19:02:03 GMT

child portal?

We're talking about upgrading a DNN installation and the operation of updating module settings after the upgrade. It has nothing to do with creating a child portal.

My upgrade threw no error messages and the only non-core module I forgot to remove was the multi-page content module from Bo. Also no core changes.

Cheers,

DocHoliday