RSS

Performance Engineering for the Developer

Fri, Nov 21, 2008

Staff Posts

Few application developers were ever trained to consider that the network is just another resource to be managed. Treated as a resource, it should be considered just like CPU, Memory, and Database efficiency. For most, the network is a “magic black box,” and in traditional development environments, the client and server(s) are located very close to one another or even in VM’s on the same desktop. While this facilitates rapid development, the developer is never exposed to how they are using (or mis-using) the network resource.

By pulling network emulation into the product development lifecycle as early as possible (developer unit test), the application has the opportunity to mature prior to Integration, QA, Load, Performance, and Scalability testing. Naturally, the earlier in development any “bugs” are identified, the cheaper they are to correct.

By creating real-world deployment conditions, Shunra’s VE Desktop aids the development process by exposing client performance “bugs” early. The developer can quickly determine what if anything is not performing as expected. Additionally, by using some of the advanced features and/or add-ons, the developer can reveal the details of how the network resources are used, and even delve into root-cause analysis.

I would encourage any developer to add network emulation to their arsenal of tools, and strive for superior application performance, and deployability.

, , , , , , , ,

share

2 Comments For This Post

  1. Les Murphy Says:

    It is unfortunately all too easy to build applications that are “chatty” on the network. This means that apps generate a request, wait for a response, and then issue another request. Each request will run very fast in a LAN environment, but much slower over a production network.

    Andrew’s suggest is a great one – include the network environment during initial development tasks, so any architectural performance issues are uncovered early in the development project.

  2. Scott Moore Says:

    Engineering performance into the lifecycle instead of testing it into the final product two weeks before go live just isn’t going to cut it anymore. It would be great to see developers take just a few moments and performance test their code from the end user experience, including under realistic network conditions the end use might see. Great idea.

Leave a Reply

Get Adobe Flash playerPlugin by wpburn.com wordpress themes