Phase 6: Responses (performance)

There are not very many performance tweaks that can be made here. We already mentioned a faster network, faster hard drives etc. at the outset. Only Responses of type "Message", where one profile calls another, allow you to change a few settings that affect performance. When we were talking about memory, we advised you to set the checkbox "Pass data via file". This is much more memory-friendly but of course, when a file needs to be written and then read by the next profile, this takes some time. As long as you are dealing with small volumes of data, for example, a CSV with a few hundred rows, it is simply more efficient to transfer this data directly in the memory. The best thing to do is to export your data into a file and check the size. If it is less than a hundred kilobytes, do not bother with the file transfer method.

Using asynchronous or persistent messages does not really improve performance in the sense of saving processor time. The key is that if you use synchronous messages, the sending profile must wait until it receives a response from the profile that it has called. Only then can the profile execute further Responses or end successfully. By contrast, there is no waiting for asynchronous (or persistent) messages. Once they have been fired off, processing continues straight away. Persistent messages are generally preferable as they are somewhat more reliable than plain asynchronous messages. This means that the first profile is finished more quickly, and there is no need to prioritise the profile that has been called. Instead, it can be placed in the queue as normal. As we said earlier, this does not really save processor time, but the throughput can 'feel' better as the thread for the message sending profile is immediately available for another profile.

However, we should not overlook the disadvantages. The profile that sends the message will not know if there is a problem with the profile to which the message is sent. This means that no other Responses can be dependent on this one because it will always be classed as successful. And if a serious problem were to occur with the hardware or operating system before a job was created with the data for the profile to which the message was sent, then the logs would show the first profile as successfully completed, but there would be no indication of the second being incomplete or incorrect. With synchronous messages, you would at least be able to see that the first profile has been unable to complete its work and to react accordingly. You should, therefore, consider whether you actually want to work with asynchronous or persistent messages in your current situation, or whether it might not be better to use synchronous messages.

As a side note, a thread is always created immediately for profiles that are supposed to respond to a synchronous message. This means that you can also force this profile to be handled immediately, without waiting.

Note: See also sections "States of Responses" and "Dependencies Between Responses".