Rick I don't have the code for the latest version ready to be posted yet, it needs to be packaged up properly.  However, I can tell you that the size of the page cache is worked out like this (the page cache is a dictionary<string,string> object, with the first string the alias/pagename, and the second string the rewrite value, ie default.aspx?tabid=34):

sum across portals( portalAlias x tabs). 

So if you have 200 portals and 76774 tabs, and each portal has 2 portal aliases, you're looking at a dictionary size of (76774 x 2) = 153548 entries.  The average entry size for the dictionary is probably 45 bytes, so right there you're looking at 7 Mb as a best case scenario.  In reality it's probably 10-20% bigger than that.  And as you have noted, the process of building the cache for the number of pages you're looking at requires some decent working memory.

I do have future plans to cut down the dictionary size by both only building the dictionary for portals as they are requested, rather than all portals as you have noted.  I also plan to only keep a copy of the page for a single portal alias, instead of duplicating across portal aliases.  This will mean choosing a single,canonical portal alias, but this is good practice anyway.  These changes will ultimately mean that the page index will be reduced by at least 50%, and, if built portal-at-atime, reduce the startup.  These factors don't show up for single portal installs, but one like you're talking about is showing up these issues.  The reason I haven't done this yet is that to do it properly it requires some refactoring of the code so that it deals with portals individually rather than altogether as is currenlty the case.  It's designed like this as I originally wrote the provider with a single website in mind, and the scope of the project has grown somewhat since then, but those fundamental design choices are still showing through.

So I think my best advice I can give is that the module might not be suitable for that size install just yet.  But I'm happy to work with you in improving performance by concentrating on these aspects.  Unfortunately I can't just drop everything and fix these things because of my workload, but over time I will endeavour to address things.

-Bruce

Rick

I'll endeavour to get some source code to you as soon as I can.   You can certainly experiment with it and attempt to restrict to one portal load at a time.  My plan is actually to flip the order around somewhat and identify the portal first (based on a regex - sourced routine I've already written) and then go on to identify the tab etc if required.  The reason for this is to (1) only load the tabs for that portal and (2) allow all types of domain-based redirects before going through the processing of finding hte matching tab.  The current system (as is ) tries to identify the alias/tab as a pair, and then works out if that was the correct alias or not.  It's kind of around the wrong way.

With regards to your suggestions - the first thing you'll find is that identifying a portal based on a domain name is a very tricky thing indeed.  Portal aliases are strange beasts - some are just domain names, some are domain names with virtual directories.  Others are domain names with child aliases tacked on the end.  Some have port numbers, some do not.  It's never just as simple as finding something to the left of the first '/' like it would appear at first glance.  Trust me I've been down that difficult road!

-Bruce

Hi Rick

I've posted the source code at http://www.ifinity.com.au/Products/Friendly_Url_Provider_For_DNN/

I'll make no warranty as to whether it will compile out of the box though, because I haven't had time to verify that it is complete and correct.

-Bruce