Greetings WOW members and Web professionals everywhere. Bill Cullifer here with the World Organization of Webmasters (WOW) and the WOW Technology Minute.
Today?’s podcast is a continuation of the media coverage of Web Builder Conference, Las Vegas. If you?’ve been following along with the series, then you know I sat in on a variety of great sessions covering the world of Web Development. I also had the pleasure of interviewing a number of speakers including Richard Campbell Product Evangelist Strangeloop Network based in Vancouver, British Columbia. Richard presented on the topic of “Performance Isn’t Optional Making Web Services Work”.
Often the motivation for bringing web services into the enterprise is not performance – its about interoperability. But performance is not optional, without performance, interoperability becomes an exercise in frustration. Richard’s session dug into the strategies that an architect can employ in the design web services so that performance is a feature of web services, rather than an obstacle.
Check out the three minute interview on today’s WOW Technology Minute website.
Today?’s WOW Technology Minute is brought to you by WebProtraining.org, offering a complete solution for all your Web professional training needs including WOW certification options. Check it out at Web Professional Training website.
Transcript of Making Web Services Work-Performance Isn’t Optional–Interview with Richard Campbell
BILL CULLIFER: Bill Cullifer here with the World Organization of Webmasters (WOW) and the WOW Technology Minute at Web Builder 2.0 Las Vegas. I have the pleasure of interviewing Richard Campbell, Product Evangelist at Strangeloop Networks out of Vancouver, BC. Good morning, Richard. Excellent presentation today on “Performance Isn?’t Optional, Making Web Services Work.” Can you summarize that session for us?
RICHARD CAMPBELL: Sure. Web Services are usually built mostly for interoperability. Folks are really focused on what does it take to get all of my different disparate systems working together and the Web services are the lowest common denominator. It?’s not a really performant protocol. Often it tests well, because we don?’t have a lot of requests running at once and we?’re inside that nice, fast LAN connection and Web Services often end up being bigger than they thought, the packages come back much larger than they thought and requested a lot more. Often these interoperability exercises are really successful and they have apps that are in high demand because they work across all those different systems.
This talk really came from my experiences as a consultant dealing with these companies that get caught by surprise. Really it came from their own success. I cited a particular case where a client went from maybe 10,000 requests a day off of mainframe when they wrapped it in Web Services it jumped up to 750,000 requests a day and it was just burying the machine. It turned out that those requests were almost all identical, so by adding a caching layer in we were able to take a lot of stress off that server in a big hurry. The net effect ultimately is that they didn?’t have to upgrade their mainframes or rewrite any systems. Understanding where they performance problem is, is the biggest challenge.
A great deal of the talk that I just did here was really about, what do we instrument, where do we instrument, because most people don?’t understand where their Web Service pain is coming from. They?’re looking at the far end, at that consumer end, and saying, “This site?’s too slow.” As the owners of that product we have to dig in deeper and say, “Well where are we too slow?” One of the big whammies I see with Web Services over and over again is that requests end up coming back as much too large; they?’re marshalling megabytes of data and they didn?’t really need it. It?’s just that it hasn?’t been thought through enough to be efficient.
BILL: Yeah. Well said. You had a couple of specific walk-aways too. For example, for the listeners of this podcast or developers out in the world, what would you like us to walk away with?
RICHARD: Really there?’s a couple of elements we talked to. I talked to the performance equation, which really decomposed our overall request time. It looked at the payload and the bandwidth but we also broke out, what?’s our latency like? Are we dealing with a long-range communication here? Do we have problems with connection speeds? And also separating out the time it takes for the server to compute it and the time it takes for the client to compute it.
One of the pains we get in with Web Services is really we?’re translating binary data into text, then we?’re translating it back again. That marshalling overhead is expensive. It takes a long time. And it?’s one of those hidden penalties to Web Services. So one of the suggestions I made, and there was a variety of them, not only tricks around cache and doing work once and taking only the data we really need, but do we really need a Web Service here? If we have a really popular app, could we go to a more performant protocol? Does it make sense for this scenario? I know that Web Services are a good choice overall, and I?’ll leave that layer in place so that it?’s very compatible and works with everything, but for a particular app we might find that it?’s worth making the S and A call, just skip over all that translation. Or maybe we?’re calling out to java and we?’ll use a java interoperability layer for it. That?’s the choice we can make. It makes sense once we?’ve properly instrumented the column and once we?’ve properly diagnosed it, this is the issue, that it?’s the marshalling or it?’s the time it takes to translate that data back and forth, that we can eliminate those pieces.
BILL: Yeah. Great summary and excellent walk-aways. We appreciate that.
RICHARD: My pleasure. Anytime.