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.
midrange.com
