Thank you só much Christofer that's what I'm talking about!!! Muito obrigado pela ajuda!!!
Sent from my iPhone On 23/10/2012, at 22:38, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel, > > On 10/23/12 4:12 PM, Daniel Barcellos wrote: >> Imagine this simple examplo... we used to develop app for Oracle >> forms that runs over a oracle application server. If you need to >> install it you should obey a big list of requirement so that every >> thing under its control will run ok. Now we need to use and deploy >> software over Tomcat that is basically a free server. Where can I >> find those requirements? > > Tomcat by itself (well, with the JVM) can run in about 16MiB of Java > heap. Your webapp will probably need a *whole* lot more than that. > > Tomcat is lean and mean. OAS is a beast that has higher minimal > requirements, but I suspect that OAS all by itself can run in maybe > 32MiB or 40MiB. The reason they tell you that you need 32GiB of heap > space is because they want your app to work pretty much no matter what. > > Realistically, only you can determine what your requirements are. > > Start by giving the JVM plenty of heap space. Let's say 1GiB (if you > have it) on a test bed. Then, deploy your webapp, force a few GCs (use > jconsole or something else that allows you to do that) then check the > memory usage: that's your baseline. You cannot possibly go below that > and support even 0 users. > > Then, login a single user and go through a typical workflow. Repeat > the GC/heap dance from above and see what the requirements are for a > single user. Then try 10 users. Then 20 users. You can even graph them > if you want to get fancy (which I recommend). I also recommend using a > tool like JMeter to act as users. This will give you something > repeatable and scalable (from a /load/ point of view). > > You might still be wrong about the heap space, because you may have > huge transient requirements during a single transaction (for instance, > you need to build an in-memory image, plot stuff against it, compress > the image, etc.). You'll need to load-test your webapp in a test bed: > that's the only way you can really know your requirements. > > The CPU speed is more difficult to pinpoint because realistically, any > CPU will do, right? It's just a question of how long it takes to do > stuff. So, you have to do all of the above (1 user, 10 users, 100 > users) working constantly and checking the response time to see if it > meets your targets. For instance, some people require that their > response times are less than 500ms. For you, that might be more like > 3000ms. You may have different targets for different transactions: > choosing a chart template might need to be within 500ms but it's okay > if the actual chart generation takes 10s. > > In case you aren't realizing it, yet: nobody can tell you what your > own requirements are: you have to go figure them out yourself. > > If it makes you feel better, I can tell you what you need and I'm sure > you'll be happy with the performance. Here goes: > > 1 IBM BladeCenter Chassis > 4 IBM BladeCenter HSxx (you get to choose which ones) > (You'll want a chassis with at least 8 blade slots: you'll need > room to grow) > Go for 1TiB per blade: you'll thank me later. > You're definitely going to need a bank of SAS disks. Don't bother with > elaborate RAID rigs or anything like that: just mirror everything > because you don't want to waste time waiting for any RAID re-syncing. > > Or you could just fire the whole thing up on a laptop and beat the > hell out of it. Your choice. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlCHOHIACgkQ9CaO5/Lv0PA0hQCfeXBZPLpsaQl9uvLI2QKGQcwA > 3NMAoLnjdE1dzgLwCedtMYwoPc12q7Pj > =LdQW > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
