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



I think we actually just found the problem - 

We rearranged the where clause - and created new indexes to match.  One
of the fields is a reference number for customer accounts - which is
much more likely to be unique that the ranges we were searching on first
before. 

 I still don't understand the reason why it made such a huge difference
when running on the web compared to the 400  - but running it from the
web we needed to have it ordered so that the criteria in the where
clause were progressively LESS unique.  Does that make sense?  We put
the reference # first (field3 and field4), then got everything field11 >
.01 and THEN searched for the ranges of group#'s (field6).  

This massively increased our performance to where it's running in under
7 seconds from the web now. 


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Corissa Andrascik
Sent: Wednesday, April 19, 2006 1:17 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Slow Query Performance from the Web

The query is as follows

select field1, field2, field3, field4, field5, field6,  field7, field8,
field9, field10, field11 from View1 where ((field6 >= 0000 and field6 <
0100) or
(field6 >= 8300 and field6 < 8400)) and
(field3=999999999 or field4=999999999)
and field11>=0.01 


I'm not worried so much about the result set per se. The view in our
test database is over 4 physical files totaling about 3.7 million
records.  The result set is very small.  Usually less than 5 records -
never more than 30.   From our web logs I can see where the query is
created and sent to the 400 - and when it returns results.  This is
where we see the lag in time - about 1 minute 10 seconds. 

When we get to production the view will be over 22 million records but
will still have approximately the same amount of results. 


Thanks for all of your help!

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Tom Huff
Sent: Wednesday, April 19, 2006 9:05 AM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] Slow Query Performance from the Web

Long Live Green Screen

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Walden H. Leverich
Sent: Wednesday, April 19, 2006 7:36 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Slow Query Performance from the Web

Can you post the SQL and the number of rows returned in the result set?
Also, have you run SQL Performance Monitors on the job?

One mistake I've seen lots of people make in Java is not to pre-size a
collection when loading records into a collection. In one case simply
adding an ensurecapacity(500) method call to an ArrayList changed
response time from 20 seconds to sub-second.

The more memory constrained the app server the more a problem like this
will be noticed.

-Walden

--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


-----Original Message-----
From: web400-bounces+waldenl=techsoftinc.com@xxxxxxxxxxxx
[mailto:web400-bounces+waldenl=techsoftinc.com@xxxxxxxxxxxx] On Behalf
Of Corissa Andrascik
Sent: Tuesday, April 18, 2006 6:23 PM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] Slow Query Performance from the Web

Hi All, 
 
 I'm new to this list - and I'm not sure this is the proper place to be
asking this question - but I'd appreciate any direction you can give. 
 
We have a query that runs over a view that joins together several
related physical files. We created indexes for each physical based on
the Where clause in the query and when I run it through STRSQL on the
400 - the performance is good - about 8-9 seconds.   When the same query
is passed from the web - we're running websphere on Window 2003 boxes -
it takes in the neighborhood of 1 minute 10 seconds.  
 
  We are trying to figure out what can be done to optimize it from the
web.  I realize I'm probably not giving enough information here - I just
have no clue where to start!  If any of you have any ideas I'd be
eternally grateful.
 
Thanks
--
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.


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

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



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

Follow-Ups:

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.