× 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.



Tim

if your CLOB is 256K that must then be a teoretical max. The XML file
I generated in 1 sec was 400K and 10.000 elements.

An 10.000 element XML document takes time to process also in the
browser and JSON would then be a better soloution but it may not
be an option.

What I try to tell you that even a 2.500 element XML document is huge
if sendt to be processed in a browser - and 2.500 elements shouldn't
take more than 0.3 seconds to be generated.

I have made a little SQLRPGLE program that reads a file, here you
can se the responce and the generation time I have placed in the
buttom of the XML file:

http://5.103.128.110:6380/pextcgidmo/testxmltim.pgm




On Thu, Oct 3, 2013 at 5:04 PM, Tim Wright <
Tim.Wright@xxxxxxxxxxxxxxxxxxxxxx> wrote:

The CLOB is at about 256K. The content of the XML varies tremendously
because of the nature of the data. These are warranty claims. There's
always a header, but there can be multiple complaints on a claim. There
can be multiple parts on a complaint. There can be multiple failure codes
on a part, etc.

The >1 second report is coming from the browser user/tester. They click a
button to retrieve the claim info, and it takes about 1.2 seconds to come
back for a somewhat complex claim. If they do the exact same thing, but
with a direct SQL select on their side, the turnaround is about 0.1 or 0.2
seconds. But - I frown heavily on direct SQL hits to my i database because
it means that I have business logic in more than one place and the risk of
making something break whenever I introduce a change is high. So - I am
pushing for a service layer. I am being forced to switch from XML to a
stored procedure that returns multiple data sets if I cannot get this time
down. (Of course - there's no guarantee yet that we can get back to the
0.1 or 0.2 second level even by doing that.)





From: Henrik Rützou <hr@xxxxxxxxxxxx>
To: "RPG programming on the IBM i (AS/400 and iSeries)"
<rpg400-l@xxxxxxxxxxxx>,
Date: 10/03/2013 10:28 AM
Subject: Re: Pushing XML out to a browser request
Sent by: rpg400-l-bounces@xxxxxxxxxxxx



Sorry to say it but XML special characters has to be encoded so
raw field/string concat is the worst way to try to make stable XML.

If you have CDATA sections it is probably caused by problems with
these special characters.

I asked and i ask again - how big is the XML you are generating
without that knowledge it is impossible to judge if one second
generation time is okay!




On Thu, Oct 3, 2013 at 3:28 PM, Tim Wright <
Tim.Wright@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Lots of great suggestions coming in. Many thanks!
We are definitely going to go with a varying-length variable and a
reduction of the %trim occurrences.
Also looking into some of the other suggestions.

I will try to post back with any results we get so that everyone can
benefit from any gains we make.





From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
To: "RPG programming on the IBM i (AS/400 and iSeries)"
<rpg400-l@xxxxxxxxxxxx>,
Date: 10/03/2013 09:18 AM
Subject: Re: Pushing XML out to a browser request
Sent by: rpg400-l-bounces@xxxxxxxxxxxx



+1 on this - I remember working on a program that built HTML with lots
of lines like this -

htmlfixed = %trim(htmlfixed) + 'another long ugly string of HTML over
lots of lines in RPG code';

htmlfixed was, obviously, a fixed-length variable.

When I did this with a varying-length variable, the web page noticeable
snapped.

htmlvarying = htmlvarying + 'the same ugly long string - anyone up for
CGIDEV2?';

And htmlfixed was probaby 32K - there are probably ways to optimize
%trim, but conceptually, don't you have to scan from the end back to the
first non-blank? For every time you append some data? Varying-length
variables tell you where that end is - ba-da-bing easy!

Vern

On 10/2/2013 5:13 PM, John Yeung wrote:
On Wed, Oct 2, 2013 at 4:47 PM, Briggs, Trevor (TBriggs2)
<TBriggs2@xxxxxxxxxxx> wrote:
Are you doing the:

@Xml = %Trim(@Xml) + ...

multiple times on each build?
I'll bet this is a major (if not the major) factor slowing him down.
About a year ago, there was a thread on this list titled "XML
performance issue" (starts with
http://archive.midrange.com/rpg400-l/201209/msg00135.html). It came
up during that thread that lots of trimming and joining of large,
nonvarying strings is a big performance hit. If @Xml is a
fixed-length string destined to become a CLOB, it sounds like that's
one likely place to get speed improvements.

John

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



**************************
This e-mail message may contain confidential or privileged information.
If
you are not the intended recipient, please delete the message and any
attachments and notify the sender by return e-mail. You should not
retain,
distribute, disclose or use any of the information in this message.
**************************

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



**************************
This e-mail message may contain confidential or privileged information. If
you are not the intended recipient, please delete the message and any
attachments and notify the sender by return e-mail. You should not retain,
distribute, disclose or use any of the information in this message.
**************************

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.






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.