We were doing some performance analysis recently of our application. The application is distributed across a central J2EE AS component, with satellite nodes running under Tomcat connecting to the central J2EE server.
We used JProbe to collect the baseline performance data and locate the hot spots. I have all positive to say about this product. I was focused on the Tomcat part, but the people who used it on the J2EE side also spoke well of it.
For Tomcat, setup was a breeze. It was all simple click through wizards. JProbe has a built in Tomcat module and it works great for Tomcat 5. The setup worked properly the first time I ran it.
The stats it collected were right on. They provided all the data I was looking for. The results were presented in a useful way that allowed me to see the key summary parts while also being able to drill down to the level of detail I needed.
At one point I wanted to focus on CPU utilization in the remote Tomcat servers. I was able to easily reconfigure my JProbe session to measure CPU usage instead of default clock time. It worked just great and quickly isolated some key areas. The areas it found were not the sections we thought were problematic. So JProbe saved us a lot of effort.
Thursday, May 18, 2006
Wednesday, May 10, 2006
Remote control
It's just so impressive what you can do remotely these days. The software is great and the CPUs and networks are now fast enough to make it work quite well. Here are a couple of examples.
Sitting at my home on a weekend I get a call about a support issue.
- from my home PC I connect to a VPN at the Halifax office
- from the VPN I'm able to remote desktop to my work PC. The GUI and everything comes up properly. It is responsive. Close enough to the real thing that I'm able to work without really noticing I'm logged in remotely. Remote desktop is just an awesome piece of work.
- from the remote desktop session I use Funk to connect to another server on a different continent. Again everything is responsive. The mouse works the way you expect. I can copy and paste from computer to computer and it all works easily
- after I Funk'ed into the computer on the other continent I was able to see what they had and do the fix
- the chain is home PC -> office VPN -> office PC -> server on a different continent
Here's another example
- sitting from my home PC I connect to the office VPN
- from the VPN I remote desktop into my work PC
- from remote desktop off my work PC I launch an xterm to a UNIX server in the office
- from the xterm window I ssh into a different UNIX server in the office
- the chain is home PC -> office VPN -> office PC -> virtual xterm session -> virtual ssh session
I just find it remarkable all the layers of indirection, all the encryption, all the network traffic. And it comes up great and is nearly as crisp and responsive as being there.
Remote desktop provides other advantages. Before RDP, when it was busy at the office, I had to be physically in the office to put in the extra hours. This meant I sometimes had to arrive at work horribly early. Or it was disruptive staying late or going in on a weekend. Now I can usually put in the extra time from home and still be able to do other stuff around.
The thing you have to be careful about with RPP is you can get a bit too attached to the office. Like just extending your office day from home after supper every night. It can be a bit "addictive".
It's OK in non-peak times to log in for a few minutes in the evenings and check your late in the day e-mail. Or pick off some small thing that was nearly done when you left. But keep it balanced. Your time away from the office is just that.
Sitting at my home on a weekend I get a call about a support issue.
- from my home PC I connect to a VPN at the Halifax office
- from the VPN I'm able to remote desktop to my work PC. The GUI and everything comes up properly. It is responsive. Close enough to the real thing that I'm able to work without really noticing I'm logged in remotely. Remote desktop is just an awesome piece of work.
- from the remote desktop session I use Funk to connect to another server on a different continent. Again everything is responsive. The mouse works the way you expect. I can copy and paste from computer to computer and it all works easily
- after I Funk'ed into the computer on the other continent I was able to see what they had and do the fix
- the chain is home PC -> office VPN -> office PC -> server on a different continent
Here's another example
- sitting from my home PC I connect to the office VPN
- from the VPN I remote desktop into my work PC
- from remote desktop off my work PC I launch an xterm to a UNIX server in the office
- from the xterm window I ssh into a different UNIX server in the office
- the chain is home PC -> office VPN -> office PC -> virtual xterm session -> virtual ssh session
I just find it remarkable all the layers of indirection, all the encryption, all the network traffic. And it comes up great and is nearly as crisp and responsive as being there.
Remote desktop provides other advantages. Before RDP, when it was busy at the office, I had to be physically in the office to put in the extra hours. This meant I sometimes had to arrive at work horribly early. Or it was disruptive staying late or going in on a weekend. Now I can usually put in the extra time from home and still be able to do other stuff around.
The thing you have to be careful about with RPP is you can get a bit too attached to the office. Like just extending your office day from home after supper every night. It can be a bit "addictive".
It's OK in non-peak times to log in for a few minutes in the evenings and check your late in the day e-mail. Or pick off some small thing that was nearly done when you left. But keep it balanced. Your time away from the office is just that.
Wednesday, May 03, 2006
EJB is not portable
Remember when Java bragged about being "write once, run anywhere"? Well in EJB land that does not seem to apply.
We did a port of a J2EE application to a new application server. We were able to finish it. I'd say that about 70% of the porting effort was spent on EJB. Around 15% was the GUI servlets. Around 15% was other stuff like documentation and the ant scripts and some J2SE clients.
The servlet stuff went well. There were just a few small things we were doing that were against the servlet spec that the first application server allowed, but the new one didn't. Easily identified and fixed.
EJB was a much different story. So much of it is vendor specific with designed lock in that porting is so much more effort and complicated. It just shows how painful everything is in EJB. It's painful just getting stuff to work on the original application server, let alone porting it to another one.
That's just not the Java way. Originally people liked it and used it because it was portable. When something is painful to port and requires code changes to port like EJB then that is not in the spirit of Java. It may be short term advantageous to application server vendors to discourage porting or make it expensive. But long term it's a bad thing. It undermines the cross platform spirit of Java and comes across as bait and switch.
I've grumbled about EJB before. I just don't get EJB or why people would choose it. It is painful to do anything in. It is so verbose with all the endless and non standard XML files. There are all these code restrictions that annoy and frustrate the programmers. Weird and tedious concepts and terminology in the EJB spec. Bewildering arrays of modes and options. Good luck connecting from an external J2SE program.
At every turn EJB comes across as developer hostile. Without developer support it will have a tough go of it long term. It's no surprise that new competing technologies have emerged and have gained support.
If I was the decision maker and was starting something brand new in Java with no legacy code base then I would not choose EJB. Just stay clear of it entirely and everyone will be happier and better off without it.
We did a port of a J2EE application to a new application server. We were able to finish it. I'd say that about 70% of the porting effort was spent on EJB. Around 15% was the GUI servlets. Around 15% was other stuff like documentation and the ant scripts and some J2SE clients.
The servlet stuff went well. There were just a few small things we were doing that were against the servlet spec that the first application server allowed, but the new one didn't. Easily identified and fixed.
EJB was a much different story. So much of it is vendor specific with designed lock in that porting is so much more effort and complicated. It just shows how painful everything is in EJB. It's painful just getting stuff to work on the original application server, let alone porting it to another one.
That's just not the Java way. Originally people liked it and used it because it was portable. When something is painful to port and requires code changes to port like EJB then that is not in the spirit of Java. It may be short term advantageous to application server vendors to discourage porting or make it expensive. But long term it's a bad thing. It undermines the cross platform spirit of Java and comes across as bait and switch.
I've grumbled about EJB before. I just don't get EJB or why people would choose it. It is painful to do anything in. It is so verbose with all the endless and non standard XML files. There are all these code restrictions that annoy and frustrate the programmers. Weird and tedious concepts and terminology in the EJB spec. Bewildering arrays of modes and options. Good luck connecting from an external J2SE program.
At every turn EJB comes across as developer hostile. Without developer support it will have a tough go of it long term. It's no surprise that new competing technologies have emerged and have gained support.
If I was the decision maker and was starting something brand new in Java with no legacy code base then I would not choose EJB. Just stay clear of it entirely and everyone will be happier and better off without it.
Saturday, April 15, 2006
Get Ethereal
At work we were having some interop problems between our server and some DSL devices. I wanted to get some packet traces to see what was going across the wire in both directions.
Needing some software for this, I Googled around a bit. There were some commercial products. Most of the commercial products were big elaborate network management suites. I just wanted to sniff some traffic between my PC and a device. Looking around a bit, I found Ethereal.
Ethereal is free to download. It did what I wanted, allowing me to analyze the traffic and get a nice detailed view of what was going on. I recommend Ethereal for packet sniffing analysis. Pretty good for free. The commercial products were starting around $995.
Ethereal is just one of many free and open source products I use all the time. Here are some others I use now or have used heavily in the past.
What does it mean? Well in those areas above, it would be tough to sell me something when there is a quality alternative that I can download and use for free. Why pay $995 to sniff traffic when Ethereal is free? Why pay for a Java IDE when Eclipse is outstanding and free.
That's kind of the thing about open source. The stuff is great for a programmer as it makes your life so much easier and more productive. However, developing commercial software, you can see a potential threat to your company's area if a strong open source alternative was available. Where I'm at in consultingware, we tend to be industry specific, with services work with each sale. Since were not mass use general purpose we're probably not too threatened by open source at this time.
Needing some software for this, I Googled around a bit. There were some commercial products. Most of the commercial products were big elaborate network management suites. I just wanted to sniff some traffic between my PC and a device. Looking around a bit, I found Ethereal.
Ethereal is free to download. It did what I wanted, allowing me to analyze the traffic and get a nice detailed view of what was going on. I recommend Ethereal for packet sniffing analysis. Pretty good for free. The commercial products were starting around $995.
Ethereal is just one of many free and open source products I use all the time. Here are some others I use now or have used heavily in the past.
- Eclipse, plus a number of quality free plugins
- Python
- JBoss
- Emacs
- SgMibSpy
- PHP
- Tomcat
- Apache Web server
- All kinds of Apache Jakarta Commons Java libraries
- MySQL
- Ant
- Java JDK
- Linux
- Firefox
What does it mean? Well in those areas above, it would be tough to sell me something when there is a quality alternative that I can download and use for free. Why pay $995 to sniff traffic when Ethereal is free? Why pay for a Java IDE when Eclipse is outstanding and free.
That's kind of the thing about open source. The stuff is great for a programmer as it makes your life so much easier and more productive. However, developing commercial software, you can see a potential threat to your company's area if a strong open source alternative was available. Where I'm at in consultingware, we tend to be industry specific, with services work with each sale. Since were not mass use general purpose we're probably not too threatened by open source at this time.
Sunday, April 09, 2006
New CEO
We've hired a new CEO at work. Since I joined Core Networks in the summer of 2001, this is the fifth CEO I've had. We also preannounced this quarter. This is the third time in the last seven quarters we've preannounced. I don't think many people are expecting the new leader to just maintain the status quo.
In the nine years I've been in software, there's been some interesting times. I've been acquired three times. I've survived eight downsizings. I left a job on my own. I've been fortunate to not yet been downsized. I've also not yet been in an office or company that was shut down. So far so good.
As always I'm grateful to on the inside working in high tech. The pay and benefits are good. The coffee is free. The work can be challenging and interesting at times. The cubicles are comfortable. The office is climate controlled. The PC is fast and the monitor big.
The change is a fact of life in high tech. I sometimes miss the stability and continuity of PRIOR Data Sciences back on Spring Garden Road. It was civilized, things were done a certain way. Spring Garden Road was happening and downtown. Alas, PRIOR is no more.
In the nine years I've been in software, there's been some interesting times. I've been acquired three times. I've survived eight downsizings. I left a job on my own. I've been fortunate to not yet been downsized. I've also not yet been in an office or company that was shut down. So far so good.
As always I'm grateful to on the inside working in high tech. The pay and benefits are good. The coffee is free. The work can be challenging and interesting at times. The cubicles are comfortable. The office is climate controlled. The PC is fast and the monitor big.
The change is a fact of life in high tech. I sometimes miss the stability and continuity of PRIOR Data Sciences back on Spring Garden Road. It was civilized, things were done a certain way. Spring Garden Road was happening and downtown. Alas, PRIOR is no more.
Monday, April 03, 2006
I'm LinkedIn
I heard from a former coworker last week. She invited me to join her network on LinkedIn. It looked interesting and I respect her, so I joined. So now I'm LinkedIn, yay for me.
My network only contains the one person, so I should try to increase it I guess. I'm not sure who I should ask to join. It would be a good time to try to find some of my old TUNS (now DalTech) fellow students and find out how they are doing. Back then around 1/2 the TUNS CS Class of 1997 joined Nortel, who I'm sure would have hired the other half too if we'd wanted to join. I wonder what became of them. At least of some of them are likely still there, but certainly not all of them.
My friend's network was interesting. She has around 12 people. Some of the names I recognized as people I'd worked with before. One guy I knew from St. Mary's and TUNS. Some of the others were well known players in the local startup scene. It was pretty good company to be in, so it's nice to be remembered positively after we'd worked together in the past.
One time there was this insane Core Networks project where she was team lead and everyone was working really hard on it. There was a key integration testing weekend before the first baseline went to the test team, and she said that everyone was on call and had to come in if problems were found in their area. I had a quiet weekend. On the Monday after she told me she'd phoned everyone else in the department over the weekend except me with code issues. No problems were found in my code. That's kind of a party trick I have of writing all kinds of features and lines of code with very low defect rate, something I take pride in. I take bugs in my code personally, but in my career I've noticed that few others do. Most people I've ever worked with are indifferent to bugs in their code.
It has made me realize I've been part of the Halifax software startup scene for nearly five years now. In my own modest way I've contributed to building a new company, and to building the Halifax software industry. I think it will be interesting to see what directions my career takes in the next five years.
My network only contains the one person, so I should try to increase it I guess. I'm not sure who I should ask to join. It would be a good time to try to find some of my old TUNS (now DalTech) fellow students and find out how they are doing. Back then around 1/2 the TUNS CS Class of 1997 joined Nortel, who I'm sure would have hired the other half too if we'd wanted to join. I wonder what became of them. At least of some of them are likely still there, but certainly not all of them.
My friend's network was interesting. She has around 12 people. Some of the names I recognized as people I'd worked with before. One guy I knew from St. Mary's and TUNS. Some of the others were well known players in the local startup scene. It was pretty good company to be in, so it's nice to be remembered positively after we'd worked together in the past.
One time there was this insane Core Networks project where she was team lead and everyone was working really hard on it. There was a key integration testing weekend before the first baseline went to the test team, and she said that everyone was on call and had to come in if problems were found in their area. I had a quiet weekend. On the Monday after she told me she'd phoned everyone else in the department over the weekend except me with code issues. No problems were found in my code. That's kind of a party trick I have of writing all kinds of features and lines of code with very low defect rate, something I take pride in. I take bugs in my code personally, but in my career I've noticed that few others do. Most people I've ever worked with are indifferent to bugs in their code.
It has made me realize I've been part of the Halifax software startup scene for nearly five years now. In my own modest way I've contributed to building a new company, and to building the Halifax software industry. I think it will be interesting to see what directions my career takes in the next five years.
Subscribe to:
Posts (Atom)