My experience with the Weblogic Portal Workshop IDE has so far been positively suicidal !! I wish no-one has to go through this experience .. But however the dark the cloud might be, there is always a silver lining .. My silver lining has been the performance shortcuts that I had to learn to make the hard way to prevent the aforementioned suicide :)
I have an Lenovo T400 office laptop with a 2.0 Ghz Centrino vPro 2 processor and 3 Gigs of RAM. Normally this would have been an ideal work laptop, but for the project I'm working on .. this stinks !
Being the nosey character I am (and in no small measure, to prevent the aforementioned death), naturally I stared to tune the IDE and the project..
(1) Tuning the hardware
What ever the software, its the hardware that has to run it. You cannot go beyond the limitations of the hardware. So naturally, the hardware has to grow to present you with the opportunity to improve the performance. Mine was a dinky little Lenovo T60 machine with 2 Gig of RAM and a 5400rpm HDD compounded by the months of fragmented files.
An upgrade to a T400 + 3 Gig of RAM and a new HDD image extended my life by at least 10 years :)
Get rid of the extra bulk of unnecessary installed programs and files .. RAR/ZIP anything you dont need for your immediate usage.
On a different note, I'm not totally sure why it happened or why it is behaving so, but my javaw process becomes unpredictable and kind of hangs every 2-3 hours lately. Also the Disk I/O reads for the javaw process frequently cross 100 million within an hour or so. My task manager depicts that of the two cores, one CPU core is busy while the other is not being used at all. Maybe this is due to a thread lock somewhere in the IDE. Looking at the Eclipse logs, it looks like the threads that control the UI facets of eclipse are running into errors and locking out the other threads. Being too lazy to figure out and resolve the actual issue, on a hunch, I set the affinity of the javaw process to only a single core. This seems to have resolved the issue. The IDE is slightly slower, but the DISK I/O reads have come down considerably and the IDE no longer hangs or crashes.
(2) Tuning the OS
Whatever the raw power of your hardware, the OS gets a chunk for itself. Unless the Google Native Interface for Java takes off (running java without an OS), you will have to take care to provide as little as possible for that chunk. Standard OS optimizations include
(3) Tuning the Middleware / IDE
Before starting the workshop
After staring the workshop
Before importing the projects / creating new projects, do the following :
After importing the projects
Anytime the workspace crashes, restarting the eclipse IDE might take a long time for the workspace to get built. This is because of the standard Java Tooling plugin that eclipse run to rebuild the workspace.
It is far easier to delete the .metadata folder in the Eclipse working directory and create new projects. This has been an accepted approach for many a portal developer.
Taking it a step further, you dont actually need to delete the entire .metadata folder. Delete just the following:
This will delete just the project information and keep all your Eclipse settings and Facets intact. This will speed up your workspace build time considerably. (My workspace rebuild time decreased by more than 50 %).
I have an Lenovo T400 office laptop with a 2.0 Ghz Centrino vPro 2 processor and 3 Gigs of RAM. Normally this would have been an ideal work laptop, but for the project I'm working on .. this stinks !
Being the nosey character I am (and in no small measure, to prevent the aforementioned death), naturally I stared to tune the IDE and the project..
- Tuning the Hardware
- Tuning the OS
- Tuning the Middleware
(1) Tuning the hardware
What ever the software, its the hardware that has to run it. You cannot go beyond the limitations of the hardware. So naturally, the hardware has to grow to present you with the opportunity to improve the performance. Mine was a dinky little Lenovo T60 machine with 2 Gig of RAM and a 5400rpm HDD compounded by the months of fragmented files.
An upgrade to a T400 + 3 Gig of RAM and a new HDD image extended my life by at least 10 years :)
Get rid of the extra bulk of unnecessary installed programs and files .. RAR/ZIP anything you dont need for your immediate usage.
On a different note, I'm not totally sure why it happened or why it is behaving so, but my javaw process becomes unpredictable and kind of hangs every 2-3 hours lately. Also the Disk I/O reads for the javaw process frequently cross 100 million within an hour or so. My task manager depicts that of the two cores, one CPU core is busy while the other is not being used at all. Maybe this is due to a thread lock somewhere in the IDE. Looking at the Eclipse logs, it looks like the threads that control the UI facets of eclipse are running into errors and locking out the other threads. Being too lazy to figure out and resolve the actual issue, on a hunch, I set the affinity of the javaw process to only a single core. This seems to have resolved the issue. The IDE is slightly slower, but the DISK I/O reads have come down considerably and the IDE no longer hangs or crashes.
(2) Tuning the OS
Whatever the raw power of your hardware, the OS gets a chunk for itself. Unless the Google Native Interface for Java takes off (running java without an OS), you will have to take care to provide as little as possible for that chunk. Standard OS optimizations include
- Setting the size of your Page file to a User defined size of 1.5 times the amount of RAM
- Making sure the antivirus scans are not running (If possible, exclude the JAR, EAR, WAR files from the A/V scans .. hard to do in a office setup)
- Try "ending-task" from Task Manager for a number of standard unnecessary background software. This might vary depending on the setup you have on your laptop.. Bottom line - > Portal IDE is huge, clunky and very demanding on your system. Be afraid of it and try to serve it well :)
(3) Tuning the Middleware / IDE
Before starting the workshop
- Play around with the JVM memory arguments in the eclipse.ini file to increase the memory available to the eclipse. I usually use [-vmargs -Xms768m -Xmx768m -XX:MaxPermSize=256m -XX:PermSize=256m -XX:NewRatio=3 -Xss256k ]
- Add -XX:+UseParallelGC to the above memory arguments for parallel Garbage Collection.
After staring the workshop
Before importing the projects / creating new projects, do the following :
- General > Appearance (Uncheck Enable Animations)
- General > Appearance > Label Decorations (Uncheck EVERYTHING !)
- General > Startup and Shutdown (Uncheck auto updaters and feedback/usage reporting plugins)
- General > Welcome (Uncheck all root pages)
- General > Workspace (Uncheck Build Automatically)
- Install / Update > Automatic Updates (Uncheck automatic updates)
- Run / Debug > Console (Check Limit console Output)
- Server (Uncheck Automatically publish to local and remote servers)
- Server (Server Timeout delay should be set to Long for big projects)
- Server > Audio (Uncheck Enable sounds)
- Server > Launching (Uncheck Automatic Publishing and Automatic Restarting)
- Validation > Audio (Uncheck Allow projects to override the preferences, Check Suspend all validators)
- Server > Audio (Uncheck Enable sounds)
- Also make sure you have all unnecessary windows, views and perspectives closed
After importing the projects
Anytime the workspace crashes, restarting the eclipse IDE might take a long time for the workspace to get built. This is because of the standard Java Tooling plugin that eclipse run to rebuild the workspace.
It is far easier to delete the .metadata folder in the Eclipse working directory and create new projects. This has been an accepted approach for many a portal developer.
Taking it a step further, you dont actually need to delete the entire .metadata folder. Delete just the following:
- .metadata/.lock file
- .metadata/.plugins/org.eclipse.core.resources\*
This will delete just the project information and keep all your Eclipse settings and Facets intact. This will speed up your workspace build time considerably. (My workspace rebuild time decreased by more than 50 %).
No comments:
Post a Comment