For the last few days I have been making some performance/reliability
changes within Jetspeed. This should make things much more solid and
responsive.
- Bad URL Manager: If Jetspeed encounters a URL that it can't fetch
(for whatever reason: server down, bad URL, etc) Jetspeed will add this
to the BadURLManager. This URL will no longer be available and will
throw Exceptions if you try to fetch it for some reason.
- Delayed Portlet expiration: Prior to this Jetspeed was expiring
Portlets right when the user tried to hit them. It now creates a Thread
that creates the new Portlet and then swaps that instance with the one
that is currently in the cache. The next request will see the refreshed
Portlet.
- FeedDaemon: I made some changes here. On some really stupid
JVMs/JITs (IE Blackdown) the design was causing core dumps in some
configurations. Usually greater than 25 Threads. I have rewritten it
to use a different algorithm. Now it creates 1700 Threads :). This
isn't a problem because most of these resolve instantly. About 20% of
these hang for about 60 seconds because of DNS/HTTP timeouts. This
means that the FeedDaemon now completes its work in about 1.5 minutes.
This now means that your CPU will stay pegged for a while with low
priority Threads. The bad part about this is that if you run Native
thread on Linux you will have a process table that is 1700 entries long
:(. If you do a "ps aux --forest" you will see them organized though.
So those changes are in CVS.
Right now I am working on bulk Portlet instantiation and Portlet content
disk caching. The bulk Portlet instantiation is done and I have a copy
of Jetspeed local that does this. The problem is that our RSS Portlet
takes about 2 - 3 seconds to instantiate. 1700 RSS Portlets times 2 -
3 seconds each yields about 1 -> 1.4 hours startup :( !!! . This is
****REALLY**** bad. I am trying to come up with creative ways around
this. Here is what I have thought of... if anyone has any other ideas
let me know:
- Don't use Castor with RSS. Only use XSL.
- benefits:
- Won't do the 2 phase Castor parse kludge like it is doing now
- should be faster
- content rendering is now done with XSL :)
- we were going to be using XSL with castor anyway
- drawbacks:
- All <image> URLs will be remote and won't be put in the
public disk cache
- Try to speed up Castor. From looking at the code it wasn't geared for
performance.
- benefits:
- might get speed improvements by 20%
- drawbacks:
- might not speed up Jetspeed.
- time spent away from Jetspeed development
- Delayed instantiation (not bulk instantiation). Don't try to
instantiate Portlets at all. Assume users will do this for you.
- benefits:
- no startup time needed to create Portlets
- Search will still work for portlets that are subscribe to.
- drawbacks
- Search won't work unless all portlets are instantiated.
Honestly I am leading towards the first idea. I just need to get a
performance metric to see if it is worth the time to store URLs
remotely. The other problem is memory utilization. This was just
soaking up memory. I am not sure if it is actually using it or just is
a memory leak.
Anyway. Hopefully I will have this last issue corrected soon. I
installed a new version of GNOME this weekend and my JDK started dumping
core (stupid Blackdown). Anyway.... soon :)
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
The house of the unbelievers shall be razed and they shall be
scorched to the earth. Their code will be open until the end of days.
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
