next up previous contents
Next: Efficiency of the SOAP Up: Performance and Scalability of Previous: Scalability and Performance of   Contents

Memory Usage

As a next step, the memory requirements were tested. The current memory usage for the OPC server could be retrieved from the operating system and was periodically logged. Then the three OPC operations ``GetStatus'', ``Read'' and ``Browse'' were tested with 1, 50 and 100 concurrent server requests. The results of this memory usage test is depicted in figure 76.

Figure 76: Memory Usage of IGUANA OPC XML-DA Server in Different Scenarios
\begin{figure}\centering
\includegraphics[scale=0.4]{graphics/perf-runmem.eps}\end{figure}

It can be seen that the idle server requires approximately 15MiB. It is interesting to observe that the ``Read'' and ``Browse'' operations consume much more memory than the ``GetStatus'' operation. The reason for this behavior is that ``GetStatus'' does not connect to the ESD server and hence does not create any Twisted ESD client protocol objects. However, the memory requirements are huge in case of concurrent requests: 10 concurrent OPC read requests almost double the memory requirements of the server. However it is also interesting to see that the additional requirements between 10 and 100 concurrent requests are not as high as it would be expected. The reason for this server behavior is uncertain, but it is expected that certain optimization would greatly reduce these high memory requirements157.

It was further interesting to examine how much memory is allocated by various server modules. Therefore the memory usage of the server was measured during the server start time after each module load. The results of the OPC IGUANA server memory allocation is depicted in figure77.

Figure 77: Memory Usage of the Server Components
\begin{figure}\centering
\includegraphics[scale=0.5]{graphics/perf-memusage.eps}\end{figure}

It can be seen that the Python interpreter and the ZSI framework each allocate approximately a third of the memory, while the last third is allocated by the Twisted modules and the OPC server logic. It is interesting to see that the SOAP message handling, which is done by ZSI and its generated typedefs consumes almost a third of the server's memory, which is quite much. Moreover, it was also not expected that the Twisted framework consumes so much memory.

It is expected that certain optimization, especially in the ZSI SOAP framework but also in Twisted, could lead to a reasonable memory reduction, however further investigations on this topic were not done.


next up previous contents
Next: Efficiency of the SOAP Up: Performance and Scalability of Previous: Scalability and Performance of   Contents
Hermann Himmelbauer 2006-09-27