Webservice performance on pages.

marvinqvist

Hi,

I have a c# application working on webservices from NAV. I would like to speed up the connection and came to wounder if the size of a page (amount of fields included) matters.

If for instance I have the following two methods in c# calling a webservice/page calles wsSalesOrder:

private void updateSalesOrder(SalesOrder so)
{
wsSalesOrder.Update(ref so);
}

private SalesOrder GetSalesOrder(string key)
{
return wsSalesOrder.Read(key);
}

If a SalesOrder object on the read contains 10 fields instead of 100 fields will this matter. I would say yes, but is there really any difference? Same for Update, which may be even more "expensive" to run. I have not taken the time to "trim" the fields in my pages, but if this gives me a better performance I will do so.

It is obvious that the a call (sending one parameter) for a codeunit which updates a single value will be much faster then sending the entire page object as in the above mentioned method "update". But I am not sure if the update is faster if the page contains less fields.

Any ideas?

Marijn

I have a PHP application which talks to NAV Webservices. This application and NAV both run locally on my machine. I implemented a caching mechanism on the PHP application side to prevent calls to the webservice which aren't really necessary.

Actually this didn't speed up any ReadMultiple requests. It seems SQL is already doing a good job. The actual transport of data through the webservices seems to be only a very small part of the total time. In other words, reading some (huge 14mb) textfile with serialized record information on the fileserver is as fast as calling NAV webservices. That's surprising isn't it? So my 2 cents are that limiting the amount of fields will improve performance, but only because the application has little to process. I don't think NAV webservices are to be blamed. However, my setup is locally. Things could be different out in the open.

The readMultiple webservice uses a BookmarkKey and Limit parameter to indicate which subset should be retrieved. To me, being new to NAV, this seems pretty odd. I can only move forward or backward through results. But I want to jump straight to page 8 for example. So I want to use an Offset, like give me 10 rows maximum starting from rownumber 80. I don't have a solution yet, which means all my readMultiples requests are a lot slower than they could be. I am looking for a solution. Any comments on this are greatly appreciated.

I will see whether I can do some profing on skinny and fat pages. When I can, I will post the results here.

kine

There will be a difference... some... :-) the WS will not need to transfer the fields (it means smaller XML to send). When updating, only the transfered fields are validated, thus quicker when only few fields... but question is, if the difference will be measurable....

marvinqvist

Kine > That is exactly my point. Is it possible to measure?

Have anyone tried this?

kine

You can try to use e.g. Fiddler to measure the time between reqest and answer.