Re: XMLSERVICE with .Net

Nathan,

I wouldn't worry so much of the size of what is returned and besides that,
ODBC dosn't
DEFLATE/ZIP while HTTP normally does.

But DEFALTE/ZIP creates overhead on both server and client side so what you
gain in
network speed you generally loose in the server/client overhead.

Another thing is the comparison of ODBC and XML format, again XML (or JSON)
creates
overhead on the server, and is the XML encoded etc. etc. and XML/JSON may
create different
overhead in the client.

And again, what client do you use, if it is a browser that has to process
javascript and XML
or JSON and render HTML i can give you an example:

I have an EXT JS page that receives 1300 records with 8 fields in an AJAX
request. On the
server side the time to generates either JSON or XML is aprox. the same
(1.0 sec) and the file
size is approx. 25% larger in XML (232/291KB undeflated, 18.4/20.1KB
deflated).

But when I render the page in different browsers here comes the real
performance hit:

MS IE 25 sec
FF 15 sec
Opera 7 sec
Crome 5 sec

Normally this isn't at big problem, because I use paging and thereby only
transfers 25
records to each page - or if I want real scroll I just tells EXTJS to read
and render 25
records at a time in a technique called infinite scroll where the page
loader always are
a couple of pages ahead of the user.

You can se a demo here:


http://dev.sencha.com/deploy/ext-4.1.0-gpl/examples/grid/infinite-scroll.html

I understand you use winshark, if you have to measure
dns,connecting/send/wait/receive time
in browsers Crome has an exellent build in tool for that.


On Fri, Aug 3, 2012 at 6:01 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

From: Alan Seiden
since XMLCGI communicates via a web server and CGI jobs,
it probably won't be as fast as calling XMLSERVICE with stored
procedures, such as through the ibm_db2 or odbc transports ...

Actually, I've done several comparisons between CGI vs. QZDASOINIT
interfaces and performance is nearly identical with respect to socket
communications, database retrieval, and generating formatted response
streams. ODBC is quite comparable to the HTTP protocol in terms of the
size of request and response headers.

However, using ODBC to return a result set of say 6 fields per record only
adds something like 13 to 24 bytes per record, while an XML response may
add something like 100 to 150 bytes per record.

Getting a connection, querying an IBM i database, and generating a
formatted output stream using both CGI and QZDASOINIT performs great. The
point where you take a big performance hit is on the receiving end, where a
client parses a formatted result stream and maps it to some client object.

For example, when connecting to a QZDASOINIT job and downloading a 2,450
record table from an IBM i database to a Visual Foxpro table, a formatted
result set is returned over a LAN in less than 100 milliseconds. You can
measure that with a tool like Wire Shark. But parsing it, and loading it
into a local Foxpro table takes something like 8 seconds.

Where's the performance hit? It's on the client!

-Nathan.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.