× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.