I've been monitoring this thread, as it's a topic that interest me (and many other coreteam members). Whilst we're aware of lots of installations that have many thousands of users, and hundreds/thousands of portals, we rarely receive feedback from these people, so we're forced to make "best guesses" and use the resources at our disposal such as dotnetnuke.com to determine necessary changes that would help with these installs (note: I am aware of many govt./educational/militaryforture 500 sites as part of my security role, so cannot discuss them due to NDA's)

This area really is composed of 2 parts. The first is general performance (which is an area we're looking at at present so expect some improvements in the next releases) as it has been a while since we looked at it from a holistic portal level. Please note, performance improvements are checked in constantly i.e. the other day a fix for a roles related issue that's existed for a few years was checked in that will boost performance for all sites, but particularly for those with many roles, it's just been a while since it was done end-to-end.

The second part of this area is really the UI, and where it is not suited to large scale deployments. There are many dnn installs which take the framework into areas we neither have the hardware, data (or imagination in some cases - people are using it in very innovative ways) to test, so we rely on feedback from users.

For instance, for a long time there were only a few security roles on dotnetnuke.com, but with the advent of the projects the roles grew substantially, at which time it was obvious to us the UI needed fixed to deal with many roles better - hence role groups. Now, you may argue that this is obvious, but it's only with large samples of data or feedback, that these points are made more apparent. The same applies to users, which is a UI area we've refactored extensively.

Recently, we've also received feedback from users who have so many portals that when logged in as host, the portals screen are virtually unusable. This again is an area we'll look at, but also have to balance against resources e.g. for the small number of people who experience this issue (which for them is a showstopper) against the much larger (probably 99.9% of user have 1-3 portals per install) group for who this effort would not bring a benefit. At the end of the day, we need as much information/feedback as possible, either via the forums or preferably via the public issuelog http://support.dotnetnuke.com/project/Project.aspx?PROJID=23 , so we can determine need and prioritise accordingly.

egyptegypt, I'm don't wish to appear as if I'm picking on you (I only wish to use your comments to illustrate a point), but your comments are typical of ones I've heard many times ("It required extensive customization to get it to a useable state and it's still a work in progress. "), but we get surprisingly little of this feedback/customisation code from the community. Have you any information/code you wish to share, I'm sure we'de be interested in listening (I appreciate that some people make changes that they regard as their intellectual property/unique selling point, and the BSD licence makes this completely fine). In many cases unless people step forward and make their concerns apparent, they won't be addressed - simply put, if we don't know of them, theres little we can do to fix them. Communication is something an open source community is supposed to be better at than closed source , I encourage everyone to try to make it so.

FYI: the performance boost around roles that I mentioned earlier came about as we were helping a user who's site crashed after a particular number of portals loaded. During our investigation, his site crashed after approximately 6000 portals loaded, and after extensive research helped by the community members data/error messages, we tracked it down to the role area. This fix will now allow them to scale to many more thousands of portals, whilst benefiting everyone else.

Cathal