webservice response times --How can we improve ?

[Former Member]

Hi All,

I am making two different calls to a Function module from java

1. web service 2. Jco

When I go to STAD transaction i can see webservice response timings are more compared to Jco.

What intresting here for is CPU timings and DB timings.

Some case The DB timings for webservice 3 to 4 times more than Jco .

Ideally DB timings should be similar in both the cases..right ??

CPU timngs also more in webservice ? Why ? How we optimze this for good performance of web service ??

My webservice is simple one conatins 4 input parmaters (simple type) retuening a simple structure.

Jco response time is around 500-2000 (ms)

web service response time is 2000-5000 (ms)

Looking for expert suggestions from our community

Thanks in advance.

Best Regards,Anilkumar

[Former Member · Accepted solution]

Hi Anil,

The hard fact is that you can never get the performance of a webservice better than JCO in any case either you use extra hardware or other tuning methods.

The performance area is always a concern for Web Services after it became popular. Now development is towards new and effective XML parsers which can reduce the serialization timings and improve performance.

However you can always improve (and approach near to RFC/Jco call) the performance by applying the methods given above in the chain reply .

Regards,

Piyush

[Former Member · Accepted solution]

Hi Piyush,

Yes you are right. Jco is faster than web services.

I am looking more into different areas so that we can bring down the web service response timings .

My discussion is more towards the areas that we can touch /concentrate to get better performance.

1. No of attributes in the message.The FunctionModule may have 10 Inputs and 10 Outputs but we may not require all .So we can optmize the web service Interface on ABAP. This is one I can think of as far as web service Interface is concerned. ( I am not taking the coding of FM into consideration assuming that coding standards are fine)

2. What optmization/tuning can we do on the web server ??

We can increase the no of Dialog users on the web server so that you can pass more concurrent HTTP requests .This will reduce the waiting time for your request which will improve your response times....Am I right ??

3. My each web service request is of size 10 MB and webserver is receiving 100,000 requests at a time .

In this case what are the minimum memory requirments to handle such a requests whitout any problems ?

Thanks,Anil

[Former Member · Accepted solution]

Hi Anil,

Both the tuning of web server and memory requirements can be better handeled by your basis/admin team.

You can also try out calling a web service by a dedicated line to your web server as network traffic also contributes a lot towards bad performance or reponse time.

If you are Java guy , just go through these links below "how to increase the performance for Web Services".

http://java.sun.com/developer/technicalArticles/WebServices/fastWS/

http://java.sun.com/developer/technicalArticles/WebServices/high_performance/

Regards,

Piyush

[Former Member · Accepted solution]

Hi,

Have a look to this blog => /people/daniel.mcweeney/blog/2007/01/09/web-services-overhead

Regards

Thomas

[Former Member]

Hi Anil,

I had the same question and asked this question to few SAP Experts at a SAP workshop and the conclusion from that discussion is that tuning and adding more hardware / memory is the only way to improve the performance.

I expressed my views on a weblog on the same subject few weeks back too. check the <a href="/people/arulraja.ma/blog/2007/09/24/esoa--technical-point-of-view--ii weblog</a>

[Former Member]

Hi Raja,

Thanks for your response.

Nice weblog. So by adding the more memory and hardware we can bring down the webservice response timings ??

Anilkumar

[Former Member]

Yes. As i mentioned earlier, performance tuning is essential too. I think this is the case of finding a balance between Performance/Cost vs Flexibility of IT Infrastructure.

Arul

Message was edited by:

Arul Raja

[Former Member]

<u><i><b>My webservice very simple one which takes 5 parameters (simple type ) and returns a simple structure.It just returning 2 records.</b></i></u>

and I need more hardware?????

I hope you are working in SAP engagement for some Oil company or health insurance firm. Personally I think they are the only two type of client has money to listen to stupid recommendation such as this and buy hardware.

Yours is a basic software engineer's problem and you should not recommend to load more hardware for a simple web service performance issue.

I think at this point it is most important to do some home work about software computing, how a software code execute in a hardware and OS etc, understand the context and learn the magic behind the computing.

This take me to an instance of the largest telecom company's supply chain SAP implementation, performance tuning around SAP integration using IWAY adaptor, JCO and web services and some of the most stupid comment i ever listened to BASIS people and their ignorant knowledge about basic computing behavior analysis.

All I can say when people attend 3 months training in some indians cities without any basic knowledge about computer science, or electronics and show up some where in USA or some where to make use of high demand in SAP job and make reasonably good money working in SAP customization job without even reading a simple book in OS, kernel, socket, work unit, transaction, concurency, parallel processing, all we can expect from is tell the client "BUY MORE hardware" your problem will be resolved .

Good luck buddy. You have tremendous information in this thread to solve the performance issue around simple web service, irrespective of whatever platform on which you are cooking it and all you have to do is "DO the home work"

Thanks

[Former Member]

Hello Guru Shaji ,

My recomendation was in addition to your original recomendation of Performance Tuning. I have even mentioned this in my reply. First read the replies properly before rushing in to your own conclusions about others recomendations.

See my original reply to anil's question:>>

<<<<<<

I had the same question and asked this question to few SAP Experts at a SAP workshop and the conclusion from that discussion is that <u><b>tuning</b></u> and adding more hardware / memory is the only way to improve the performance.

>>>>>>

So let me stress the fact that performance tuning of any application/software and proper development methodology is essential.

You could be correct in your comment regarding my engagements with Oil or health insurance company. Those are the companies who have complex system landscape and resource intensive applications. They need more hardware to boost the performance.

Arul

[Former Member]

Hi there,

I am no sysadmin so I can't tell you how to tune the system. I just can talk about my observations.

1. I don't believe that there can be an actual difference in DB timing. After all, both Jco and webservices pass the request to some function modules (and further pure ABAP) where DB selections occur. So, there should not be a difference in access times since the SOAP runtime doesn't really access the DB (heavily). Probably you did your test cases with webservices first and then tried to do the same call using Jco, where the DB selects were already cached.

2. heavier CPU load for webservices seams reasonable since the XML processing is ressource intensive, even with the optimized simple transformations (ST) used.

Systems I work on are (most of the time) well equipped and tuned. For rather simple services (such that do not depend on heavy business functionalities) I get response times for 0.1 to 1 sec on average.

A real limiting factor in my experience is network bandwidths and XML size(compared to better packed formats). If your "query" yield some several hundred non-trivial records, you quickly accumulate megabytes of data. On load test where several clients hammer one application server which such queries (even with the same query -> remember DB caching!)you quickly run into bandwidth problems. This will be avoided in the future by zipping the payload but isn't available yet on WAS as far as I know.

btw,there is nothing wrong with Jco. If you have a clear integration only task (connecting two distinct systems in a customer specific implementation) you always have to choose which interfacing technology performs best in that situation.

Only when you want to provide some service to a potentially unknown number of consumers (different consuming applications that is), i.e. if you want to provide a service as an SOA artefact, you should consider webservices (if webservices is the means your SOA is based on). so, imho, even in a sustainable SOA there will always be use cases for "traditional integration only".

my 2 cents,

anton

[Former Member]

Hi Anton,

Thanks for your detailed explanation.

I've executed the webservices followed by Jco. Please find the results below .

My webservice very simple one which takes 5 parameters (simple type ) and returns a simple structure.It just returning 2 records.

webservice

CPU time DB time

1620 1308

1530 647

1750 947

JCo

650 235

650 472

700 539

As you mentioned , System load and tuning could also influence the CPU timings..right ?

How can we tune the system for better results ? Could please share some links on this.

How can I findout network bandwidths ?

Thanks & Regards,Anilkumar

[Former Member]

I wish I could by web service like cake or IC chips from the shop. Seems like people think web service is some kind of solution for all technology problems.

Following are the dialog content of web service DRAMA in broadway, if you though about some these concepts before using web service for your IT enablement requirement you could have saved a lot of hardware, software, licesing, cheap laboured technology work, late night production support etc.

A Web service is a HTTP operation with a SOAP binding. By default, a web service has to go through a number of marshalling and de-marshalling operations. It is important to develop a web service tuning practice with the help of the service infrastructure so that the deployed service will provide the expected response. Following below is a list of items to be considered when a service tuning guide is prepared:

1. Take the frequency of the messaging into account. Replicate web service data as necessary across the cluster to avoid repeated RPC calls across the network.

2. For aggregation services such as catalog search, try to retrieve data during off-hours in large, course-grained transactions.

3. Repeated SOAP-client calls to access back-end server state can choke a network and degrade the server performance. Cache data on the client whenever possible to avoid requests to the server. Ensure that client data remains up-to-date by using a call to a server service which blocks until data is changed. A user interaction with the back-end system can be segregated through the nature of an user’s actions. As an example, a browse operation can use cached data, but an edit operation can trigger a cache update and then return the same data from the local cache.

4. Quality of service requirements for web services are measured based on:

a. Availability (is it running)

b. Accessibility (can we run it now);

c. Integrity/reliability (will it crash while I run/how often)

d. Throughput (how many simultaneous requests can we run)

e. Latency (response time)

f. Regulatory (conformance to standards)

g. Security (confidentiality, authentication).

5. HTTP is the basic protocol behind SOAP-based service implementation. HTTP is a best-effort delivery service. This means any SOAP-based web service request could simply be dropped due to an HTTP related error. HTTP is not providing a reliable transaction around the request and response calls and associated application component execution. Web services implementations have to handle these concerns. W3 has defined the specification such as web service reliable messaging, web service call back implementation in ASYNC mode of services, and web service addressing to address these concerns.

6. Web service quality is measured in terms of service throughput and latency. Web service latencies are measured in the tens-to-thousands of milliseconds. Asynchronous messaging based web services can improve throughput at the cost of latency.

7. SOAP overheads include extracting the SOAP envelope and parsing the contained XML information. XML data cannot be optimized to a large extent. SOAP requires typing information in every SOAP message. Binary data gets expanded (by an average of 5-fold) when included in XML and also requires encoding/decoding. Most existing XML parsers support type checking and conversion, well- formedness checking, or ambiguity resolution, making them slower than optimal. Consider using a stripped down XML parser which only performs essential parsing.

8. Place attention on the underlining parser. Some parsers are not good for all business services due to the fact that each parser take different approaches to XML parsing. DOM based parsers are slower than SAX based ones. It is recommended to compress the XML when the CPU overhead required for compression is less than the network latency.

9. Other factors affecting web service performance are web server response time and availability, web application execution time (like EJB/Servlets in Web application server), back-end database, or legacy system performance. Request results should be cached where possible. Requests should be load balanced and prioritized according to the business value.

10. Carry out capacity planning to enable the performance to be maintained in the future.

11. Extreme care should be taken to make sure that resources are not locked for long periods of time and avoid serious scalability problems.

12. Measure the performance of web services by adding code measuring elapsed time to the generated service proxy (and recompiling). Open source web service testing framework such as push-to-test will provide a very optimistic web service testing framework to test the web service in an SOA based solution for accuracy such as stateful testing, privilege testing, speed testing, boundary timing testing, and regression testing

13. Cache the web services description language (WSDL) in a centralized database and periodically check for newer versions. Web service registry products use these caching features.

14. Cache schema definitions for scalability.

15. Use simple SOAP data types (String, Int, Float) as much as possible. Each new data type introduces a serializer to convert from the XML value into a Java value and back again, which may cause performance problems. SOAP messages move much more data than the average HTTP GET or POST call, adversely impacting network performance. A XML processing framework such as XML bean have extensive factory classes for each node of an XSD document. When reading a XML document based on numbers of xml elements inside the message, XML parsers create a chain of JAVA objects and factory classes. Each of these factory classes has setter and getter methods based on JAVA primitive types. Processing a SOAP message with elements and attributes from multiple schemas will have higher over head compared to simple data types during the parsing operation.

16. Use faster hardware. As most application performance does not scale linearly with increases in hardware processing speed, there is a limit to single server scalability. Use more than one server in a cluster that services requests as if it were a single server using software load balancing (using a load balancing front-end dispatcher)

17. Use faster communication protocols (plain sockets)

18. Support asynchronous request processing & message based interactions.

19. Generating XML produces a large amount of data during communications but this does not mean that the communication will be the bottleneck.

20. Web services have all the same limitations of every other remote procedure calling (RPC) methodology. Requiring synchronous communications across a WAN is a heavy overhead regardless of the protocol.

21. If "Web services" tend to be chatty with many round trips and a subtle state-fullness between individual communications, the response will be slow. This is a function of failing to realize that the API call model isn't well-suited to building communicating applications where caller and callee are separated by a medium (networks) with variable and unconstrained performance characteristics/latency. Asynchronous messaging may be required for efficient web services. Asynchronous messaging is the concept applied inside a service invocation where an intermediate system with a custom implementation inside the ESB framework controls the flow of message between different service implementation components so that there is no tight coupling between service invocation and service execution.

[Former Member]

Hi Shaji,

Thanks for you detailed explanation.

I am more intrested in looking to the caching part. Lets take an expample where my webservice call taking parameter link ProductID and poromotionID as input and returns the product price after discount for that particular promotionID.

If the user is making a same call for the productID and promotionID then we can cache the data and we can avoid maing a webservice call again for the same data .Does it make sense ??

If so how can we implement this ??

Thaks again

Anil

[Former Member]

Sorry about not responding quickly,

First we have to make sure that the service operation is kind of read only or it is dealing with a data object from the back end system where it is not frequently changing.

For example, I have a web service operation which is providing a lit of product details based on a product ID search from a product catalog located in a remote ERP system. In such case, we do not have to implement the web service in a service enabled platform such as NW with continues query back to the ERP system. We can get to the conclusion about the nature of operation and relevant data during the service analysis such as

Catalog information can change in every 3 hours, catalog info is big in size.

In such case we make an optimized design decision in such a way that our web service is not making continued query to the back end system for every look up made from a single user session.

For an active session or a pre-defined time frame below the catalog change time of the back end system, we can define a cache for a catalog search inside the middleware. so that repeated search for the same combination of product ID will not go and chock the ERP system.

Also we have to make sure that cache entries are not consuming the middleware heap size without any reason, so an optimized configuration of cached data at middleware level can improve the over all performance a lot.

In case if your web service middleware system is JAVA based such as NW there are 100s of JAVA based optimized open source cache mechanism available today. You can choose a right one suitable for ur requirement and improve the performance .

Thanks