Project Details
Changes Log
Who We Are

Performance considerations

    1  Overview
    2  Network configuration
       2.1  Default Network configuration
       2.2  Network configuration improvement
    3  Maps updates
       3.1  Projection update cap
       3.2  Optimizing the Map updates
    4  JVM options
    5  Notes

In ARINC 661 The performance of the an ARINC 661 Server is mainly related to how it answers to the User Applications Buffers. Note that while the Server does not receives any Buffer, it will normally not use any or very few CPU time.


The ARINC 661 Server runtime pipeline is event−driven, which means that its job is to: The time to take the buffers sent by the UA into account contains: The overall computing time is the sum of:
The main areas which can affect the Server performance are:

Network configuration

Default Network configuration

The default configuration for the Network (if no Network configuration has been defined):

Network configuration improvement

If there are a lot of Buffers sent from the UA to the CDS, it is often a good idea to separate cyclic data from event−driven data. For example: It is not possible to specify parameters for two different Channels directly in the server configuration properties, but in this case defining a network configuration is simple. For example for the configuration properties, the network property allows to specify the XML file defining the Network configuration:

The associated Network configuration could be:
  <channel name="EventDrivenChannel">  
    <direction type="serverInput" port="8080" size="10000" />  
    <direction type="serverOutput" port="8081" size="150" />  
    <layerSet appli="1" />  
    <property key="protocol" value="tcp" />  
    <property key="maximumQueueSize" value="5"/>  
  <channel name="CyclicChannel">  
    <direction type="serverInput" port="8083" size="10000" />  
    <direction type="serverOutput" port="8084" size="150" />  
    <layerSet appli="2" />  
    <property key="protocol" value="udp" />  
    <property key="maximumQueueSize" value="blocking"/>  

Here we have defined two Channels:

Maps updates

Projection update cap

To avoid to be completely swamped by Map updates sent by the UA, the server.projectionUpdateCap property allows to specify at which rate the MapItems coordinates will be updated: This is the minimum time between two projection characteristics changes in Maps. The default is 160 ms, and 0 means that there is no cap at all. If two MapItemList buffers or MapHorz characteristics are received in less than this value, the Server will wait until this time has elapsed to compute the change.
Also, if updates to the MapItems are received before this time are elapsed, the Server will store the associated MapItems characteristics in the received Buffers and perform the compute after the time has elapsed.

Be aware that too small a value for this property (or even setting it to 0, which means that the Server will try to update Maps as soon as it recives the Buffer), can lead to huge performance problems.

Optimizing the Map updates

Contrary to regular widgets, by default the Server considers that if it receives a MapItem in a Buffer, this mapitems has been updated (Even if none of its attributes has changed and its associated item Style has not changed).
It is possible to change the behavior of the Server regarding the MapItems updates with the server.optimizeMapUpdates property: if set to true, MapItems which have not changed in the MapItems Buffer will be discarded.

JVM options

It has been discovered that in some cases the default Garbage Collector used in Java 8 is not ideal when used with the J661 Server (when working with high workloads). The observed general behavior of the default Java 8 GC (named "G1" or "Garbage−First Collector") [1] for a J661 Server is roughly the following: It has been observed than falling back to the CMS (Concurrent Mark and Sweep) collector [2] allows to improve the performance of the application by processing old generation GC much more frequently. For example, the following options are useful: For example, these options can work better in some environments:


  1. ^ See the Garbage-First Collector documentation
  2. ^ See the Concurrent Mark and Sweep Collector documentation

See Also

Categories: dev | performance | server | user

Copyright 2016-2017 Dassault Aviation. All Rights Reserved. Documentation and source under the LGPL v2 licence

Project Web Hosted by SourceForge.net Copyright 1999-2010 - Geeknet, Inc., All Rights Reserved About - Legal - Help