Virtual portals are ideal for setting up many micro sites that all have the same sets of applications in common. The most common usecases involve central service providers hosting a specific application suite for a series of independent yet similar tenants (departments, sales teams, vendors, etc) that all need access to that same application but want a differently branded experience. This is the usecase for which virtual portal was designed. This allows the maximized use of costly infrastructure and allows more users through the system without impacting the system with too many disparate applications.
That being said, virtual portals can also be used to host totally different user communities with different application needs. However, you do have to be more careful with how having many different applications will impact JVM heap utilization. Applications are shared resources across all virtual portals, regardless of whether the VP is actually using a particular application or not. Therefore, users in VP A can experience the effects of applications running for users in VP B. You can isolate the application environment from the virtual portals using WSRP, running those applications in their own JVM, but otherwise there is no application isolation inherent in virtual portals, nor will there ever be (hence the term "virtual").
If all the tenants use a common set of applications, you can likely scale to a very large number of tenants and virtual portals. If there is very little in common between the virtual portals, then you can expect to only scale so far, how far will depend on the relative expense of the applications in terms of memory consumption.
We have documented in the past that we only support 1000 virtual portals. That isn't actually true. We have only tested (back in WP 5.1) up to 1000 virtual portals. There are no physical limits to the number of VPs we can support. The number of virtual portals a system can support is highly dependent on the size of the VP in terms of pages, the number of users having access to that VP, and the inherent overhead of the applications in the system. There is very little to no overhead in the usage of virtual portal by itself.
For a system with a large number of virtual portals, performance is optimized when:
- Most users have access to a small number of pages relative to the whole portal (e.g. access to only one VP)
- Multiple users have the same roles on the same sets of pages (optimizes the caching of common content)
Otherwise, a large amount of resource (memory and CPU) is consumed keeping up with every user's configuration.
Performance will eventually degrade with very large virtual portal deployments with little content commonality between users, as our caching mechanism becomes less efficient and too memory intensive. What "large" means will vary by implementation, but is most likely in the several thousand range. At that point, you should consider adding parallel portal clusters for future VP instances and federate between them using technology like WebSphere Application Server Extended Deployment, which knows how to route users based on virtual portal ID to the correct Portal cluster.