After spending too much time today waiting for WebSphere Portal to restart (due to a nasty bug causing Portal to crash when I was working with it) I've been revisiting how to improve the startup time.
The key step in doing this is to uninstall portlets that aren't needed. (see http://www-01.ibm.com/support/docview.wss?rs=899&uid=swg21213982&ca=lsall for a list). For the lazy developers (read me) there are a series of scripts that have been developed that do this. The article Installing and configuring WebSphere Portal V6.0 Servers for development with Rational Application Developer V7.0 and Rational Software Architect V7.0 includes these scripts in a zip file (search for StartupPerformanceConfig.zip in the article). The article also has some good suggestions for memory and jvm settings for your server.
I have known about the existence of this process for a little while, but it took me a little to find them just now (when tuning a development server). Google was have troubles pointing me to the right article, so I thought for my sake I'd try and help google find this in the future. (Even if google did find the right spots, the title of the developerworks article wouldn't have made me think that it had the nugget of information about IBM WebSphere Portal Startup performance).
I've been using ssh tunnels for a while now. I first encountered the technique when setting up my e-mail client when doing research at the ISI. The ISI are understandably quite security conscious, so a ssh tunnel was required to access my mail on my mac. I'll admit that I set this up initially withot really having a clue, simply following the directions of the guys at the ISI that knew what they were doing. I had a couple of ssh commands sitting in an e-mail (and more often than not in my history), which I would simply refer to and reuse.
More recently at Ephox I've been doing a fair bit of ssh tunneling. I've been doing this to access the UK demo server for E2, exposing the Websphere admin and wcm portal urls via the tunnels. This process has worked relatively well for a couple of weeks for me, but in my current stage I'm going through some pain as the transfer of my ear file from the local build to the remote server is taking between 15 and 20 minutes currently. To get around this for some rapid bug fixing work, I've entered the next stage of my ssh tunneling jujitsu
ssh to remote server
ssh back to local Brisbane office, setting up a tunnel into subversion server
then use subversion to check out the codebase.
After having performed this setup work, I can easily do my changes on my local box, update the remote server via svn, then build and deploy from the remote server. The build and deploy are currently too manual, and could use some automation, but I'm currently happy to wear the pain, and drop my deploy process from 20 minutes to under five.
My current next step is to automate the rest of the process. Assuming my recent foray into sysadmin land didn't completely kill the server, this should be done very soon.
The IntelliJ Analyse stack trace is a good tool to add to your bag of tricks.
Simple copy a stack trace to the clipboard, then go to IntelliJ -> Analyze Menu -> Analyze Stack trace
You will see the option to normalize the stacktrace (which is worth choosing), after pressing ok, you will see the output put into the run menu, which will allow you to navigate to classes inside your current project.
This is a nice tool for debugging support stacktraces you may receive, or stack traces originating from a remote server.
As I seem to end up with the odd person dropping by the blog to look at IntelliJ keyboard Short cuts, I figured that it is probably worth pointing people towards the DZone IntelliJ Refcard which has a pretty good introduction to IntelliJ.