Nathan
If you are experiencing performance issues have you explored the types of
server side data caching offered by the IBMi?
Are there any?
Maurice O'Prey
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.htm
l
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.
midrange.com
