Has anyone ever heard of installing multiple instances of webMethods 6 IS on a single server to increase performance? If so, were there any issues and what was the average increase in performance? Also, outside of modifying code are there easy ways to increase the runtime performance?
JVM - 1.3.1 versus 1.4.1
JVM Settings
Server/OS - HP(Unix) versus Intel(Windows,Linux) versus Sun(Solaris)
Phil,
Personally, I wouldn’t expect to see a big performance boost by installing multiple IS’s on the same box. They’re sharing the same system resources, so I don’t see much value-add there. However, I do think you’re on the right track looking at system configuration changes.
You should be aware of things like kernel parameters, OS patches, and (as you noted) JVM versions and settings. While the choice of OS itself may have some performance implications, you can most likely tune your selected OS appropriately to get it in line with your requirements. As a general recommendation, I’d suggest you check out some of the performance and scalability whitepapers on Advantage. They should give you a good idea of what each OS vendor has done to optimize IS performance on their platform.
I have heard that the 1.4.1 JVM is supposed to have some nice performance tweaks, but can’t attest to that personally yet. Certainly, you’ll want to be sure that you’re starting whatever JVM you use with the right parameters, especially making sure you’ve allocated enough RAM to the JVM.
Lastly, there are configuration settings within IS (not involving code) that can dramatically impact your performance. For example, if you’re using TN you’ll most likely want to ensure you’re not saving the entire contents of inbound documents. You should also turn logging down to a minimum. Validating XML inputs unnecessarily can slow you down. Etc. HTH.
Thanks so much for the response. I have been leaning heavily towards tweaking the OS, JVM, and IS settings versus installing another instance of webMethods. The reason that I am asking about this is that installing multiple ISs was recommended to me by a colleague who seemed to think that it was definitely the way to go.
I would like to play the devil’s advocate for a moment and ask the following question of you and the rest of the webMethods community:
Could installing multiple ISs on a single machine more effectively use the available system resources? Essentially, are two JVMs better than one?
In my mind you would benefit from multiple instances of IS but in a clustering/load balancing mechanism when the instances are on different machines. Putting 2 instances on one machine to me would degrade performance because you now have 2 processes, 2 jvm’s, more total RAM used, etc. However I can’t back up my statements with real test results but whenever IS has been shared with other non-IS processes it has degraded IS performance for us.
I can’t imagine two JVM’s running on the same machine being better than one. Java’s use of CPU time would be one of the issues facing two JVM’s. Lots of memory is another factor. I’m sure other will lend their opinion.
Generally IS is CPU bound. Recent JVMs seem to scale well at least to 4-CPUs. If you have a box with >4 CPUs it may be worth looking at partitioning multiple instances of IS to sets of 2-4 CPUs each.
Thanks a million for all of the responses. You have confirmed what I initially thought.
I now have a curve to throw you. What happens if there is a Broker in the mix? If I understand correctly, a single IS can only point to a single Broker. So what do I do if I need to scale the Broker but not IS? For example, I have a lot of large documents (1000 documents [A single document contains a document list which contains a large number of child documents] at 10 MEG a piece) that need to be extracted from a database, published, subscribed, and finally inserted into a different database. It has been my experience that Broker handles small documents really well but is very slow when handling large documents. What do I do? Is there a way to point a single IS to multiple Brokers? Should I remove the Broker from the equation for these large documents and only us IS?
On a related (performance) note, I worked with a system previously that benefited greatly from writing its logs to a separate (striped or RAID, I believe) disk. Having the logs on a different physical disk avoided head contention and thereby improved I/O performance. Does anyone know if such a tactic would be of any benefit to IS?
BTW - I’m sure it’s possible to specify a different location for IS’ logs, but it would be nice if this was more straightforward. Manageability was the concern expressed in our environment. Folks were also a bit uncomfortable with the blending of static files (the software) and dynamic data (logs, config files, etc).
I know WM recommend One Broker to one IS. But I also have clients that used multiple brokers on the ES platform. My client was told by WM that multiple brokers on one IS is not good. But I can’t tell you anymore since we don’t use the broker feature.
It is possible to move some of the logs via settings in the IS server.cnf file. Since IS is usually CPU bound and services get loaded at startup time, logs aren’t often the bottleneck.
That said:
It is possible to use a DBMS to hold Audit Log information and to have an asynchronous batch insert of this info. It will reduce the local log writing.
You can use a remote repository, so that other persisted stuff (like “Client Side Queuing” of Broker messages on IS) are also remote or on a separate disk from IS.
I think GEAR has a lot of this info in a Performance Tuning section.
On a recent visit, Jeremy Epstein, Director of Product Security and Performance, suggested that the best IS performance could be obtained using Intel CPU’s and the IBM JRE. Some recent testing (not yet complete) seems to suggest that this is correct.
Has anyone conducted WM 6.01 performance tests that compare hardware (Intel vs. Sun, etc.), OS (Windows vs. Solaris, etc.) and JVM vendor and version (Sun, IBM, JRocket, etc.)?
The last comparison I saw on GEAR was about a year ago, but I haven’t run a search there recently.
If someone knows of a more recent performance white paper, I’d love to read it. If there’s not one, perhaps we can request one from our respective account execs / technical account managers.
A new performance benchmark report for HP/UX systems running on PA-RISC or Itanium CPU’s was published by HP’s Jeff Krenek and Swarna Pedireddy in October 2003.
“This document is the second in a series of reports from hp that communicates the performance and scalability of webMethods Integration Server on hpux. The first report was published earlier in 2003, and was completed using IS 4.6. This report details similar test results, but completed with IS 6.01 SP1. Additionally, upgrades were done to both the hardware and software operating environments. The tests were completed on hp’s JVM version 1.4 for hpux running on both PA-RISC and Itanium 2 systems. The data shows that Integration Server running on the latter configuration is clearly a performance leader.”
I searched the Advantage site for the earlier version of this report that tested performance of IS 4.6 on HP/UX systems but could not find it.
There are two performance-related Technical Notes available on Advantage (see Best Practices->Product Technical Notes) that you may be able to use to gather some information.
Except for the Sun platform in the Flat File Performance report, all of the Intel systems used the IBM 1.3.1 JVM. Since any vendor would want to use the fastest possible hardware / software combination for its publicly released benchmarks, you could draw the conclusion that webMethods feels very confident in the performance of IS using the IBM 1.3.1 JVM.
These reports do not directly compare the performance of these two JVMs and I am not sure whether the 1.4.2 version of Sun’s JVM was out and stable at the time the tests in these reports were run, so you can not jump to the conclusion that webMethods performs better on Intel platforms using IBM 1.3.1 JVM than using the Sun 1.4.2 JVM.
One item of note is the use of the Sun 1.4.2 JVM’s aggressive heap option in the Flat File performance report. This option is not available on the IBM 1.3.1 JVM and may offer better performance for some webMethods IS installations where garbage collection performance is a major factor.
In summary, if you don’t have time to conduct your own tests that compare the performance of your company’s webMethods IS setup under both JVM’s, using the IBM 1.3.1 version is a safe bet.
If you just love Sun JVM’s or actually know that you need some of the advanced JVM options (and know how to use them properly you System.GC()-scheduling people) then I think you’ll also see acceptable performance with the Sun 1.4.2 JVM.