From time-to-time I'm asked about the performance and scalability of uniCenta oPOS which is often difficult to answer because there are so many variables, so I'm constantly on the look-out for anything that can give me a heads-up.
I found this topic by Justin Buist in one of the Openbravo forums and decided it's definitely worth sharing and I think you'll find his results are quite amazing!
p.s. here's the link if you want to go visit the original post: http://forge.openbravo.com/projects/openbravopos/forum/viewtopic.php?f=434920&t=7026585&sid=bbb58b07f5e515f50257086752622925
I thought I'd share this with the group.
When I turned down a quote from a commercial POS vendor and told him I'd be rolling out OBPOS he expressed some concerns about the software not treating the DB nicely and overloading it with our "high" traffic -- 38 lanes, up to 8,000 potential tickets a day.
I didn't put much stock in his concerns, but thought I'd test them out anyway. So, I loaded up OBPOS/MYSQL with the product list from our existing MS RMS 1.3 database (21,000 products), built 10 lanes running Linux as the OS, exported our current record highest day of sales from a single register's 12 hour day, scripted that data out into a shell script that ran a series of 'xte' commands to simulate keyboard/mouse commands, figured out about how fast the software could respond with some extra padding (0.5 seconds between scans, 3 second delay before hitting tender, 1 second to move to the 'cash' tab, half second delay, enter $1000 as amount tendered, hit OK, wait 3 seconds then start the next order.
And then I stuck all 10 lanes running that shell script into an infinite loop. Each loop completes in about 1 hour. So that's 12 hours of actual sales compressed down to one hour. With 10 registers running that fast it's about like having 120 actual lanes with real people and real customers pushing them along. I had to reboot the registers after 36 hours, because the audio layer got mucked up (custom code, not stock OBPOS, I play a "beep" WAV every time an item scans and an "Error" WAV every time an item fails lookup) but after 5 days I had 180k transactions in the OBPOS database which is what we'll do in our 8 week busy season.
Pretty comforting to know that it can handle compressing 8 weeks of sales into 5 days and not miss a beat. Heck, the load average on the MySQL server never went above 0.30, and that silly little test box is also running DHCP/SVN/DNS/Apache.
The real kicker is that it's just a dual core Atom box, same as my registers, with a single SATA 5400RPM drive and 2GB of RAM in it. I'd probably have to scale up to simulating 300-400 lanes before even THAT thing choked.
Pretty sure the quad core Opteron@3.0Ghz with 5 15k drives in RAID-5 and 32GB of RAM I've got racked up and ready to go will handle our load just fine, but I'm going to test it anyway, because this kind of testing is fun!