Thursday, June 14, 2012

WebSphere Liberty Profile (Quick Performance View)

I've had the pleasure of developing a new application on the WebSphere Liberty Profile for the last week.  I wanted to take the time to write a quick summary of my experience.  While there is very cool and interesting blogs proving the point of the small nature of the server documented by running the profile on Raspberry Pi, I wanted to take some time to document my experience developing on the profile to talk in terms that matter to the typical developer.

Some "performance" points:

  1. At one point, I got the server into a non-recoverable state.  Later, Alasdair told me how I could have fixed the issue, but the server creation time made it pretty much a non issue.  I was able to delete the server directory for the server I was working on, run the server creation command (server.bat create server1), re-run my ant script to repopulate the dropins directory with my application and restart the new server in about two minutes.
  2. Speaking of repopulating the dropins directory with my application, the normal reployment of an application is FAST.  My war file is about 5 megs, of which 4.5 is library jar files under WEB-INF\lib.  I typically see a redeployment time of about four seconds.  To make this truly interesting, this is the server started with debugging.  If I'm not debugging, it usually takes around 3 seconds for redeploys.  I pretty much call this instantaneous as it takes just about that long to swap from eclipse ant build back to my browser for testing.  Every once and a while I'll catch the application in deployment getting a 404 error, but a refresh always is all it takes to see the app show up.  I used to think about checking Twitter, Facebook between app deployments but now I can't.  Now I can keep working though basically an immediate compile, deploy, test life cycle.  Darn it, no productivity distractions any more.
  3. I don't restart the server at all during the day, but it's worth stating server start up time.  With this application deployed, it takes about seven seconds to start the server.
  4. I haven't yet tuned the server at all.  I just point the server to my IBM Java for JAVA_HOME and start the server.  That means I'm not tuning the heap or thread pools or anything like that.  Granted, so far, I'm just doing single user testing of my application.  But that said, here is what my process explorer reports about the instance:
    • Virtual memory size = 1.5G, peak private bytes = 144M, peaking working set = 160M
    • I didn't specify any Java command line options, but it looks like the start-up script sets -XX:MaxPermSize=256m
All of these numbers are from my laptop which is a Thinkpad W500 which is a  2 core x 2.53GHz Intel Core Duo, with 4G of memory (2.5 usable as I didn't install 64-bit Windows), with a SSD Disk (btw, get a SSD Disk, spinning disks are horrible!).

All in all, this server is a joy to develop applications on.  Congrats to the WebSphere Liberty team!

Tuesday, June 5, 2012

New Blog

I have reluctantly decided to move my main blogging from the WebSphere Community Blog to here. I have chosen to do so after much thought. Over the last few years, I have spent a fair amount of time encouraging multiple authors to blog on the WebSphere Community blog seeing as the best place to have the most relevant content for WebSphere customers. Even so, I have decided to move my blogging here for the following reasons:

1. I have returned my focus to performance at IBM (I can't seem to get away from performance and I do truly love doing performance related work). While performance is interesting to all WebSphere customers, I doubt that as I start to ramp up performance discussions that all topics will be just WebSphere focused. Therefore, I don't want to put such blog posts on the WebSphere Community Blog.

2. WebSphere is such a broad portfolio these days. Much of the WebSphere Community Blog is focused on what we refer to as the WebSphere Foundation (the application servers, the data/caching grids, etc). In my current role I will be focusing across the entire WebSphere portfolio and beyond.

3. More and more, IBM has started to release solutions that aren't tied to a specific brand (WebSphere). I am working on such products and solutions and again not a great fit for the WebSphere blog.

4. I have changed focus and jobs within IBM four or so times within the last ten years. I would like this blog to stay around forever, regardless of what focus I have.

5. To be brutally honest, one of the best parts of being on the WebSphere Community blog was the traffic. When there is a search for WebSphere blog on Google, the WebSphere Community Blog is the first entry. We see a steady stream of traffic there. I think over time, people reading blogs starting from the top down will change. I know I have a steady stream of followers on Twitter and expect that no matter where my content is, my followers will see it and if its the best content on the topic, specific posts will show in Google searches.

6. All the above points have discouraged me posting in the last year or so. I'm hoping making the move will encourage me to start blogging again.

Let's see how active I become on this blog. I will still try to cross post WebSphere related posts, but for now, lets hope iSpyker.blogspot.com thrives all on it's own.