Does your business generate 2 billion order lines per year?
Then Openbravo retail is for you!
Wouldn’t it be cool if your business generated 2 billion order lines per year? Probably it doesn’t do it in your case, but still, wouldn’t it be nice if the retail solution you use could handle that load, even if it’s not exactly required?
As we put the final touches on the Openbravo solution for Retail, we have been reflecting a bit on the performance side of the project. This post intends to show how a critical component of our solution behaves, and to analyze a bit how this will benefit the companies which will be using our new POS technology in the future.
The dream we were dreaming: The Openbravo Retail architecture
The most common Openbravo Retail configuration consists on a set of POS (Point of Sale) Terminals, connected to a single Openbravo instance. This instance is a full-fledged web-based Openbravo instance which serves as the backoffice, and stores all your sales orders, alongside all the masterdata (such as products, business partners, …) and the rest of your business data.
The POS terminals can work in two different modes: online mode, and offline mode. When they are online, and a sales order is created, the terminal sends this order to the Openbravo instance. Openbravo receives this order, and processes it, automatically creating all required business objects (the sales order, shipment, the payments), and updating the available stock of the sold products.
If the terminal is offline, however, the order cannot be immediately sent. In this case, the order is stored in a database inside the POS terminal. Once the terminal returns to online mode, the POS terminal sends a batch which contains all stored orders to the Openbravo instance.
It’s clear that the Openbravo process which stores the orders and creates all needed business object must have excellent performance, if we want to support a large organization with a significant quantity of terminals, and a big amount of orders created every day.
As we knew this from the beginning, we’ve built this process with care. We’ve designed a process which is very efficient, and can receive both individual orders, and a batch of multiple orders. This capability is specially interesting when POS terminals become online again, as in that situation, it is very likely that the POS will want to send a set of all the orders which have been processed while the terminal was offline.
The clock keeps ticking: The test
We have designed a number of tests so try to find out if the performance of our order loading process is good enough. In these tests, we will stress the Openbravo instance to levels which are not really reasonable: normal operation of Openbravo should not reach these levels of activity normally. However, as at this point we are only interested in theoretical limits of the architecture, this is probably fine.
We will be showing results of our tests in three different Amazon EC2 machine sizes:
- Small instance: This instance is a low memory, low cpu power instance. We knew before doing our tests that you should not use this Amazon machine type if you need to work with a moderate number of terminals concurrently, but still, it surprised us that it actually worked more or less fine in smaller situations.
- Medium, high-cpu instance: This instance is a low memory, but moderately high cpu-power instance. It packs the same amount of memory as the small instance, but it has the double of virtual cores, and each core is 2.5x faster.
- Extra large, high-cpu instance: This instance has more memory, and four times the number of cores as the medium instance. Each core is as fast as the medium instance cores.
The first test we will describe consists in simulating a number of online terminals connected to the server. These terminals will attempt to create orders as fast as they can, and send them “live” to Openbravo. This test best showcases that we are testing activity levels way above the normal business operation of most companies: usually, even in high-activity situations, a POS terminal should only complete an order every several seconds, or even minutes. Still, this test is very interesting to find out how many POS terminals can be creating orders concurrently.
Let’s see the results:
The times shown are the average time to create an order, measured in milliseconds. It’s quite clear that the small instance has trouble handling more than eight concurrent terminals. However, both the medium and the large instance can handle more than 16 terminals in parallel. It’s also clear that the large instance is scaling a bit better with a large amount of terminals, so our process takes at least some advantage of having multiple CPU cores, even if there are parts of the process which need to be synchronized (such as the update of the stock).
Again, one remark: these results do not mean that Openbravo for retail cannot work with more than 16 or 24 terminals. A human cashier can only process one, two, or at most three or four orders every minute, and these very efficient “virtual cashiers” are processing multiple orders per second, so we are probably looking at many many more terminals in a real case scenario.
To simulate this, we will do an identical test, but just with a large Amazon instance, and with a different behavior in the POS terminals: instead of generating as many orders as they can, they will generate one order every 10 seconds, so that they behave more similarly to how cashiers will enter orders in their terminals. Let’s the results in this case:
In this test, we are able to handle more than 128 terminals with ease!
Not too bad, but let’s see the next test. We will now simulate a different case: let’s suppose we have a POS terminal which has gone offline (for example, because the Internet connection in the Store has gone down). The cashier in the store can still process orders without any problems, but these orders will be stored locally, in the POS terminal. Once Internet comes back, the POS terminal will send all orders to the server in a batch.
But, how much time does that operation take? Let’s see it. We tested how much time did it take to send a batch of 100 orders, each with 10 order lines, so 1000 order lines in total. The results are the following:
So, it takes just 11 seconds to send to the server and process, create the shipment and the payment information for all the 1000 order lines! That’s quite efficient, and if you are a user of our current Openbravo POS solution, you will probably have noticed that it’s a huge improvement over how the old Openbravo POS synchronization worked, which could take hours in a similar situation.
For our final test, let’s think about the worst case for our system. We suspect that the worst case would be to have a big number of POS terminals offline, and to put them online all at the same time. If the terminals have been used to create a big amount of orders, they will each send those orders to Openbravo at the same time, and the server will need to process thousands of order lines in parallel.
So, we will simulate terminals which simultaneously send 100 orders, with 10 orderlines each (so 1000 lines in total, like before), and let’s see how the different amazon machines behave.
In this graph you can see the times in seconds which are needed to process all the orders sent by all the terminals. You can see that a large amazon instance is able to process all the orders generated by 8 terminals in about two minutes and a half. That’s 8000 order lines processed in 161 seconds! (it’s important to take into account that it seems bandwidth started to pay a role in this test, which is the reason for a slightly worse scaling from the previous test; 8000 order lines take quite a bit of space, and moving those from the clients to the server takes its time).
One final remark: the Openbravo instance was accessible at any time while the tests were performed, and was perfectly operable, even in the small Amazon instances, while executing the hardest hitting tests. Windows opened in a short amount of time, and data came fairly quick. Standard operations such as editing and saving data, or filtering in the grid, could be performed without troubles.
All those wasted hours: Conclusions
At some point in this too long blog post, you probably wondered where did these 2 billion order lines came from. It’s very simple to explain: if a single POS terminal generated sales orders as fast as our systems did in our test, an Openbravo instance installed in a large machine would have no trouble processing more than 2 billion order lines in a whole year (assuming a 150 milliseconds per order, and orders of 10 lines). But this number is, of course, just a small joke, which I used to get a more or less catchy title.
The important thing we wanted to share with you is that in Openbravo, we take performance very seriously. Our agile philosophy requires us to do so, and we are very committed to deliver software that performs better and better, and that therefore allows you to be more productive and efficient, and to scale your business as much as you want. The order loader process in Openbravo for Retail is just a small step towards that goal, but we believe it will be an important one, and we hope that you will be able to take advantage of it in the near future.
Stay tuned for more news on Openbravo for Retail, because we are very very excited about it, and very soon we will be showing out many more cool things about it.
