Posts Tagged ‘Performance’
Let’s say you’ve been working hard customizing Openbravo for a customer. And now you’d like to deploy it, so that the customer can start using it immediately. Next step? You go ahead and start installing the ERP on a server… wait! Not yet! You first need to think about the hardware, don’t you? Not so relevant nowadays? A commodity? Try to answer these questions and you’ll see why it matters:
- How many employees does the company have?
- From these employees, how many of them will use the ERP?
- From these users, could you classify them depending on the amount of time and intensity they’ll devote to the ERP?
- How do the most typical user flows look like? Standard ERP flows? Customized ones? Heavy report generation or long processes?
As you can imagine the hardware requirements differ quite significantly depending if you need to support 5, 20 or 100 concurrent users.
And let me ask you two additional questions:
- Do you care about saving costs?
- Do you like the feelings (aka headaches) arisen when you notice that your server just cannot cope with all the requests in the ERP? Imagine you’ve just bought some new hardware and it’s not enough. Even worse, the customer can no longer work under those conditions, they’re unhappy because of having to buy new hardware again and they do not trust your abilities to choose the right hardware this time.
“Well, of course I care about costs, my time and the service level I provide to my customers! Are you kidding?”
OK, I might have dramatized it a bit. Have I? If you’ve ever participated in an ERP implementation process, you’ll know that these things happen. Obviously no one chooses to consciously increase the project’s costs, look for headaches and decrease the overall customer satisfaction. But these might be some of the consequences of incorrectly sizing your Openbravo installation.
Sizing? Sizing, you say? A sizing is an approximation of the hardware resources required to support a specific software implementation, in this case Openbravo. And I have good news for you, for all these inconveniences can be avoided by using the Sizing Tool we’ve just developed for you!
In a nutshell, you simply tell the tool how many concurrent users you want to support and it tells you what hardware you can use. And in case you want to calculate it using your own flows, it’s enabled to allow that as well.
To give some of the behind the scenes details, we have written test cases for the most common Openbravo flows using a performance benchmarking tool called JMeter. This, summed to our experience with real customers has outcome in the Sizing Tool and Guidelines.
Additionally there’s some interesting data we have proved with this tool. For instance we’ve been specially pleased to see that Openbravo supports 100-250 concurrent users without a hitch (given the proper hardware, of course).
Being Openbravo ERP a web based application, using SSL is currently a must for those who appreciate their privacy. Think about the kind of data that is transferred in an ERP: customer details, transactions with business partners, invoices, balance sheets, etc. Not using SSL basically exposes all this information to anyone around with a network sniffer.
This article assumes that you already have a working Openbravo ERP installation, using the following software stack:
- Apache Tomcat 6.0.x with the Tomcat Native libraries, version 1.1.x.
- Apache httpd web server 2.2.x with mod_ssl.
- The mod_jk 1.2.2x connector for the Tomcat and httpd integration.
If you try to use Openbravo ERP with the default configuration, then you will find some problems. Namely:
- All the reports generated by Jasper Reports don’t work, displaying an error such as the following one:
- It’s slow. Noticeably slower than running it under plain HTTP, as if every request took an additional time of 100ms and 1 s, and as if nothing was being cached.
09:23:59 [ajp-8009-3] WARN org.openbravo.erpCommon.utility.ErrorTextParserPOSTGRE - did not find constraint name for error message: Error loading byte data : https://localhost:4443/openbravo/web/images/CompanyLogo_big.png
Needless to say that these are showstopper issues, because the first one prevents you from e.g. printing invoices and the second one makes it very unpleasant. Let’s fix these issues.
The first error is caused by the fact that the Java process that generates the reports requires some images located at a SSL protected URL of your server. And it doesn’t trust the provided certificate, so it fails. Actually this is supposed to be a feature, because it’s verifying that the site is really who it claims to be. There are two ways of solving this. The first one requires buying a SSL certificate from an approved provider and it’s appropriate for production servers. The second one doesn’t require to buy anything, and it’s suitable for testing servers.
For production servers:
- Register a (sub)domain name for for your ERP, e.g. openbravoerp.mydomain.com
- Buy a SSL certificate for openbravoerp.mydomain.com. You can find them for ~$70/year.
- Register openbravoerp.mydomain.com in the internal DNS server of your LAN, in case the server is hosted in-house. If you don’t have one, it’s time to set it up. There are tiny DNS servers that take no more than 5 minutes to install and set up.
For testing servers:
- If it’s going to be exposed to the Internet, register a (sub)domain name for the ERP in a free DNS service, such as DynDNS, e.g. erp-atlantis.dyndns.org
- Generate s self-signed certificate using OpenSSL.
- Import the SSL certitificate into the local JDK. Go to a command line terminal, download the InstallCert utility and run the following commands:
- Restart Tomcat to apply the changes of the previous step.
- For using the ERP in your LAN, register erp-atlantis.dyndns.org in your internal DNS server.
javac InstallCert.java java InstallCert erp-atlantis.dyndns.org cp jssecacerts $JAVA_HOME/jre/lib/security
There are two separate issues regarding slowness. First of all, the web browser starts a new SSL negotiation in every request, adding a 100ms-1s delay to every single request. To fix this, make sure your Apache httpd configuration has the KeepAlive option turned on:
KeepAlive On MaxKeepAliveRequests 200
In this case we have also doubled the number of allowed alive requests, because it is expected that this numbers grows as we now allow persistent connections.
The second issue is related to the cache. SSL does not store cache in disk between sessions, for the sake of security. But there is a performance penalty. So this a trade-off you need to decide. To make Apache httpd save the cache between sessions, we need to set the Cache-Control header to Public. This can be achieved by using the mod_headers module:
Header unset Pragma Header append Cache-Control "public"
I want to thank katratxo for finding the solution to the cache issue.