Overview

You would like to understand why the server CPU was high when a large picture and fetch request were processed in parallel. You want to know what processes are running when a large picture is coming from other mobile operators.

Information

When Mercury or other MMSCs receive a message, no matter where it is from, it saves it to internal storage as is and notifies B-party that a new message is received. When the MMS application on the B-party handset starts fetching the message, MMSC transcodes the message accordingly with the B-party handset's capabilities. If a device cannot receive a large picture as is, Mercury has to transcode the picture after performing every fetch request. In some cases, this picture has to be transcoded several times because Mercury makes several attempts to reach the target size and resolution of the picture. Therefore, no matter where a message was received, it will be transcoded when a fetch request is performed.

Mercury does not provide a protection mechanism for such cases (i.e., it doesn't monitor CPU load).

However, Mercury can work with external transcoding servers. One or more additional machines can be configured to transcode message content, and Mercury will balance the loading between these servers.