• Home
  • RSS Feed
  • Log in

Web performance in seven steps; step 2: Execute a proof of concept
Posted by Jeroen Borgers at around evening time: June 15th, 2009

Last week I blogged about setting your performance goals: defining your requirements. This time I'll blog about the importance of a Proof of Concept for performance.

The IT world is very sensitive to trends. Having been around in the IT industry for 15 years, I’ve seen a few. A technology is hot for a while, and then quickly becomes out-of-fashion and yesterdays news. It will be replaced by something which is much better and what everyone follows almost blindly.

Such fashion items are for example CORBA, CGI, applets, EJB, Struts, Spring, Server Faces, XML, SOA, OMT, UML and RIA to name a few. Often new, bleeding edge technology is used in a project just for the sake of being trendy. In addition, each technology or framework comes with its own teething troubles and largely uses more resources than its predecessor. Goal of such a new technology is generally improvement of flexibility, productivity or maintainability, and performance usually has no priority or has not even been considered at all.

Therefore, it is questionable if the chosen new technology and architecture will meet the specified performance requirements. In practice, this regularly becomes only evident in a late stage of the project: when it has already slipped beyond the planned production date. Only then it may become clear that the chosen technology or architecture is just not sufficient. And switching to a different technology or architecture usually results in high cost and long delays. Therefore it is essential to execute a Proof of Concept for performance in which all technology and architecture components are touched, in a vertical slice of the application. It is important that this test is performed in a sufficiently representative manner, on which I will elaborate in my next post. By executing this PoC and understanding and using the results of it, the project can early be corrected in the right direction to prevent excessive cost and delay.

Next time I'll blog about step 3: representative performance testing.

  • Share/Bookmark

Tags: Architecture, Java, Performance
Filed under Architecture, Java, Performance, Quality Assurance, Requirements Management, Testing | No Comments »



No Responses to “Web performance in seven steps; step 2: Execute a proof of concept”



Leave a Reply

Click here to cancel reply.

Deployment automation for Java application running on Websphere, WebLogic and JBoss

Archives

  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009

Training

  • Tackling Top 10 JavaEE Performance Pitfalls
    13 & 14 May 2009

Xebia Sites

  • Xebia Corporate
  • Xebia France
  • Xebia India

Categories

  • Java (282)
  • Agile (109)
  • General (50)
  • Testing (42)
  • Performance (42)
  • Hibernate (36)
  • Scrum (33)
  • Podcast (31)
  • Architecture (31)
  • Spring (28)
  • SOA (24)
  • Maven (22)
  • Project Management (22)
  • Middleware (23)
    • Deployment (14)
  • Flex (17)
  • JPA (17)
  • Eclipse (15)
  • Xebia Labs (15)
  • Quality Assurance (14)

Tag Cloud

    Groovy Scrum Seam Testing Agile Awareness Workshop Maven Lean IntelliJ Semantic Web Closures Grails Java SOA Architecture Poppendieck Xebia product owner JavaOne Scala Performance Functional Programming Introduction to Agile esb Agile XML qcon Hibernate Ajax Spring fitnesse