On Mon, Apr 15, 2013 at 11:18 AM, Mark Eggers <its_toas...@yahoo.com> wrote:
> On 4/15/2013 7:25 AM, David kerber wrote: > >> On 4/15/2013 10:10 AM, Howard W. Smith, Jr. wrote: >> >>> On Mon, Apr 15, 2013 at 7:40 AM, David kerber<dcker...@verizon.net> >>> wrote: >>> >>> On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote: >>>> >>>> On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomas<ma...@apache.org> >>>>> wrote: >>>>> >>>>> On 14/04/2013 21:53, Howard W. Smith, Jr. wrote: >>>>> >>>>>> >>>>>> On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz< >>>>>> >>>>>>> ch...@christopherschultz.net> wrote: >>>>>>> >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> >>>>>>> Hash: SHA256 >>>>>>>> >>>>>>>> Howard, >>>>>>>> >>>>>>>> On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote: >>>>>>>> >>>>>>>> On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz< >>>>>>>> >>>>>>>>> ch...@christopherschultz.net> wrote: >>>>>>>>> >>>>>>>>> Your heap settings should be tailored to your environment and >>>>>>>>> >>>>>>>>> usage scenarios. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Interesting. I suppose 'your environment' means memory available, >>>>>>>>> operating system, hardware. Usage scenarios? hmmm... please clarify >>>>>>>>> with a brief example, thanks. :) >>>>>>>>> >>>>>>>>> >>>>>>>>> Here's an example: Let's say that your webapp doesn't use >>>>>>>> HttpSessions >>>>>>>> and does no caching. You need to be able to handle 100 simultaneous >>>>>>>> connections that do small fetches/inserts from/into a relational >>>>>>>> database. Your pages are fairly simple and don't have any kind of >>>>>>>> heavyweight app framework taking-up a whole bunch of memory to do >>>>>>>> simple things. >>>>>>>> >>>>>>>> >>>>>>>> Thanks Chris for the example. This is definitely not my app. I am >>>>>>>> >>>>>>> definitely relying on user HttpSessions, and I do JPA-level caching >>>>>>> (statement cache and query results cache). pages are PrimeFaces and >>>>>>> primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help >>>>>>> with >>>>>>> speed/performance. And right now, the app handles on a 'few' >>>>>>> simultaneous >>>>>>> connections/users that do small and large fetches/inserts from/into >>>>>>> relational database. :) >>>>>>> >>>>>>> Hopefully one day, my app will be support 100+ simultaneous >>>>>>> connections/users. >>>>>>> >>>>>>> >>>>>>> >>>>>>> For this situation, you can probably get away with a 64MiB >>>>>>> heap. If >>>>>>> >>>>>>> your webapp uses more than 64MiB, there is probably some kind of >>>>>>>> problem. If you only need a 64MiB heap, then you can probably run on >>>>>>>> fairly modest hardware: there's no need to lease that 128GiB server >>>>>>>> your vendor is trying to talk you into. >>>>>>>> >>>>>>>> >>>>>>>> Understood, thanks. I have Xms/Xmx = 1024m, and I rarely see used >>>>>>>> >>>>>>> memory >>>>>>> get over 400 or 500m. the production server has 32GB RAM. >>>>>>> >>>>>>> >>>>>>> I'll summarize a number of JavaOne sesisons I've been to on GC and >>>>>> performance (caveat - this was a couple of years ago and GC design has >>>>>> moved on since then). >>>>>> >>>>>> - GC pause time >>>>>> - throughput >>>>>> - small memory footprint >>>>>> >>>>>> You can optimise for any two of the above at the expense of the third. >>>>>> >>>>>> Assuming you opt for min GC pause time and max throughput the question >>>>>> then becomes how much heap do you need? If you look at your steady >>>>>> state >>>>>> heap usage graph (it should be a saw-tooth) then take the heap >>>>>> usage at >>>>>> the >>>>>> bottom of the saw-tooth and multiply it by 5 - that is the heap >>>>>> size you >>>>>> should use for the GC to work optimally. >>>>>> >>>>>> HTH, >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> Interesting, that does help, Mark, thanks. 250 x 5 = 1,250. I >>>>>> guess I >>>>>> >>>>> was >>>>> pretty close on target when I set Xms/Xmx = 1024m. >>>>> >>>>> Prior to seeing your email/response, I checked the server again, and it >>>>> was >>>>> no saw-tooth at all, it was at 250 (bottom), and then saw-tooth >>>>> graph came >>>>> into play...minutes later. >>>>> >>>>> >>>> Make sure you give it enough time for the memory use to stabilize. >>>> >>> >>> >>> Will do (and doing that), thanks. :) >>> >>> >>> Depending on your app and usage patterns, it can take up to days for the >>>> sawtooth to stabilize and start showing. One of mine takes a couple of >>>> hours, and another a few days for that pattern to become visible. >>>> >>> >>> >>> I see it stabilize 'in minutes' (after/during usage of the app). >>> >>> Just now (prior to writing this email), I was looking at the app's usage >>> (via monitoring the app's own data/record audit trail page), and then >>> decided to check-on the app to see how it is doing/performing via >>> jvisualvm, and voila, again, I saw no saw-tooth[1]. >>> >>> I saw this, 5 to 15 minutes after a period of inactivity in the app, but >>> before I logged into the app, as I stated above, I checked the app's >>> audit >>> trail (which can definitely be a 'heavy-lifting' database query, >>> depending >>> on work done within the app on selected date, default = current date), >>> and >>> it[1] still showed no activity (or saw-tooth); I assume activity >>> within the >>> app can = definite/obvious saw-tooth graph (which also means, GC is >>> working >>> while app is being used). >>> >>> What I mentioned above is very normal behavior for my app. >>> >>> [1] >>> http://img805.imageshack.us/**img805/8453/**20130415jvisualvm01.png<http://img805.imageshack.us/img805/8453/20130415jvisualvm01.png> >>> >> >> These graphs are only showing ~40 seconds of data. I'll bet if you let >> the app run for several minutes or hours, you'll see it. >> >> > Yep, there's no history in that data. > Agreed! :) > > What you can do (probably in a test environment) is the following: > > 1. Set up monitoring (visualvm, psi-probe, jconsole) > 2. Abuse your application with well-crafted JMeter (or other) tests > 3. Watch memory > Interesting. I will have to try that, at some point. Thanks. > > This becomes a little more challenging with AJAX-style applications (yours > is a PrimeFaces / JSF / AJAX one, right?), but I've seen some notes on > this. Google is your friend. > Yes, PrimeFaces, but not much AJAX at all. my endusers went from using an almost 20-year-old MS-DOS dBase IV app to a Java/JSF web application. They don't need AJAX (partial page refreshes), so they are very happy with full page refreshes. :) I implemented security and session management in my app via some approaches that I got from BalusC on stackoverflow.com. so, Full page refresh (FPR) is necessary to refresh the page, <meta http-equiv="refresh" content="#{session.maxInactiveInterval};url=#{pf_usersController.isLoggedInViaAndroid() ? 'pf_viewExpiredOnMobile.jsf' : 'pf_viewExpired.jsf'}" /> so, session can timeout/expire according to the follow context param, set in web.xml. <!-- session-timeout = 15 minutes --> <session-config> <session-timeout> 15 </session-timeout> </session-config> this meets my requirements for session timeout/expire/management. > . . . . just my two cents. > /mde/ > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@tomcat.**apache.org<users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: users-h...@tomcat.apache.org > >
