|
Friday, November 22, 2002 |
|
And if you need to increase the heap size of your WebObjects application (or Java app, in general), add the following to the list of arguments passed to the JVM. -Xmx180m -XX:NewSize=2m -Xms128m (The NewSize isn't really necessary). Keep in mind that OS X ships with a ridiculously small default stacksize and heapsize:
[bumbox:~] bbum% limit If you find that your applications-- typically invoked from a Terminal window-- are exploding with what looks to be out of memory or stack overflow errors, it may be because of the above limits. Try issuing the command unlimit and run the app again. See the limit man page for more information.
This limit is the same reason why Python's regular expression unit test breaks on OS X. When it is testing a particularly complex regex, it recurses to the point of stack overflow. Unlimit the stacksize and all is well. (Or maybe it is the datasize, I can't remember -- I always just use unlimit). |
|
OptimizeIt! and WebObjects 5.2 We use OptimizeIt! as a part of the optimization regimen in building WebObjects and Java applications. OptimizeIt! is a great tool for optimizing Java applications, but it can be a bear to set up. Some time ago, Kenny Leung-- Apple Engineer extraordinaire-- sent a recipe for using OptimizeIt! with WebObjects 5.1/5.0. It works by extending the build in PBX such that one can supply a simple command line argument and environment variable to a WebObjects application to enable the various OptimizeIt! analysis modules. However, everything broke with WebObjects 5.2. Namely, Apple modified the startup of WebObjects applications in 5.2. The change is very much for the better-- Apple finally provided an intelligent class loader that automatically grabs the appropriate jar files as the application launches as opposed to the classpath hoops that we had to jump through in previous versions (I have ranted on this subject in the past). I modified Kenny's recipe to work with WO 5.2. The steps are as follows: 1. Install OptimizeIt! somewhere useful. I suggest ~/Developer/. 2. Add this file to your WebObjects project. It doesn't need to be added to any particular target. 3. In the Build Phases for the main target of your project (I.e. not the web server or application target, but the target that is typically named the same as your project), edit the "Shell Script Files" target and paste this...
# Add extra options for the JVM in the startup file.
SCRATCHFILE="/tmp/ScratchFile" ... to the build phase after the . "${BUILD_FILES_DIR}/CreateRunFiles.sh" line. 4. In the executable editor, add the environment variable OPTIMIZEIT_SUITE and sets its value to the full path to the OptimizeIt installation directory (in my case, it is set to /Volumes/Data/Users/bbum/bbum-developer/OptimizeItSuite). 5. To enable the profiler, create a new set of launch arguments (typically, by duplicating whatever set you normally use to mimic the production environment on the development desktop) and add the argument -DOptimizeIt=Profile. If all is configured correctly and you launch with the -DOptimizeIt=Profile parameter, you should see something like this...
OptimizeIt Profiler 4.2 build 020502 Audit System. ... printed immediately after the java command line. Of course, this also means that you can enable OptimizeIt! in a production environment by ensuring that the OPTIMIZEIT_SUITE environment variable exists and the appropriate command line argument is added to the app configuration in Monitor. Once the app is running, launch OptimizeIt! and select remote application in the settings window. The default port should be fine. Provide a hostname if you need to analyze an app running on a different machine. Click Attach Now to attach to the application. The presence of OptimizeIt does slow down the application considerably, but it is across-the-boards and should not affect the detection of hot spots in the code. However, I would recommend only attaching to the application once you are prepared to start the analysis. Attaching to an app slows it down even more than just the presence of OI!
By the way, CodeFab has resources available -- if you are in need of help with developing/refining/designing/optimizing WebObjects or OS X application(s), need help with network architecture/management, etc.. please contact Jerry Walker jwalker@codefab.com for more information. |
|
First exposure to Windows Chuq has a friend who is working with Windows XP for the first time. Her reaction: It looks like the UI was designed by the Disney people who brought us all the really bad films when they were in the "what would Walt do" stupid-cute--kawaiiiiii mode. It looks like something you'd run on a toy. Chuq's response: Windows: It's like "it's a small world" when the ride breaks down and you're stuck next to Sweden" That hit a bit close to home as I actually was stuck in the Small World ride at Disney for almost 40 minutes. This ocurred 3 years ago, so the memory-- the terror-- is still fresh in my mind. I have tried to use Windows on a semi-regular basis mostly because I either have to or because I simply want to keep up on what Redmond is lumping into the OS these days. I can honestly say that trying to use Windows for any length of time makes me physically ill. It becomes so blatantly obvious that the "user experience" was created with zero consideration for the user.
Thanks, Chuq, now I have a rather painful soundtrack to go with Windows. |
Last update: 1/23/03; 11:05:47 .
