Confusion on Java heap memory and WLS_FORMS

Question

Hello all,
Background first:
Oracle Forms/Reports 11.1.2 64-bit
WebLogic Server 10.3.6
JDK 1.6 update 37 64-bit
Microsoft Windows 2008 R2
Using nodemanager to start/stop managed servers
After having read all of the documentation and searched both this forum and the Internet for advice, I'm still utterly confused about the best way to make use of memory on the server (the server I'm working on now has 8GB). The two trains of thought that I have discovered in my search:
1). Don't change the Javaheap size at all (stick with the defaults) and just create additional managed servers on the same machine.
2). Increase the Java heap size for WLS_FORMS
Having said that, here are my questions:
A). What is the best-practices approach (#1 or #2)?
B). If it's #2, what's the approved way to increase the heap size? I have tried adding -Xms and -Xmx arguments to the WLS server start arguments in the WLS console. These are applied when the managed server is started (confirmed in the log file), but because of the way WLS_FORMS is started, there are more -Xms and -Xmx arguments applied after mine, and Java picks the last one mentioned if there are duplicates.
First update: Question #2 seems to be answered by support note 1260074.1 (the one place I hadn't yet looked)
Thanks for any insight you can provide. If there's a document I've missed somewhere, I'm happy to be told where it is and will read and summarize findings here.
Regards,
John

Answer 1

John,
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 11.1.2.1 is out, it came out shortly after we downloaded 11.1.2.0 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 11.1.2.1, this can be installed fresh or as a patch over 11.1.2.0. So for machines that don't currently have anything installed, you can go directly to 11.1.2.1 without having to install 11.1.2.0 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 ;)
.