Since Notes is a client server solution it generates a significant amount of NRPC calls between the Notes client and the Domino server. Thousands of NRPCs are created during simple actions like searches and lookups. If you are developing Notes client applications that are used only inside your LAN you will never notice this because the NRPCs are quickly processed. However, if you are accessing the Domino server through the Web, the time to process the NRPCs grows exponentially as packet jumps from router to router. What took less then a second on your LAN could take minutes or longer. One way to reduce the delay cause by NRPCs is to process as much of your transactions using RunOnServer agents.
For our applications, we package everything as XML and process the XML using RunOnServer agents and return the response as XML which is then process on the Notes client using string manipulation which is very fast. From the response XML, we then populate the form. Therefore, there is separation between the data and form. In theory this should keep the NRPCs to a minimum.
I was on-site at our customers working with them to modify a project management tool that we developed. Since most of the users do not reside in the office where the server is located we spend a significant amount of time creating RunOnServer agents to handle the majority of the transactions. We also spent a significant amount of time on the UI to make the experience pleasant for the user. However, even with all this effort the NRPCs continue to bite us and each transaction is slower then it should be. The problem that I have discovered is that the field population process itself like:
doc.fieldName = "hello"
generates NRPCs though everything should be processing on the Notes client. This was very frustrating.
For our applications, we package everything as XML and process the XML using RunOnServer agents and return the response as XML which is then process on the Notes client using string manipulation which is very fast. From the response XML, we then populate the form. Therefore, there is separation between the data and form. In theory this should keep the NRPCs to a minimum.
I was on-site at our customers working with them to modify a project management tool that we developed. Since most of the users do not reside in the office where the server is located we spend a significant amount of time creating RunOnServer agents to handle the majority of the transactions. We also spent a significant amount of time on the UI to make the experience pleasant for the user. However, even with all this effort the NRPCs continue to bite us and each transaction is slower then it should be. The problem that I have discovered is that the field population process itself like:
doc.fieldName = "hello"
generates NRPCs though everything should be processing on the Notes client. This was very frustrating.
Comments
Typically I'd try to spread several replicas all over the world so that users don't need to work on a server located on a different continent. Even for applications that need a central storage place to avoid conflicts it is possible to reduce network traffic by replicating just the configuration database needed for lookups etc.
Another possibility is moving the application frontends to the web browser - no more RPCs calls at all from the client!
This issue is one of the reasons beside others is why we are looking to move away from the Notes client. We are experimenting with Flex and AIR as a replacement for the Notes client. I do not know what IBM's exact plans are for this cloud computing (LotusLive) with the Notes client, but this NRPC issue makes the experience unpleasant. IBM should provide the Notes client the option to access the Domino server using HTTP services. This would resolve this issue.