Virtual Machines are a great way to test stuff or use valuable tools in a separate environment. Think of test driving an OS, like Ubuntu 12.04 or Windows 8. Other examples include using pre-build appliances to use Oracle SOA Suite and BPM or WebLogic Server and Java tools.
Improve VirtualBox appliance performance
These Virtual Machines can be quite demanding for resources on your PC or laptop. Fortunately there are ways to speed up VirtualBox appliances. Besides increasing the allocated CPU power and RAM there are a few less expected things you can do:
- Create fixed size disks – A preallocated disk will have less fragmentation. Adding of files to the virtual disk will be faster (spaces is already reserved). The downside is that a fixed-size disk uses more space on your hard disk.
- Exclude the Virtual Machine directory from the virus scanner – Scanning there from the host isn’t very useful either. So add this directory to the exclusion list.
- Put the VirtualBox files on non-system disk – Put the VirtualBox files on a non-system disk. The virtual disk and your hosts’s OS won’t be competing to read from or write to these same disk.
- Make shure the Intel VT-x and AMD-V setting is ON – These are processor extensions that improve virtualization performance.
In today’s post you can find out why you need a changelog, and what activity to add to your upgrade roadmap.
After a recent upgrade of SOA Suite to a more recent patch level, we saw errors that some of us vaguely remembered. They were traced back to transaction timeouts in the BPEL Server. Searching Metalink, OTN, and of course Google we found out we had to change the
min-instances in the
orion-ejb-jar.xml. More detailed information on these settings can be found on in the SOA Suite best practises. However they are not in the spotlight of this post. So let’s go back to the main story.
At that time it seemed strange that the suggested values in the documentation, and as mentioned in blogposts, conformed with the ones we thought set in production.
Need for a changelog
Fortunately we have a changelog. We checked it, and indeed the values should correspond. We set these during a previous tuning effort. Time to check the actual
orion-ejb-jar.xml in the production environment. Oops! During the SOA Suite upgrade our fine tuned
orion-ejb-jar.xml was overwritten with one with default values 🙁
What can you learn from our experience:
- Maintain a changelog – also for configuration settings;
- Include a post upgrade action in your plan to check whether all tuning and other configuration settings are still at the appropriate values;
- Oh, and by the way, keep your test environment in sync with production (including all configuration settings)! So all this can be well planned and tested before the actual go live.