Discussions

Performance and scalability: performance hampered by design patterns

Bookmark and Share Get thread feed

  1. performance hampered by design patterns (6 messages)

    • Posted by: bow poo
    • Posted on: May 16 2002 12:23 EDT
    Hi,

    I have a question about the performance of architectures that employ well knoen design patterns.

    Assume the architecture is as follows;

    1) Client layer uses HTTP to get to servlet
    2) frontController servlet filters and passes on the request to a servlet that does the real work
    3) this servlet calls a method on an EJB
    4) the EJB makes a call on a JDO (Java Data Object)
    5) the JDO makes (jdbc) calls to the database


    So there are 5 layers to penetrate to get data from the database to the client.

    These layers add value e.g. JDO layer insulates the rest of the system from schema changes.
    But at the same time, the more layers there are the worse the performance should be.


    Does anyone have any thoughts on this?
    Is performance worse if you use these design patterns?
    should you pay close attention to key areas and avoid some of the patterns for performance reasons?


    regards,
    Bow
    ------
    Reply to this

    Threaded Messages (6)

  2. performance hampered by design patterns[ Go to top ]

    Hi,

    Good design does impact performance to some degree. At the end of the day you could write a JSP that calls a Stored Procedure and your performance will be great. This is pretty much what MS did in their Pet Store demo. Of couse they then claimed rightly it performend better than the J2EE implementation that is based on showing a good design approach.

    I am not saying performance is not important but at the end of the day it is not the only factor in a building a system to be proud of. Good design should produce a solution that is maintanable, extensable, reliable and performs within expectations.

    Certain bad design mistakes often lead to bad performance. Overuse of XML, RMI and badly designed data model access are common issues. This are oftern corrected by implementing certain good patterns.

    David
    Reply to this Reply to original

  3. performance hampered by design patterns[ Go to top ]

    Is not a good design one which meets the needs of the business intiative a system is trying to implement? As architects, I believe our responsibility is to design the best system that meets the constraints (budget, resources, time-to-market) imposed by the project. All too often I have seen systems that were over-engineered, over-budget and months beyond the required implementation date, for the sake of somebody's interpretation of good design.
    Reply to this Reply to original

  4. performance hampered by design patterns[ Go to top ]

    Hi,

    Over engineering and its counter part under engineering is indeed a situation ever good engineer wants to stay clear off.

    In the end I suppose a "good design" is one that meets our project managers requirements, the business requirements and the architectural requirements.

    Anyway we seem to have moved off the original discussion point ;-)

    David

    Reply to this Reply to original

  5. performance hampered by design patterns[ Go to top ]

    You are thinking about performance, yes, I'm sure the MS approach with ASP calling stored procedures might perform better... for 1 user, or 3, but how about 25 simultaneous users? 50?

    You are forgetting about scalability. Application servers and server side component models (such as EJB) were designed to address this issue.

    That's why MS's applications "beat" all benchmarks, when it comes to one or few users and fail to perform in the real enterprise environment.

    -Oleg Kozlov.

    Reply to this Reply to original

  6. performance hampered by design patterns[ Go to top ]

    Bear in mind that all these layers are purely logical and can run within the same JVM. In which case your overhead is simply a method call or call to a factory and then a method call. I would assert that with the proper caching techniques (e.g., caching homes and avoiding JNDI lookups) single-layer system will not have any substantial gain in performance over multi-layered system. Moreover, in theory your single-layer system may loose to multi-layered approach because efficient persistence tier may use pretty aggressive caching or preloading which is difficult to implement if you need to hand-code everything.

    The number of layers is not about performance, it is about the design. After all in OO we don't ask the question whether we need one class or multiple, so why layers should be different? Layers are just the way to package functionally related classes.

    Alexander.
    Reply to this Reply to original

  7. performance hampered by design patterns[ Go to top ]

    You have to avoid the temptation to employ every single design pattern in every project you undertake. You have to decide whether you need the functionality offered.

    If your front end is simple you may not need a FC, similarly you may not need JDOs. There is also often a tradeoff in functionality over performance, although many of the EJB design patterns will help inexperienced developers achieve performance in their applications... such as using a facade rather than referencing all those EJBs from the client.

    The main point of the architecture you outlined is to separate the various layers so that changes to Database code don't get reflected back to the client. I've worked on a number of J2EE projects and can see the value of this. I see less value in constructing huge generic frameworks which will address all the future needs of the project (NOT!)

    David
    http://www.kimble.co.uk/
    Reply to this Reply to original