XPages application development for large user groups and high performance

Question

The following questions were asked by a client who is planning to write a large-scale XPages application. Although I think the questions are really broad to fit the stackoverflow style, they are interesting, and the collective knowledge of experts here can give better results than the one person answering them:

• How many willing users can use XPages applications on a single Lotus Domino server (do you have multiple applications on a Lotus Domino server?)
• How can we detect and analyze memory leaks on a Lotus Domino server when running the XPages application?
• How can we write XPages the right way to achieve maximum performance and memory leak?
• What methods and code objects should not be used?
• What are common mistakes when a Lotus Script developer starts writing code for XPages? What are the best practices?
• How can we create a centralized, consolidated application on XPages for 10,000 to 15,000 users? How many servers do we need? How to configure the XPages application in this case?
• How to add users to the system?

I will provide my ideas, please share your

Answer 1

• How long is the string? It depends on how the server is configured. And the "application" can be one form or hundreds. Only a test can tell. In general: Build a high-performance server with 64Bit architecture and plenty of RAM. Make this RAM available to the JVM . If applications use attachments, use DAOS, put them on a separate drive, and of course, make sure you have the latest version of Domino (8.5.3FP1 at the time of this writing).
• There is an XPages Toolbox that includes a memory and processor profiler.
• It depends on the type of application. Smart use of areas for caching, expression language and beans instead of SSJS. You lose memory, you forget .recycle . Hiring an experienced lead developer and reading a book is also another and two . Consider slicing longer code, so users don’t have to wait.
• Depends on your needs. General Domino development lessons apply when it comes to db operations, so FTSearch through DBSearch uses a scope compared to @DBColumn for parameters. EL via SSJS.
• Typical errors include: all code in XPages -> use script libraries. Too many @dblookup, @dbcolumn instead of scope. Check in buttons instead of validators. Violation of the principles of decomposition. Forget to use .recycle (). Designing applications "like old note screens" instead of one-page interaction. Too little use of partial updates. No caching. Object orientation too small (cluster functions of graves in script libraries).
• This is a summary of Question 1-5, nothing new to answer.
• When clustering Domino servers for XPages and before setting up load balancing, the load balancer must be configured to save the session on one server, so partial updates and Ajax calls reach the server on which the component tree is presented, the user.

Answer 2

• It depends on the server setup, I have ie extranet XPage with 12,000 registered users covering more than 20 XPage applications. It runs on a single Windows 2003 server with 4 GB of RAM and a quad-core processor. In these 20 applications, the data volume is about 60 GB. No Daos, no beans, just SSJS. Great performance. Therefore, when I upgrade this installation to 64 bits, and the Daos application will scale when more. So 64Bit and a lot of Ram are the key to a lot of users.

• I did nothing around this

• Make sure you redo when you loop documents. Use the openntf.org debugging toolbar, which will save a lot of time before we have a debugger for XPages.

• Always think when you do this, it will be done by several users, so try reducing the number of searches or getElementByKey. Try using ViewNavigator when you can.

• It all depends on how many users use the system at the same time. If you have 10,000 - 15,000 users at the same time, you should look at what the applications are doing and how many users will use the same application at the same time.

This is my understanding of the issue.