Loosing of performance on Service Layer

Damir Dobric Posts

Next talks:

 

    

Follow me on Twitter: #ddobric



 

 

Archives

Loosing of performance on Service Layer

 
 Category            WCF 

The architecture one modern application in this century requires the usage of service layer, which ensure the service orientation.
Many people think that such architecture is theoretically nice, but practically not usable. The reason should be a performance.
This is why we done this test which should show how much does the service layer really impact the performance? If you do not want to read this and would just like to know the answer, here it is:

Service orientation impacts the performance of the application, but much less than most people think.

Our test is build on the top of following architecture:



The database in this test is the SQL Server 2005. Some tables in this database contain several millions of records. The data access layers enforce multiple query with several joins. The result shown is related to two operations. The operation 1 is the light one and returns about 300 records. The operation 2 ist the heavy one and it queries a millions of records in multiple table. The result of this operation returns about 1000 records. In this test we used the WsHttpBinding with message security.

The WebService contract is implemented in the service layer (InvokeOperation1() and InvokeOperation2()). Both operations return the array of some business objects styled as a message containing data contracted types (As usual in WCF). The implementation of the service in ServiceLayer just invokes the corresponding methods in the BusinessLayer and converts the result from List<Type> to array of that type: List<Type>.ToArray().

BusinessObject1[] Operation1()

{
  BusinessLayerApi api = new BusinessLayerApi ();
  List<BusinessObject1> res = api.Operation1(par1, par2, par3);
  return res.ToArray();
}

The Business Layer internally creates the instance of DataAccess Layer, which executes the query and returns the reader. After all,
the EntityAdapter converts one row in reader to the target BusinessObject1. The idea behind this is that practically every data object
requires some kind of conversion to some publicly visible object.

  List<BusinessObject1> Operation1(string par1, string par2, string par3)        {            DataAccessLayer dal = new DataAccessLayer();            using (SqlDataReader reader = dal.GetResult(kuerzel, locations, categories))            {                while (reader.Read())                {                    Result res = EntityAdapter.FromResultReader(reader);                    results.Add(res);                }            }        }

Note that in this scenario the database is located on some remote machine connected with 1GBit Network Adapter. The client and the service are both on the same machine. We know that this is in some cases not enough realistic scenario. Later more about this.

result for operation1. (100 calls)


Service Layer

22236.34
Business Layer 22236.34
Resource Layer 17674.42
Entity Adapter 4510.23
 



Result for operation 2 (100 calls)

Service Layer

74427.75
Business Layer 74427.75
Resource Layer 70800.84
Entity Adapter 3499.29



Result for operation 2 when client, service and database are located on three different machines (100 calls).

Service Layer

10650.00
 

1.       If the Business Lauer already implements all your service need (this is our case) the performance loose for just converting of the data is almost not existent. That means that implementing of the service layer has no negative impact on performance.

2.       If the service layer does some power job, because the business layer has not been designed for this task, the service layer will probably have a negative impact on performance.

3.       Usage of EntityAdapter (recommended by Pattern&Practices. See Don’s blog.) does not impact the performance too much. As you see, the bigger amount of data queried, less Adapter impact expected. Please note that adapter used in this test just does the copy of database related object to business object!

4.       Test in this post shows that pure adding of layers on the top of .NET and WCF is not a real negative performance impact. In reality you will probably have to do much more in business layer and service layer than these samples. In this case you do what you have to do. However by designing of application you will not lose too much if all layers are well designed in SOA manner.

5.       When the system is distributed over three layers (three tire) the network transport between client and service can have negative performance impact from 15-30% (without of compression) comparing to performance measured from the point of view of the service (message enters the service layer, the operations is executed and resulting data is serialized in the service).

  I would be glad to see your comment on this.

PS. All given values are in milliseconds.
 



 

 


Posted Sep 03 2007, 05:13 PM by Damir Dobric
Filed under:

Comments

Christian Weyer wrote re: Loosing of performance on Service Layer
on 09-04-2007 9:07

Oh yeah: if I were to drive on the plain chassis of my car then it would be more light-weight and surely would 'perform' much better on the German Autobahn - wouldn't it?

Well, no, as

a) they would allow me to drive this vehicle and

b) I would surely - after some time - add more new stuff to this vehicle so that it will actually look,l behave and feel like a car.

It is not about 'Loosing Performance' but rather negotiating which additional features you really need and which additional overhead you are willed to pay based on an analysis beforehand.

Just my 2 Euro-Cents.

developers.de is a .Net Community Blog powered by daenet GmbH.