This content has been marked as final. Show 8 replies
I think the better question, and one I often find myself asking people, is "why are you trying to make changes to these setting?". Is there a particular problem you are experiencing, are you just simply attempting to tune the installation, did someone tell you this was something you should just do?? The answer will help to assist in understand the best approach for your situation. In most cases, there is no reason to alter the default setting. The one case where it might be necessary is for example if you are trying to push the machine to capacity. For example, if you are trying to get your Windows 2008 machine with 8gig of RAM to host 5000 Forms sessions. Well, this isn't likely going to happen regardless of what tuning you do.
Strictly from a Forms point of view, very little can be done to the environment that would result in measurable performance or scalability increases. In order to achieve either scalability or performance improvements from a Forms perspective, you would need to recode/redesign your Forms' modules. There are some exceptions, but this is the situation for most. Details are about coding tips are explained in the Forms Upgrade Guides. For cases where your Forms application makes server side java calls (this includes using RUN_REPORT_OBJECT) then using the Forms JVM Pooling feature can help. If your app does not call out to java then JVM Pooling will do nothing.
The remainder of the environment doesn't really belong to "Forms". The layers above Forms like OHS and WLS stand alone. Forms is merely a product/application hosted by these other components. At this level, various tuning methods can be implement. However, as I mentioned, you must first understand what you are trying to solve. If you are trying to solve or answer more than one question then I recommend addressing them one at a time although keep all in mind as you make changes. Changes to one area may adversely impact another.
As for the idea that you have X amount of RAM installed on a machine and you want to know how to tune around this, I don't think in most cases this is the best approach for tuning unless you are seeing that memory usage is nearing max or because there is some failure you are trying to correct. In cases where memory and/or CPU usage does seem oddly high then start with the basics.
For example, consider these basics:
1. Most times there is no need to run everything you have installed. For example, if you aren't using the WLS Admin server then there is no need to have the managed server or node manager running (unless you are scripting calls which need node man). If your application does not use Oracle Reports, kill the WLS_REPORTS server. And so on....
2. For WLS, when managed servers are created the startup parameters are most often configured with default settings. For example, for most of the releases I believe the default max heap setting is 500M. In many cases, this value likely will be higher than needed. The problem here is that only you will be able to determine how much lower you can safely reduce this value. Likely will need to do some experimentation to find what works best. Tools like jvisualvm might be able to help determine the ideal setting. This is included in the jdk installation.
3. Don't waste resources. For example, don't attempt to create additional managed servers on the same machine in order to do load balancing unless you actually can justify the need. In other words, if you generally only have 100 (this is just an example) concurrent users running Forms then likely there is no added benefit in creating another managed server to load balance these sessions. The added resource cost of the new managed server will likely negate any performance gain you were expecting.
4. Avoid having applications (e.g. Forms) access file via network shares (mapped drives). This will degrade application performance.
5. Be sure to comply with the guidance found in the product installation guide, system requirements guide, and product certification guide. Not following the instructions often will lead to performance and stability issues. For example JRockit is not certified for use with Forms/Reports installations. Likely it will work if you use it, but you may find that it is unstable and does not perform as you otherwise would have expected.
Again, these are just some very basic thoughts. Here are a couple of MyOracleSupport notes which can offer some specific guidance:
<li>Optimizing Performance of Oracle Fusion Middleware 11g (Doc ID 1469617.2)
<li>Tuning / Load Balancing: How to Manually Create a New WLS Forms Managed Server in 11g (Doc ID 989118.1)
Thanks for the well-thought-out reply. There are a number of things that I'm trying to solve in asking this question:
1). We had been getting some "Apache unable to contact the forms server" type errors (the users were seeing the "Failure of server APACHE bridge" error). The log files showed nothing of interest. I increased the memory allocated using setDomainEnv.cmd, and the error seems to have gone away. Yes, I know that it was a shotgun approach, trying something without really having a reason to do so, but it seems to have helped :) Edit: Now that I review the OHS logs instead of the WLS_FORMS logs, I have found log messages, which leads me to Doc 1380762.1, which tells me I need a patch. DOH. And, oh crikey, Forms 184.108.40.206 is out, it came out shortly after we downloaded 220.127.116.11 to create these environments. Good news/bad news kind of thing...
2). As tony.g suggested, we are looking for what we should do to solve the "I have n servers with x GB of RAM, what should I do to the out-of-the-box configuration of Forms for stability" question.
3). HA is important to us, so we are implementing a cluster of Forms/Reports servers with an LBR in front of it. I have read in the docs on clustering, cloning a managed server, and via Support, how to increase the heap memory for the WLS_FORMS server. My thought process was "if Oracle gives me instructions on how to increase heap memory and how to clone managed servers, there must be a scenario in which doing so provides benefit." I'm trying to understand the scenarios in which we would do either of those activities.
Right now, we're just building "lesser" environments (dev, training, etc), but the end users (our customer) is in fact accessing those servers and seeing the issues mentioned in #1, above. When we go full production, we could see concurrent user counts of 1,000+, so I'm trying to remain ahead of the curve. Yes, we are going to do proper performance and disaster testing - but knowing best practices for this ahead of time will help us avoid potential issues down the road.
I am aware of the JVM pooling (yes we do call out to Reports) - I've yet to implement this, but it's on my to-do list.
You are correct in pointing out the fact that we don't necessarily need to run everything that is installed, but I can say that we do need Forms and Reports - we can probably not start the external report server and use the one that runs as part of WLS_REPORTS, because that's what Oracle recommends for clustering. Our team does use Fusion Middleware Control, so we do, in fact, need the Admin Server running as well. I believe that node manager is also the best way to ensure that when things go wrong (e.g. WLS_FORMS hangs or crashes), they can be restarted - I view it as kind of the "OPMN for WLS."
Can you provide any additional thoughts based on my ramblings?
Let me try to comment on each of yours:
1). We had been getting some "Apache unable to contact the forms server" type errors (the users were seeing the "Failure of server APACHE bridge" error). The log files showed nothing of interest. I increased the memory allocated using setDomainEnv.cmd, and the error seems to have gone away. Yes, I know that it was a shotgun approach, trying something without really having a reason to do so, but it seems to have helped Edit: Now that I review the OHS logs instead of the WLS_FORMS logs, I have found log messages, which leads me to Doc 1380762.1, which tells me I need a patch. DOH. And, oh crikey, Forms 18.104.22.168 is out, it came out shortly after we downloaded 22.214.171.124 to create these environments. Good news/bad news kind of thing...<blockquote>The Apache Bridge error is fairly straight forward if you understand what it is telling you. It is an error generated by mod_wl_ohs who is owned by OHS (Apache). This module is responsible for the connection between OHS and WLS. The Apache Bridge error means that OHS (mod_wls) was unable to get a response from the WLS managed server it was calling. Basically it was unable to cross the bridge ;) The cause could be anything from the managed server is not running, to the managed server is over tasked, or there is a network configuration issue and the managed server simply didn't hear OHS calling.
This is all discussed in MOS note 1304095.1
As for 126.96.36.199, this can be installed fresh or as a patch over 188.8.131.52. So for machines that don't currently have anything installed, you can go directly to 184.108.40.206 without having to install 220.127.116.11 first.</blockquote>
2). As tony.g suggested, we are looking for what we should do to solve the "I have n servers with x GB of RAM, what should I do to the out-of-the-box configuration of Forms for stability" question.<blockquote>As I mentioned, there really are no "Forms" specific tweaks related to how much RAM your machine has. The only exception to this is (although somewhat indirect) to use JVM Pooling. JVM Pooling can reduce the size of each runtime process's memory footprint by moving its java calls to the jvm pool then sharing common requests with other running runtimes. Memory usage by OHS or the WLS managed server really has little to do directly with Forms. Specifically to the managed server, from a Forms point of view, I would not expect the memory cost of WLS_FORMS to increase much because of load. I expect it to increase as concurrent load increases, but I would not expect it to be significant. If I had to guess, seeing an increase of 1m or less per user would not surprise me (this is just a guess - I don't know what the expected values would be). If we were to use our (Oracle) older scalability guidelines, typically we would have suggested that you should consider about 100 sessions per 1 jvm for best performance. Given that v11 uses a newer java version and scalability is better today, I suspect you can easily scale to a few hundred (e.g. 300) or so before performance drops off. Beyond that, the need to add more managed servers would likely be necessary.
This is discussed in MOS note 989118.1</blockquote>
3). HA is important to us, so we are implementing a cluster of Forms/Reports servers with an LBR in front of it. I have read in the docs on clustering, cloning a managed server, and via Support, how to increase the heap memory for the WLS_FORMS server. My thought process was "if Oracle gives me instructions on how to increase heap memory and how to clone managed servers, there must be a scenario in which doing so provides benefit." I'm trying to understand the scenarios in which we would do either of those activities.<blockquote>Refer to the note I mentioned above. Generally, if you limit the number of concurrent sessions to less than around 300-400, I would think the default settings should be fine. If you think you would like to go beyond 300 or 400 per managed server then likely you will need to increase the max heap for the managed server. Again, refer to the note I mentioned previously.
Also see MOS note 1260074.1</blockquote>
I am aware of the JVM pooling (yes we do call out to Reports) - I've yet to implement this, but it's on my to-do list.<blockquote>This is discussed in the [url http://docs.oracle.com/cd/E38115_01/doc.111210/e24477/jvm.htm]Forms Deployment Guide</blockquote>
Hope that helps ;)