Does anyone have any experience in Sun Java Portal Server in production environment? How does it fare, comparing to BEA or IBM Portal Server?
Cant' talk for BEA but I have experience in both IBM and SUNs portal offerings. Personally I prefer IBM as I find it has more maturity in this market generally even though Sun have just announced their new portal server which has included stuff regarding blogging and wiki's. Today for large enterprise scale portals I use IBM Websphere and find that the performance is good. We must bear in mind that most performance issues encountered in portals are generally to do with poor portlet application design and implememntation and not the vendors portal container itself.
Does the number of portlets that a portal server has, affect its performance greatly? Say if I have 10 portlets, will logging into the portal be significantly longer than if I have 5 portlets?
Depends how many portlets you have on a particular page and what they do.. If after you authenticate, your first page contains 10 portlets which are all accessing different datasources then you could be up for a performance hit especially when you try to scale the application up for 000's of users. Good portal site management and User Interface Design is key to addressing the needs of the business and ensuring that portals don't become stuffed full of unrelated applications to which no personalisation has been applied and no UCD. In answer to your specific question, yes 10 portlets will take longer than 5 generally but this also depends on caching and pooling strategies plus the exact nature of the function the portlet is performing e.g. if you had 10 portlets which just displayed HTML compared to 5 portlets that read datasources via EJB's or web services then the latter most probably would take longer.
I just finished a project with Sun One Portal Server and I agree with everything that was said previously.
Specific to Sun One Portal Server...
Be sure to run the performance tuning scripts they provide and make sure you use the mode that actually makes the changes or be prepared to do them manually.
Consider how many times a particular portet is called. We wrote some pretty generic portlets (JSR-168) to minimize the number of deployed applications. Example: We needed a link list portlet that provided more functionality than the one sun provides (...better user interaction for mainting the list). We created one portlet that used the preferences during channel configuration to establish the listname, who could edit it, etc. A portlet ultimately becomes a servlet. All the channels configured up use that servlet to render the content and respond to actions. We had some 50 channels each with a different list. I had already set up caching both at the data access layer (singleton custom cache)and at the portal presentation layer on the channel itslef (refresh property). This handled most everything but under extreme load (using 6 remote test machines running JMeter) we started throwing some exceptions related to concurrency. I don't recall the specific exception. What we did was to solve that was to deploy more that one instance of the portlet which in turn created more instances. We then altered the channels to spread them across the portlet app instances (especially where more than one instance of a list was on the same "page").
Lastly, make sure you performance test. JMeter does a pretty good job.