WebContainer synchronous vs. asynchronous mode: Advice?
Frederic Mora (138●1●15●18)
| asked Apr 10 '12, 3:59 p.m.
edited Jan 31 '13, 3:57 p.m. by Bianca Jiang (141●2●4)
Hello,
We are using RTC 3.0.1. We are building with JBEs. Our JBEs recently started encountering timeout exceptions. This is the same problem as Defect 187852. We opened a PMR. RTC Support said that we might be running out of memory and suggested that we apply the change described in http://www-01.ibm.com/support/docview.wss?uid=swg21317658. In a nutshell: In the WAS admin console, add custom property com.ibm.ws.webcontainer.channelwritetype with value "sync". This switches the WebContainer responses to synchronous mode. We did this. Indeed, with that setting, we see that our RTC VM memory usage is about 2.5 GB out of 8 GB. Without the setting, in the default async mode, it used to be 4 to 6 GB out of 8 GB. But the load time for a build went from 8-9 mins in async to 23 mins in sync mode! This is not acceptable, so we are thinking of going back to the async mode by removing the custom property. The question is, what are the downside of switching back to async transfers? I can easily allocate 16 GB of RAM to my WAS VM. Is there a known memory leak in WAS? What's the appropriate VM size for loading a 200,000-file workspace? |
Accepted answer
Hi, Frederic,
Sorry about the belated reply. But I think the web container channel write mode and Defect 187852 are two very different issues, even though both can have an impact on performance of your build loading. Defect 187852 (or essentially FilesystemService.getFileTreeByVersionable() should be streamed (62219)) is about allowing file load to start before getFileTreeByVersionable is completed fetching file tree, in RTC source control. The web container channel write mode is about the trade-off between performance and memory usage when WAS writes out response data. WAS writes response data in chunks into a response buffer (32k default) before the buffer flushes. The property "com.ibm.ws.webcontainer.channelwritetype" controls the behavior of such writings. "async" mode (default) not only writes the response data asynchronously (each write of a data chunck returns as soon as it is queued), but also it keeps on writing even when the response data is bigger than the response buffer by simply buffering more in memory. This mode improves performance of requests with mid - large response data, but it can lead to high memory usage sometimes even OOM error. It may also cause app server to hang when more requests are simultaneously processed than the web container's defined number of threads. "sync" mode makes the data chunks writing synchronously, up to the defined response buffer size. i.e. next chunk won't start writing until the previous chunk finished. As a result, it guarantees the max. amount of response data in memory is "responseBufferSize" multiplied by the number of web container threads. As max. number of requests processed simultaneously won't exceed the web container threads limit. Additional requests will be queued until some requests in process are completed. So your observation of the memory usage vs. performance is an excellent one. It shows exactly the trade off of this web container property. So if memory consumption is not a big concern but performance is (like in your case), you are probably better off to stay with the default mode. Hope this helps, Bianca Frederic Mora selected this answer as the correct answer
Comments but be forewarned.. if you run in async mode (default) and run out of jvm heap, your system will crash.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.