Rifidi Edge Server Scalability and Performance Supported By Retail Scenarios

by Mychal Capozzi (RIT Rifidi Coop/Undergrad Comp Sci) and Matt Dean (Rifidi Lead Software Engineer)

This document will give an overview of some basic scalability and performance data for Rifidi Edge and Rifidi Box Appliance


Four tests were run on different levels of hardware to test the load that the Rifidi Edge v1.2 could handle both with and without business-end computational logic.  The tests were set up as follows:

Two different hardware configurations were used to demonstrate scalability, the first being a Asus Model: EEBox B202 (a netbook like device similar to is bundled with the Rifidi Box appliance)  and the second target machine is a Toshiba Satellite laptop Model: Portege r700-S1320 (the more powerful of the two machines running with an Intel Core i5 (Dual Core Hyper Threaded) @2.4ghz ).  Two software configuration scenarios were set up on the machines, the first to demonstrate the performance of the Rifidi Edge Server’s ability to process tag events purely in memory and the second to demonstrate the Rifidi Edge Server’s ability to process tag events and persist to a database (in this case MySQL v5.1) on the same machine. In all the test scenarios a separate machine is used to execute the simulated the virtual LLRP readers and tag rate scenarios. The product used for simulation is Rifidi TagStreamer v1.1.1 and the machine TagStreamer executed on is an dual-core, dual threaded 2.4 GHz processor. The simulated environment contained 4 LLRP readers, each with a single antenna and single read zones.  The throughput time from one reader to the next was set one one millisecond, to simulate each of the four readers receiving their load almost simultaneously. Various numbers of generation two GID96 tags were sent across all four reads in bursts over one second, with a one second cool down between bursts for one to two minutes while data was collected.  The tests were designed to be limited by buffering of tags by either Rifidi Edge Server or MySQL, to verify that a given load could be sustained over long periods of time.

Note: All testing for these four scenarios were over a wired Ethernet 100 MB network. More readers could have been used but for simplicity in setting up the scenario 4 LLRP readers were used with a higher load and frequency of tags within the antenna range.

More details for both hardware configuartions can be found in the summary results table below.


The first machine used an Asus appliance, Atom n2700 single core dual-threaded processor, Ubuntu 10.4 operating system, 1 gig of ram, 160 gig hard drive and is the basic platform recommended for use with the Rifidi Box appliance.  Without the database writes of every tag seen, the edge server on the aforementioned hardware was capable of seeing between 350 and 450 tags per second with minimal buffering. With the database write enabled, the Rifidi Edge was capable of receiving bursts of 75 to 125 tags every second.

The second machine, based around a consumer-level test, was a Toshiba Satellite laptop with an Intel Core i5 @2.4ghz with 4 gigabytes of ram running Linux Mint 10 (based on Ubuntu 10.10). When the database writes were disabled, Rifidi Edge was consistently reading 2200 – 2300 tags per second. With the database writes occurring, the read rate was closer to 600-700 tags per second.

As far as CPU consumption, on the Asus machine with the Rifidi Edge Server processing tag events in-memory, the CPU reached 65-70% consumption. When including the MySQL database, the Rifidi Edge was consuming much less; closer to 45% of the CPU. The database was consuming close to 25% while this test was running.

The Toshiba Satellite machine CPU in-memory test was 80%, but once the database test began, that consumption dropped to 65%, while the database was consuming no more than 35% of the CPU.

Calculating RAM Usage:
RAM usage between the two was minimal, not surpassing 250 Mb.  Additional readers were established to estimate how much RAM would be required to support each additional reader, and it is estimated to be .1 Mb (100 Kb). This value is platform independent.   Additionally, we estimate that tag’s memory usage is variable depending on the tag type, for these tags it was negligible at less than 1KB each.  This estimate was reached by firing 200 tags over 200 milliseconds at the Atom machine and measuring RAM consumption during the test until negligible fluctuations were measured, and then comparing that amount to the Rifidi Edge without receiving any tags.

Scalability with Retail RFID Business Case Scenarios:

Based on the load-tests described above, estimates can be extrapolated to account for various reader and tag rate environments.  Given the following three retail scenarios described in detail below, we were able to size the necessary hardware requirements based on the scalability testing results above prior executing the simulation using Rifidi TagStreamer v1.1.1 on the same constant machine and Rifidi Edge Server v1.2 on the Toshiba Satellite laptop.

The Retail Scenarios:
A Department store has recently been outfitted with RFID readers on it’s dock doors, shelving units, and at the sales counters.  On an average day they process hundreds of thousands of individual items from the dock doors to the sales counters, and with the use of RFID tags, keeping track of inventory has become completely automated.  There are three defined areas where tags should be seen and a defined flow of events, they are:

1) There are five loading dock doors, each receiving 1000  tagged items every 30 seconds to 3 minutes.
2) There are 35 shelving units each receiving 50 tagged items every 15 seconds to 2 minutes.
3)There are ten points of sale, each receiving 10, 25, or 50 tagged items every 30 seconds to 2 minutes.

So using the Rifidi Edge software to process the tags and Tag Streamer to generate the tags on a separate machine, the following data was collected:

Edge Server Data:
-Top CPU usage: 75%
-Top RAM usage: 20%
-Avg CPU: 50%
-Avg RAM: 15%
-Network speed: 100 Mbps
-Total LLRP Readers used in testing: 50
-Test Duration: 18 hours
-Average tag events per second including database persistence: 107
-Peek bursts including database persistence (Tags events/per second): 336
-Total tag events processed by the Edge Server and persisted to MySQL in 18 hrs: 6,621,280

End results:
Based on the performance of the Toshiba Satellite laptop under the strain of the simulated environment, we are able to conclude that the Rifidi Edge can handle the requirements for a real-world deployment, but performance could be notably increased by separating the Database from the Rifidi Edge onto two separate machines, as the Database ended up being a bottleneck during bursts of 1,000 or more tags.

Setting up the Retail Scenario in your Environment:

Hardware Requirements:
One computer (at least an i3 processor) to run three Rifidi TagStreamer instances
One computer (at least equivalent to the Toshiba i5 above) to run the Rifidi Edge Server and MySQL Database

TagStreamer can be leveled across three computers each running one instance of TagStreamer for each test case scenario Note: The Rifidi Edge Server configuration will need to  be configured to connect to three separate IPs. (The first 5 IPs will point to the Tag Streamer instance invoking the Loading Dock scenarios, the next 35 IPs will point to the Tag Streamer instance invoking the Item Level Shelves scenarios and the last 10 IPs will point to the Tag Streamer instance invoking the Point of Sale scenarios).

The MySQL Database can be installed on dedicated Database Server hardware. Note: This will require the Retail Application running on the Edge Server to point to the Database Server IP address. Also make sure you have at least 100MB network bandwidth and on the same sub-net as the Rifidi Edge Server

Software Installation Requirements
MySQL  v5.1 – www.MySQL.com
Rifidi Edge Server v1.2 – www.rifidi.org
Rifidi Tag Streamer v1.1.1 – www.rifidi.org
Retail Rifidi Edge Application (Retail)
Events MySQL table – events.sql – used to store tag events during scenario execution
Rifidi Edge Server configuration (rifidi.xml)
Rifidi Tag Streamer configurations (TS_Retail_5_LoadingDocks.xml, TS_Retail_35_ItemLevelShelves.xml, TS_Retail_10_PointOfSale.xml)
Retail Scenario download: http://www.transcends.co/wp-content/uploads/2011/05/Retail.zip

Setting up the Scenario
Note: More details on how to use the Rifidi platform can be found at wiki.rifidi.org

1) Start the first Rifidi Tag Streamer instance and click on File|Load Test Suite to load the TS_Retail_5_LoadingDocks.xml. Note: Make sure to change the IP addresses in the configuration file to the IP address of the computer running this Tag Streamer instance and File|Save Test Suite.

2) Start the second Rifidi Tag Streamer instance and click on File|Load Test Suite to load the TS_Retail_35_ItemLevelShelves.xml.Note: Make sure to change the IP addresses in the configuration file to the IP address of the computer running this Tag Streamer instance and File|Save Test Suite.

3) Start the second Rifidi Tag Streamer instance and click on File|Load Test Suite to load the TS_Retail_10_PointOfSale.xml. Note: Make sure to change the IP addresses in the configuration file to the IP address of the computer running this Tag Streamer instance and File|Save Test Suite.

4) On the computer running the Rifidi Edge sever, place the  rifidi.xml configuration file in the [Rifidi_Edge_Home]/server/config directory.  Note: Make sure to change the IP addresses in the configuration file to the IP address of the computers running this Tag Streamer instance and the equivalent scenarios.

5) Copy the Retail Application into the Rifidi Edge server’s [Rifidi_Edge_Home]/server/applications directory. In the [Rifidi_Edge_Home]/server/application/Retail/database.properties file verify the com.emaise.jdbc.url=jdbc:MySQL://[MySQL_IP_Address]/emaise is set the the ip address of the MySQL 5.5 DB server instance, jdbc.user=root is set to the correct MySQL user and jdbc.pass=rifidi2010 is set to the correct MySQL password.

6) Start the Rifidi Edge Server and verify the MySQL Database Server is running

7) On the MySQL Database Server instance, verify the Retail database has been created, the events table has been created and at the start of each test delete all the records from the events table. Note: For use of the MySQL 5.5 Database please refer to www.MySQL.com for user documentation. – Use events.sql script to create events table.

8 ) After the Rifidi Edge Server starts, on the Edge Server console type loadApp Retail to start the Retail Application

9) For each Rifidi Tag Streamer instance, click on Test Units then click on TestUnit1  and on the menu bar click the run icon to start the Test case scenario. Note: You will need to repeat these steps for each of the three Tag Streamer instance.

10) To verify that the Retail Scenario is operating correctly, first on the Edge Server console type and readers and all 50 LLRP reader adapters should be in processing status, second monitor the cpu and memory usage on all the computers to verify CPU does not exceed 50% – 90% and memory does not exceed 50% available.

11) After you decide to end the test as the test cases are configured to run indefinitely so you will need to stop execution manually, the results can be analyze by querying the Retail Application MySQL 5.5 database. DB name: Retail. Table name: events. Note: For instructions on how to use MySQL 5.5 please refer to the www.MySQL.com documentation.

Future Planned Rifidi Edge Server Testing:
Future tests with the Rifidi Edge Server will include scalability and performance writing to a queue (JMS), web services, Software as a Service (SaaS) and in a Cloud.

Rifidi Edge Server Product Distribution Sine 10/2009 Release: Over 10,000 Downloads Across 119 Countries


Country Downloads
1. China 2,616
2. Brazil 1,063
3. India 898
4. United States 769
5. Italy 311
6. Germany 230
7. France 213
8. Spain 211
9. Colombia 194
10. United Kingdom 162
11. Canada 145
12. Malaysia 145
13. Korea 137
14. Taiwan 133
15. Venezuela 117
16. Thailand 111
17. Portugal 100
18. Viet Nam 99
19. Netherlands 97
20. Egypt 84
21. Turkey 78
22. Philippines 76
23. Poland 74
24. Mexico 71
25. Indonesiatd> 69
26. Argentina 62
27. Greece 55
28. Iran 50
29. Tunisia 49
30. Peru 48
31. Singapore 47
32. Belgium 46
33. Hong Kong 44
34. Australia 41
35. Algeria 40
36. Lebanon 38
37. Iraq 36
38. Morocco 35
39. Ireland 35
40. Japan 35
41. Russia 33
42. Saudi Arabia 32
43. Romania 32
44. Pakistan 30
45. Chile 28
46. Slovakia 26
47. South Africa 24
48. Finland 20
49. Lithuania 19
50. Trinidad and Tobago 19
51. Nigeria 18
52. United Arab Emirates 17
53. Denmark 17
54. Croatia 17
55. Kenya 15
56. Latvia 15
57. Serbia 15
58. Europe (specific country unknown) 13
59. Satellite Provider 13
60. Norway 12
61. Sweden 12
62. Switzerland 12
63. Uruguay 12
64. Czech Republic 11
65. Anonymous Proxy 11
66. Slovenia 10
67. New Zealand 10
68. Benin 10
69. Nicaragua 10
70. Austria 10
71. Ivory Coast 8
72. Estonia 8
73. Jordan 8
74. Macedonia 8
75. Ethiopia 7
76. Ukraine 7
77. Brunei Darussalam 7
78. Panama 7
79. Asia/Pacific Region (specific country unknown) 7
80. Nepal 7
81. Israel 7
82. Sri Lanka 7
83. Namibia 7
84. Bolivia 6
85. Bosnia and Herzegovina 6
86. Bulgaria 6
87. Hungary 6
88. Malta 6
89. Syria 6
90. Uganda 5
91. Kuwait 5
92. Myanmar 5
93. Bangladesh 4
94. Martinique 4
95. Jamaica 3
96. Palestinian Territory 3
97. Cuba 3
98. Dominican Republic 3
99. Libya 3
100. Mozambique 3
101. Ecuador 3
102. Belize 3
103. Sudan 3
104. Cambodia 2
105. Oman 2
106. Rwanda 2
107. Bahrain 2
108. Congo – Kinshasa 2
109. Cyprus 2
110. Ghana 1
111. Guatemala 1
112. Afghanistan 1
113. Senegal 1
114. Andorra 1
115. Puerto Rico 1
116. Isle Of Man 1
117. Iceland 1
118. Zambia 1
119. Guadeloupe 1

The Art of Turning an Idea Into a Solution in an Emerging Market

The challenge many are faced with when new technologies emerge in the market place is always centered around how to use the technology to solve a business problem, demonstrate this to a business sponsor within a limited budget, where to acquire or build the skill set and what technology to use. Many times because the fact a technology is emerging  there are a limited number of experiences in the market place to leverage,  limited selection, proprietary, difficult to access  and the question on how stable, flexible, scalable, viable and cost effective is the technology needs to be answered.

The approach to be taken is very much a art form. Just like painting a picture there are many perspectives, techniques and potential outcomes with not just one being correct. The key is to enable the creative spirit but as a group converge upon a answer that leverages each members unique skill set and create a solution which makes a statement having impact. When a new technology comes about such as the personal computer, internet, smart phones and RFID alike there are many ideas on how this technology can be applied to solve existing business challenges, create new business opportunities and revolutionize our society. The keys to enabling an emerging market to be success is to make adoption of and access to the technology as simple and seamless as possible, provide a forum where people can collaborate on their innovative ideas, rapidly demonstrate the power of the technology to bring a solution to life and most importantly provide business value where all in community can benefit from the overall capital return (intellectual, monetary, partnerships, impact on society….).

Pramari has been focused on these principles for over 5 years now by being the key sponsor’s of Rifidi. During this period of time we have seen many ideas evolve now into pilot and production systems where the business is beginning to see value. We are seeing the realization of the importance of bringing solutions to the market place rapidly and as a collaborative effort. This is typical in a emerging market place where there are many companies each with their core competencies that need to work closely together to deliver a solution.

For those who are attending the RFID Journal Live 2011 Event in Orlando, FL April 12-14 feel free to stop by the Pramari Powered by Rifidi booth # 242 and Argo Wireless booth # 449 to see a couple examples of production solutions brought to life through a collaborative effort powered by the Rifidi Open Source RFID platform. These solutions will demonstrate how the Rifidi community can work with you to bring your idea for a sensor based RFID business solution to life.

RFID Middleware: Build vs. Buy

Early on in any IT project architects need to decide which software
products best solve their business problems. “Build versus Buy”, and if
“Buy” what are the best and most efficient products. In principal any IT
problem could be solved and coded using even Assemblers. In the early
90s, people used C/C++ for their early internet systems. Yes, no one
would even think about such choices anymore. We long have learned to
rely on Java, Web Servers, and Application Servers. They are geared
towards Internet problems and come with much functionality out of the box.

Looking at RFID business problems, it has not been so clear in the past.
Many existing systems are “Build” type solutions for which developers
use .Net or Java and are accessing RFID readers’ API directly, trying
to build a minimum level of infrastructure code to address some key
technical requirements. I bet there are thousands of those individual
“infrastructure” implementations being used right now. Some of them
present an enormous maintenance burden.

What are our key requirements for RFID platforms products? Surely, they
have to address connectivity to RFID readers, also sensors if possible.
Data come in real time, often in volumes that are not predictable in a
reliable way. RFID data are basically read events that need to be
filtered and transformed into business events. This is similar to
processing requirements of high volume financial systems. Credit card
processing systems that obtain a high volume of events need to correlate
such basic events into business events and trigger actions. RFID systems
are inherently event-driven. They can very much benefit from
event-processing engines such as Esper. Those systems allow to filter
and process RFID events in memory and in real-time. They provide event
correlation, for easy detection of business events from low-level RFID
events. Esper, for instance, provides time-based queries, making it easy
to detect for example if an item has been in a zone for too long.

Another key requirement is based on the light-weight environments we
typically want to build. RFID systems are on the edge on the enterprise,
and as such need to run and perform on inexpensive hardware. Heavy
application server architectures are a fundamentally wrong approach. The
IT industry recognized this problem several years ago and defined OSGi
as a common standard for such appliances. It is being used in
refrigerators, and many day-to-day appliances that are produced in high
volumes; a nice, light-weight and flexible industry standard that avoids
the burden of for example having to run application servers on a small

In summary, requirements for RFID platform products being used for IT
projects have many clear and common characteristics. Sufficient and
appropriate RFID Reader adapters, being able to handle high volumes of
load, event processing engines are some key criteria. In addition, the
product needs to be open enough so developers can use their trusted
development environments. A last, but very important criteria is the
light-weight approach that RFID systems and appliances can use in order
to keep hardware cost to a minimum. After all, appliances should run on
the edge of the enterprise, easy to maintain, and with low hardware
costs, but in high volumes. RFID systems that meet those requirements
will help the industry advance and become standard software. No need to
build your own RFID platform anymore.

One man’s view on the definition of Edge in RFID middleware

Being in the RFID industry for 5 plus years and in the middeware space for over 10 years I have seen many definitions and usages of the term edge in reference to RFID middleware. After speaking with many clients and system integrators as well as being part of and developing RFID/sensor based solutions I have come up with what edge is today and what it will mean as the market continues to grow and mature.

The pure definition of edge used as a noun is “a line determining the limits of an area“ and used as a verb is “to provide with a border that can be useful and be reached within a duration of time“ . Using these definitions as a foundation and applying these definitions to the RFID/sensor marketplace with a focus on creating business value I have formulated my vision of an edge server.

First I will start with the noun portion, boundaries of an edge server. The boundaries of an edge server depends on the sensor area you are attempting to monitor, filter and provide business value to a consumer. A consumer could be a user interface, device, enterprise system, repository etc…It’s basically at the point where you are able to leverage sensor information to orchestrate sensor events necessary to provide business events within the consuming applications domain. For example, a edge boundary could exist strictly at the point of sale system device or could go as far as looking at information across a multitude of sensors in a cloud. The factors in my opinion that go into determining what are the limitations of an edge depend of the volume of data to be processed, the richness of data required across sensors and at what point do you converge on translating this information into valuable business events such as answering the who, what, when, where and why questions required by the consuming application.

Secondly now I will look at from the vantage point of the verb aspect, “to provide with a border that can be useful and reached within a duration of time ”. So once you have defined your edge boundaries now the key element is to provide useful information to your consuming application and the useful information is obtainable within some duration of time. I firmly believe this is a key aspect to an edge server is that it must be able to process information in a timely manner as defined by your edge boundary and turn this information into something that can be used to trigger or make a business decision.

Is RFID Finally Hitting the Masses?

By Juan Carlos Ramírez (IDLink Solutions)

As an RFID entrepreneur I’ve followed closely probably all of the RFID and sensor technologies in the last 3 years of my life. Being part of this exciting emerging technology makes you think about how “smart” things and objects will change the world and the way we live our everyday lives.

Among all of the potential RFID uses, I guess it’s natural to wonder which one of those will be the one to impact the end user in a greater and most significant way. In my opinion I think NFC technology, which is pretty much RFID for the mobile phones, is the one poised to dramatically change the RFID landscape. Giving access to product information to the end consumer could be huge. Your mobile phone could now be your credit card, your car keys and more. What about using it to access information about products in your preferred store? Wouldn’t that be great.

Last week, the most important Telco companies in the US made a major announcement. They decided to join efforts to push towards NFC adoption by creating a payment services company. This announcement was followed by Google’s CEO presentation of the next Android NFC enabled phone, not to mention Apple’s and RIM’s plans towards the same direction.

Now, this opens a whole new debate and a very interesting one by the way. NFC operates under in HF instead of UHF, which is probably the most popular RFID technology for industrial and supply chain operations. Will NFC make HF win over Near Field UHF for item level applications?

In the end, I think we are evolving towards a smarter world. Things will be interconnected and big streams of information will flow in all directions. How are we supposed to handle all that information? That’s where RFID middleware will come into place.

Dataflow and the Rifidi Edge Server

This is the first in a series of blog posts that give a technical overview of the architecture of the Rifidi Edge Server.

The most basic (and important) function of the Rifidi Edge Server is to collect data from sensors, filter them, and deliver them to systems that use the data for business processes.  This diagram gives a high-level depiction of how data are collected and flow through the edge server.  The data begin their journey as they are produced by sensors.  While these sensors are normally hardware RFID readers, such as an Alien 9800, Symbol XR400, etc, data might also be produced by a legacy barcode reader, a database, or even another edge server.  The Sensor Abstraction Layer provides a way for users to develop their own plugins for their custom sensors.

As data are collected from the sensors, they are pumped into a high speed internal message bus through which other internal edge server components can access them.  Because sensors have the ability to produce an enormous number of events, users normally want to filter them.  The Application Layer Events (ALE) specification from EPCglobal provides a standard API for collecting and filtering RFID data.  The Rifidi Edge Server has an implementation of the ALE 1.1 specification.  Internally, the ALE layer uses an event stream processor called Esper to collect data according to the ALE rules.

Some users will decide that they do not want to use ALE in their solution.  Because the Rifidi Edge Server is built on an extremely flexible architecture, they can create a custom data collection layer and hook it up directly to the internal message bus.

Future architecture posts will describe other aspects of the Rifidi Edge Server in more detail.

What’s in a Name?

Going into the RFID Journal Live trade show, I assumed that I had spent the past eight to ten months of my life developing an edge server — a piece of middleware that connects to RFID readers, collects data from them, filters the data, and pushes the data up to a higher level business application. Was I ever wrong. What I had actually been working on was an application platform. Talking to all the people at the trade show reminded me once again of just how general of a technology RFID is. Not only are there many classes of deployments (RTLS, inventory, supply chain, asset tracking, etc), but even within similar classes, deployments differ greatly depending on all kinds of variables — from the physical layout of a facility to the IT infrastructure that is already in place — that are unique to that situation.

Because there is no such thing as an off-the-shelf RFID deployment, middleware that is not completely malable is unuseful. This is why describing Rifidi Edge Server as simply an edge server is limiting; it implies that Rifidi Edge Server is a static piece of software. Describing it as an application platform, however, better captures how it will be used in practice. Much like JBoss is not so much an application server as it is a platform for building J2EE solutions, Rifidi Edge Server is more of a platform for constructing RFID applications rather than a solution in and of itself. In deployments, Rifidi Edge Server will be used as a core that provides a base set of tools and functionality that developers will tailor to their particular needs by writing extensions and plugins to it.

You might say that the difference between describing Rifidi Edge Server as an ‘edge server’ or as an ‘application platform’ is simply a marketing device. But to me, as a developer, it represents a fundamental difference in how I view the code. Before the show, I knew extensibility was a priority; now I know it is vital. With this refined viewpoint, I am looking forward to the next few months.