Products

Solutions

Resources

Partners

Community

About

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Practical limitations

Return to previous page

  • 4/7/2015
  • 3717 Views

Comments

3717 Views

Practical limitations

Last updated long time ago

Comments

Common

(Enter the content of this article below)

Advanced

 

Background

As an asp.net application, that typically utilises a SQL Server backend, a sites scope and size is typically only restricted by the hardware available. However, due to architecture and design there are a few limitations that site owners should be aware of

Note: Defensive code is being added all the time to catch these issues and warn the user , but if you are using old versions of DotNetNuke, then it is possible to generate an error without understanding why.

Reserved words


Pages

When creating pages, there are a few page names that cannot be used as these are already used as physical pages or handlers. These include

  • ErrorPage
  • Default
  • LinkClick
  • SiteMap
  • Alert
  • BIN


Portals

When creating a new portal, the admin can create either a child portal or a parent portal. A parent portal has a fully qualifed domain name (FQDN) such as www.mysite.com so the only restriction is that applied to DNS records. However, if you create a child portal this creates a folder. As the new folder will exist on a Windows filesystem, it must respect windows folders naming rules. The following names are not allowed by windows so cannot be used as a child portal name

  • AUX
  • CON
  • NUL

In addition, the series of reserved words for COM and LPT from 1 to 9 cannot be used i.e COM1, COM2 ... COM9 and LPT1, LPT2 ... LPT9

More details of Windows Folder naming rules can be read @ http://msdn.microsoft.com/en-us/library/aa365247.aspx



Size limitations

It is difficult to accurately estimate any size capabilities of DNN, as typically the first time a limit is discovered, it's often found that the underlying OS/Database/RAM is the true limiting factor, so the following figures are provided here for informational purposes only and to help identify any potential bottlenecks.


Number of portals

A number of DNN users are known to run with 3500+ portals, but they require sufficent hardware to support this. When using a lot of portals, queries that join to the portals & portalaliases start to slow down and this can have a large effect. If you wish to run with 1000's of portals, you should ensure your SQL Server(s) have sufficent RAM and CPU's to support this.



Number of users

DotNetNuke has approximately 1.1 million+ users (July '14)
Anecdotal evidence in the forums, as well as a number of sites that do not wish their details to be public known have suggested that having multiple-million user bases is possible, theoretically limited only by database size/processing power



Number or roles

Older sites (pre 6.2.0) had an approximate limitation of 40-50 roles per user as the roles were cached in an encrypted cookie. This limitation was resolved in DNN 6.2.0, so their is no theoretical limitation as roles are not read and cached in server ram -however in general limited role creation is advisable.


Contents
No sections defined
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out