what is the volume(messages/second) can xml rpc server handle?
the answer, as always is “it depends” :roll:
The limits are usually a function of the message size and complexity of the documents being processed, the back end service operations being performed as well as the hardware and available memory it is being run on. If you need higher throughput than a single xmlrpcserver can provide, you can run multiple instances on additional server hardware. Assuming, of course, the back end service being called by the xmlrpcserver can handle whatever load you are trying to throw at it.
If you give some parameters (message size, platform, memory, CPUs, target transaction speed/volume), other users might be able to chime in with whether or not they hit those volumes.
I want to know where exactly the conversion of data from mainframe to xml request is happening in XML RPC server.
Right now, XML RPC is taking approximately 1.5 seconds for each call.
Is there any way of optimizing the data conversion and minimizing the time taken for a call?
Can you please suggest on this.
Please elaborate on what the 1.5 seconds is a measurement of. An XML RPC Server receives messages from the EntireX Broker and turns around and calls a web service, and then if applicable will receive the response back from the web service and return the response payload back to the Broker. Of course there is client to Broker and Broker to client communication occurring as well. The total time recorded in the log might include the time the web service takes to process the request and network latency, too.
It would be the XML RPC Server that converts the payloads from Broker format to XML format using the XML mapping layout (*.xmm file) and back again. If you’ve recorded various other relevant timings (web service time, network latency) to get to the 1.5 seconds in the XML RPC Server, then other things will come into play (e.g., what is your transaction rate, how is the CPU load on the server that your XML RPC Server is running on, does it make sense to scale up to run additional XML RPC Server processes to handle the load on the same server or another server, etc.).