[uai-user-group] Webviewer response time

Google n'est ni affiliÈ aux auteurs de cette page ni responsable de son contenu.

John,

There are a few application side settings which could improve your
WebViewer response time.

The Uniface Oracle driver has several options to increase the buffer size
in order to retrieve larger chunks of data from your Database. These are
set in the r25_www.asn file in the DRIVER SETTINGS section on the line
USYS$ORA_PARAMS. The file probably already contains an option for "open
cursors". Excerpts from the Uniface documentation describing Oracle driver
parameters are shown below. Feel free to experiment with different settings
for WV/ASV.

4.6.2 Stepped hitlist
The default step size is dependent on the operating system; it is 10 on
most operating systems, but the number may be different (not
necessarily smaller) on platforms with memory limitations.
When UNIFACE is building the stepped hitlist, it uses ORACLE array
fetching to reduce the client/server communication overhead. This does,
however, mean extra memory usage by the driver.
If you want to ensure that the step size is a specific fixed value, do not
depend on the default value. Instead, use one of the following driver
options:
    array fetch size
    fixed array size
    step size

array fetch size
This option specifies the minimum number of records UNIFACE fetches
with one call to the ORACLE server using array fetching. The number
specified must be in the range of 1 through 32,767.
This option indirectly specifies the amount of memory which is
dynamically allocated by the ORA driver. The driver allocates an
I/O buffer of approximately 15 kilobytes multiplied by the array size plus
one. When you are using SQL*Net, memory is allocated on the client
platform. When PolyServer is used, memory allocation occurs on the
PolyServer platform. The I/O buffer is allocated when first needed, and
the memory is released when the number of logon paths to ORACLE
drops to zero.
The specified array size is subject to platform-specific memory
limitations. When the amount of memory required to fetch an array of
the specified size cannot be allocated, the following errors can occur:
ORACLE Driver Error[-54]: Storage required for I/O buffer exceeds system
limits.
Reduce array size.
and:
ORACLE Driver Error[-4]: Dynamic memory allocation failed.
If you encounter driver error -54, reducing the array size solves the
problem. If driver error -4 occurs, both reducing the array size and
increasing available memory can solve the problem (for example,
increase the storage available for paging and swapping with virtual
memory operating systems).

fixed array size
By default, UNIFACE and the ORA U3.x driver make optimal use of the
memory that is allocated for ORACLE array fetching. The size of the
allocated memory is calculated based on the size of the largest possible
record. When smaller records are fetched, the array fetch size is
automatically increased to reduce the client/server communication
overhead as much as possible. The step size of the UNIFACE stepped
hitlist must be a multiple of the array fetch size which has been computed
in this way. The step size may, therefore, be very large. Because the array
size depends on the size of the record, the step size may vary for
different
tables.
If you want to avoid having large and varying step sizes, you can set the
fixed array size option. The fixed array size option forces
UNIFACE to use exactly the array size specified with the
array fetch size option (or its default value), instead of dynamically
computing the maximum array size.

step size
This option specifies the step size of the UNIFACE stepped hitlist
mechanism. The number specified must be in the range from 0 through
32,767. If you specify 0, the stepped hitlist mechanism is disabled,
causing UNIFACE to internally finish the hitlist each time, before
returning control to the application.
The actual step size used is always either zero or a multiple of the actual
array fetch size. When necessary, UNIFACE uses the smallest step size
greater than or equal to the specified step size which is a multiple of the
array size. To avoid confusion, specify a step size which is either zero or
a multiple of the specified array size.
When the fixed array size option is set, and the recommended step
size is a multiple of the array fetch size, the array fetch size option
only affects the performance of the application, and not the behavior. The
step size option, on the other hand, determines how many records are
processed before control returns to the application. This affects, for
example, the behavior of the $currhits variable.

Example:
USYS$ORA_PARAMS = array fetch size 5, step size 10, fixed array size

If you use the assignment in this example, UNIFACE receives five
records at a time from the ORACLE server, and internally processes the
records in steps of 10 (two arrays of five records are fetched per step of
the hitlist). This is backwards compatible with older versions of the ORA
driver, which used a fixed step of 10. The performance is better because
array fetching is used.

In my environment I have the following parameters set for the Uniface
Oracle driver:

USYS$ORA_PARAMS=open cursors 300, disable checks, step size 0, array fetch
size 32000, fixed array size

This will result in the driver returning maximum results in a single
operation from it's query to the Oracle database.

*****

An additional setting in the r25_www.asn file is the permanent server
option (see below).

; MultiRequest - only set to true (=1) for permament servers
     MultiRequest=1
; Number of minutes to wait to reexecute a query
     QueryExecInterval=0
; No of seconds to expire WV content
     ExpireContent=600

A permanent server means that an ASV will not stop and close down after
fulfilling one request. It runs permanently and so can answer requests
quicker because there is no startup overhead. (Note you must set
MIN/MAXSESSIONS in the wv2.urd file as well, see example below).

WV2.urd
**********

UV7=C:\Inetpub\wwwroot\WV2\bin\urduv7.dll
MIDDLEWARE=UV7:tellurium|r25test|r25test|WV2
MAXSESSIONS=5
MINSESSIONS=2
SESSIONWAIT=30
POLLINGTIME=10
MAXAPPIDLETIME=6000
MAXSESIDLETIME=3000
SERVERVARIABLES=HTTP_COOKIE,HTTP_USER_AGENT,HTTP_HOST,URL,PATH_TRANSLATED,PATH_INFO

 A permanent ASV server also maintains a cache of previously computed
results and so if it receives a request for exactly the same information it
can pull the results from its cache without all the database access.
Turnaround time will then be of the order of 1/1000 second. The
ExpireContent setting controls how long results are kept in the cache. The
default here is 10 minutes. If you can stand more "stale" output then
increase this value.

WV also sees how frequently it should reexecute a search
(QueryExecInterval). A value of 0 means always rerun the query. Changing it
to something like 60 means that the search is only run at most once an
hour. If the results don't change frequently then there is no point in
constantly rerunning the search on every request. Setting the
QueryExecInterval to some arbitrarily large value effectively disables
dynamic execution of the search in the WV environment and hence will just
return the last result set, which was probably generated through R25. Also
note that search execution is single threaded (through R25 application
level locks). So if a second request comes into a WV ASV process at the
same time as another ASV process is in the middle of computing the search,
then the second request will wait until the first has finished. A process
that has to wait for a search to run does not immediately reexecute the
search, it uses the same results set that were just generated. Let us know
if these suggestions helped improve your WebViewer's response times.

Thanks.

Emil Izunagbara
CollegeNET, Inc.
503-973-5231

                    jshackelford@notes.cc.sun                                                                                  
                    ysb.edu                          To:     uai-user-group@collegenet.com                                     
                    Sent by:                         cc:     (bcc: Archive/UAI)                                                
                    uai-user-group-admin@coll        Subject:     [uai-user-group] Webviewer response time                     
                    egenet.com                                                                                                 

                    04/09/2001 09:37 AM                                                                                        

We've been trying to improve our Webviewer response time, and currently
have the following
at peak times:
Event by date : All Events
1 day view : displays in 4 seconds
Week view: Displays in 15 seconds
Month view: Displays in 60 seconds

The week and month views are the problem.
We are running the Webviewer on a twin PIII 733 box with half a gig of RAM,
a 100 Mbps connection, and our back end is an Oracle 8.i Spark Server.
Machines used to time views were at various offices across campus.
We use parallel databases, the one feeding Webviewer is updated hourly.
It serves no other function other than to feed Webviewer.
Is everyone hitting performance walls?
Can anyone suggest way to improve performance?
I've talked to others who have suggested looking at the ASV.
Anyone with two cent to throw in, please toss away.

John Shackelford
Programmer/Analyst
SUNY Stony Brook, NY
Phone: (631) 632 - 8636
FAX:     (631) 632 - 6936

_______________________________________________
uai-user-group mailing list
uai-user-group@collegenet.com
http://mailinglists.collegenet.com/mailman/listinfo/uai-user-group