Framework EDI - Performance Evaluation

The purpose for this page is to help users evaluate the performance of EDIdEv Framework EDI.  We will explain its design and features that are related to performance, as well as provide programs to support the underlying principle of the topic.

Performance and Scalability
One of the major obstacles facing a growing business is its ability to handle large EDI files.   When a business starts to implement an EDI solution, it may start with small size files to handle small volumes of transactions.  But as it discovers the potential cost savings of EDI, the transactions will continue to grow as EDI becomes the preferred method of handling transactions with trading partners.  This eventually results in one having to process huge files in magnitudes of 10 – 50 MGB.

Performance and scalability is directly related to the resource of the computer that Framework EDI is running on - largely: the quantity of the resource, and the type of the resource.  In this case, the quantity of the resource is the available memory such as physical RAM, virtual RAM, or hard disk space of the computer; and the type of resource means the type of the hardware that is handling the memory that's running the application such as using SDRAM, RAM Disk, etc.  Because of this dependency to resource, it is possible that an application using Framework EDI will run faster on one machine built by one manufacturer and slower on another machine built by another manufacturer even when the configuration of both machines is exactly the same. 

From its inception, Framework EDI was designed with the problem of handling large files in mind.  The following issues had to be addressed to handle performance and scalability:

1. Physical RAM limitations.  The default setting (Dynamic cursor type) of the FREDI-COM and FREDI-NET components loads the entire document before one can process the document.  So to prevent them from using all the memory resources of a computer, an internal paging system is implemented whereby objects are written to disk as the number of objects reaches a specific threshold.  (The default Dynamic cursor type can be changed to Forward cursor types so that only a few segments of the EDI file (and not the complete file) is kept in memory.  Forward cursor types are the recommended setting for processing larger EDI files.)

2. Different types of Resources.  Computers from different manufacturers with the exact same configuration results in different performance output when the same application is ran on the different machines.  Framework EDI attempts to overcome this problem by allowing the user to control the amount of resources that it can use as well as the frequency at which it will use those resources.

3. Continued enhancements.  As the demand for increasing performance and scalability continues to grow, complexity of the code base also grows, which can create problems in the quality of the product. To address this problem a modular architectural framework has been implemented so that modular processes can be continually improved in performance and scalability without affecting stability and reliability.

For the default configuration of Framework EDI, we recommend at least the following hardware configuration:

• CPU speed: 1GHz 

• Memory: 256M RAM

• Available hard drive: 1GB

From our test cases, we also found this to be the best CPU speed to memory ratio (1Ghz:256MRAM).  For example, a computer with 1.7Ghz, 256M RAM did not show much improvement; but a 2Ghz, 512M RAM improved performance by 100%.   Even with a CPU speed of 2.2Ghz, we found that the CPU was running at optimum, with very little disk activity.  However, we did not consider any database access.  Only when you find that the disk I/O becoming to be a bottleneck to a process should you change the following settings:

1. Paging System Threshold values.

2. Paging System IO Buffer.

3. Paging Batched Objects.

4. Document IO Buffer.

Other settings which can improve performance are:

1. Read-Only Mode.

2. Multi-tasking

3. Forward Only Cursor Type

Paging System Threshold value 

For Framework EDI to overcome the physical RAM limitation on any machine, it implements a paging system whereby objects internally created have to be written to disk when they are no longer used so that it can free up RAM memory for objects required to be read into memory from disk.

It is important to note that the paging system implemented by Framework EDI is not the virtual memory system used by the operating system.  The FREDI paging system is separate and does not use the paging file used by the operating system, but instead uses a temporary file to page objects to and from disk.  This prevents Framework EDI from using all the virtual memory in the operating system’s paging file when it processes large files.

There are many types of objects that are frequently created and destroyed in memory.  The objects represent semantic entities in the EDI standard and they all vary in size.  Each type of objects is maintained by a list that determines what objects are written to disk when a certain threshold value is exceeded.  The threshold value actually specifies the quantity of objects that can be kept in memory and not more.  When this threshold value is exceeded because more objects have to be created, then an object currently in memory that is no longer used have to be written to disk.  Normally for best overall performance the larger less frequently used objects have a smaller threshold value, and the smaller more frequently used objects have a higher value.  Here are the list of objects and their default threshold value:

The threshold value of any of the objects is changed through the Property method of the ediDocument object.  The object type is maintained by a list that belongs to the containing object or parent object.  For example, the transaction set objects are maintained by the group (or interchange),  the data segments objects are maintained by the transaction set, etc.

Example.  To change the threshold value to limit the amount of data segments in RAM,  

Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.Property(Property_RAMObjectSegmentsThreshold) = 1000
:
‘ or
:
oEdiDoc.Property(2007) = 1000

Paging System IO Buffer

Paging objects in and out of disk causes multiple disk I/0 to be performed such that it impedes performance.  To reduce this overhead, an internal buffer is maintained such that when an object is ready to be paged to disk it is stored in the buffer instead.  When another object is ready to be paged to disk, it is again stored in this buffer, and so on.  The buffer is then written to disk when it is full or when an object is paged out of disk.   

How to change the size of the Paging System IO Buffer

The size of the Paging System IO Buffer is changed through the Property method of the ediDocument interface.  The constant is Property_PagingSystemBufferIO.  The default buffer size is 20KB and cannot be set lower than 10KB. 

 Example.  To change the Paging System IO Buffer to 100KB. 

Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.Property(Property_PagingSystemBufferIO) = 100
:
‘ or
:
oEdiDoc.Property(1001) = 100

Paging Batched Objects 

Multiple objects are paged one after the other before any other activity takes place.  This ensures that the paging system I/O buffer is filled before writing to disk, and frees up a larger block of memory in RAM, as well as decreases the number of paging to disk. 

How to change the size of page objects in batches to disk

The number of objects that are batched and paged to disk is a percentage of the threshold value for that type of object.  By default the percentage is zero for all object types, which means that the objects are not paged in a batch, but paged one at a time in real time.  Also, batching can only be implemented if the threshold value of an object exceeds 1000.  To batch objects, set the Property method with a property constant of Property_RAMPagingObjectsPercent in the ediDocument interface to some percentage of the threshold value. 

 Example 1.  To page 20% percent of data segments that are in RAM in a batch, 

Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.Property(Property_RAMPagingObjectsPercent) = 20
:
‘ or
:
oEdiDoc.Property(2000) = 20

Example 2.  To page 5% of all transaction sets in RAM in a batch,

Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
‘ First set the threshold value of the transaction set to exceed 1000.
oEdiDoc.Property(Property_RAMObjectSegmentsThreshold) = 2000
‘ Then set the batch percent.
oEdiDoc.Property(Property_RAMPagingObjectsPercent) = 5

Multi-Tasking

Disk I/O takes a while to perform compared to RAM so operations undergoing disk I/O are placed on a separate thread.  This allows RAM operation to continue on the one thread while disk I/O operation can continue on another thread.  This multi-tasking operation achieves some measure of performance since operations do not get blocked while waiting for other operations to complete.

How to enable Multi-Tasking

To enable multi-tasking, the OptDocument_MultiTasking option in the ediDocument interface is set to 1.  Multi-tasking is not turned on by default. 

 Example 1.  To enable multi-tasking,

 Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.Option(OptDocument_MultiTasking) = 1

 Example 2.  To disable multi-tasking, 

Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.Option(OptDocument_MultiTasking) = 0

Document IO Buffer

 To reduce the number of disk I/O operation when processing a document, data read from the document are first placed in a buffer and processed only after the buffer is full.  Similarly, data that are to be written to a document are first placed in a buffer until it becomes full will they are then written to disk.   

How to change the size of the Document IO Buffer

The size of the Document IO Buffer is changed through the Property_DocumentBufferIO property of the ediDocument interface.  The default (and minimum) buffer size is 10KB. 

Example.  To change the buffer size of the Document IO Buffer to 200KB, 

Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.Property(Property_DocumentBufferIO) = 200
:
‘ or
:
oEdiDoc.Property(1002) = 200

Read-Only Mode 

Another method to reduce the number of execution command and disk I/O operations when processing data is to load the EDI file as read-only.  In this mode, no paging occurs when traversing through the EDI file because data that are retrieved are not kept.  The data of the objects returned during this mode cannot be changed and any attempt to do so will generate an error because in read-only mode, data element values cannot be changed after accessing the data element object. 

How to enable the Read-Only mode

To enable Read-Only, set the OptDocument_ReadOnlyMode option to 1 in the ediDocument interface.  By default the read only mode is turned off. 

 Example.  To enable Read-Only mode,

 Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.Option(OptDocument_ReadOnlyMode) = 1 

Example 2.  To disable Read-Only mode, 

Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.Option(OptDocument_ReadOnlyMode) = 0

Forward Cursor Type

By default, Framework EDI loads the entire EDI document into memory, which can consume a lot of memory, as well as CPU time when it is managing volumes of data between memory and temporary archive files.  This overhead is the cause of degradation, which is relative to file size. 

To stop Framework EDI from loading the entire EDI document into memory, set the CursorType to "Forward Only"  when loading an EDI file.  In this mode, Framework EDI reads the EDI file one segment at a time and does not keep them in memory.  However, in this mode, segments can only be read and cannot be changed.

When creating an EDI file, set the CursorType to "ForwardWrite".  In this mode, Framework EDI commits the documents after each loop, and then removes the committed segments off memory.  It is important to note that in this mode, you would have to create the segments in the EDI file in the correct order since the segments are committed to a file making it impossible to insert prior segments.  Also, if you are creating many small loops and observe that the commits to the file are causing your  hard-drive to "light up" and becoming a bottle-neck, you can increase the value of the "Document I/O Buffer" to improve the performance of the Cursor_ForwardWrite.

How to enable the Forward Cursor Type

To enable the Forward Only Cursor Type, set the CursorType property to 1.  By default the Forward Only Cursor Type property is 0. 

 Example.  To enable ForwardOnly Cursor Type, (Used for reading EDI files)

 Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.CursorType = Cursor_ForwardOnly

 Example.  To enable ForwardWrite Cursor Type, (Used for creating EDI files)

 Dim oEdiDoc As Fredi.ediDocument
Set oEdiDoc = New ediDocument
oEdiDoc.CursorType = Cursor_ForwardWrite

Performance Test Sample Programs

Below are sample programs that we've provided to run on your own machines: 

FREDI-COM

Download GenTest - This program generates a 10MB EDI file in about 7 minutes on a 1GHz computer using FREDI-COM.

Download TranTest - This program translates a 10MB EDI file in about 10 minutes on a 1Ghz computer using FREDI-COM.

Download Gen400 - This is a sample program that generates 400 EDI files with no degradation in performance using FREDI-COM.

Download Tran400 - This is a sample program that translates 300 EDI files with no degradation in performance using FRED-COM.

Download Ack400 - This is a sample program that reads 300 EDI files and creates a Functional Acknowledgment (997) for each one of them with no degradation in performance using FREDI-COM.

FREDI-NET

Download GenTestNet - This program generates a 10MB EDI file in about 8 minutes on a 1GHz computer using FREDI-NET.

Download TranTestNet - This program translates a 10MB EDI file in about 12 minutes on a 1Ghz computer using FREDI-NET

Download Gen400Net - This is a sample program that generates 400 EDI files with no degradation in performance using FREDI-NET.

GenX098_50DBNet - This is a sample program that generate a 1MB EDI files, and repeats it 50 times while keeping the memory page file usage history flat.

(Note: The evaluation copy of EDIdEv Framework EDI has a file size maximum restriction.  To run the File Size Test program, please email support@edidev.com to receive a serial number to remove the file size limitation.)

  Home