Re: XMLSERVICE with .Net -- WEB400

Nathan,

we are and we are not on the same page, TCP connections are at a low level
and dosn't take up many resources,
fomatting data in a itermediated format may do so - I do belive that you
have to look at the whole package and
consider all parameters.

On Fri, Aug 3, 2012 at 7:40 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Henrik,

It sounds like you and I are pretty much on the same page. IBM i server /
database performance is not the issue, regardless of whether you go with
CGI or QZDASOINIT interfaces. The performance hit is on the client, in
consuming the result set. Whether an SQL result set is generated from a CGI
program, or from a QZDASOINIT job, the performance will be essentially
identical.

I don't have any numbers comparing client performance for "consuming" an
XML response vs. an ODBC formatted response. Maybe Richard can try that?

The IBM i Access ODBC Driver for Windows does come with a "compress"
option, on the Performance tab, comparable to the Apache Deflate
module. And it does work, I've monitored the compression.

When comparing CGI to QZDASOINIT interfaces, one other thing you might
want to check is the number of TCP connections and JOB activation are
occurring under the covers. For example the following Foxpro script will
create 12 TCP connections, and activate 6 QZDASOINIT Jobs on my server:

select 0
use mdef100p
select 1
use mdef110p
select 2
use mdef120p
select 3
use mdef130p
select 4
use mdef140p
select 5
use mdef150p

Same thing happens if I use the IBM i Access Navigator to view the tables.
12 TCP connections. 6 QZDASOINIT Job activations (one for each table
browser).

Contrast that with a CGI interface, where most browsers only create 1-2
TCP connections, and perhaps 1-2 CGI Job activations.

-Nathan

----- Original Message -----
From: Henrik Rützou <hr@xxxxxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Cc:
Sent: Friday, August 3, 2012 7:40 AM
Subject: Re: [WEB400] 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.
--
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.