|
midrange.com
Etienne,
Having security enabled globally will result in some activity because even
if you have not secured an of the WebSphere resources, a check will have to
be made when a resource is accessed (e.g. servlet invoked) to see if the
resource requires the invoker to be authenticated.
However it sounds more like the SE_TABLE access is worse, and there may be
something that can be done here. The SE_TABLE stores "serious events"
(SE=Serious Event) which are just all the message events. The size of the
table (i.e. number of messages stored) is configurable. I believe in 3.5
the default is 1000 records. This can be set to less from the admin console
by selecting Console->Trace->Event viewer, Preferences tab, and then
modifying the properties. Generally 1000 records is not a bad size (in
3.0.2 it was unlimited and that was a problem - people ended up with
millions of records). You can also change the Serious event interval. The
default is 10 seconds. This means it polls the admin server every 10
seconds by default for new serious events (this means the QEJBADMIN job
will check SE_TABLE for new messages).
I am wondering if you have servlets which are using the log() method to log
information and if that is what is causing the table to be accessed so
often? Or if the WebSphere runtime is generating many messages for some
reason. Usually you can tell this by looking at the standard out and
standard error log files for the application server (for Default Server
these are located in /QIBM/UserData/WebASAdv/default/logs directory). For
the administrative server the output can be seen in the tracefile file
located in the logs directory of the WebSphere instance
(/QIBM/UserData/WebASAdv/default/logs for you).
Frances Stewart
WebSphere Application Server for iSeries 400
IBM Rochester
"Richards, Etienne
(CAP, PTL)" To:
"'java400-l@midrange.com'" <java400-l@midrange.com>
<Etienne.Richards@ cc:
penske.com> Subject: RE: WebSphere and
ejsadmin
Sent by:
java400-l-admin@mi
drange.com
03/21/02 05:32 PM
Please respond to
java400-l
Frances
The database activity seems to be there as long as there are users that are
accessing the web application. I have also made sure that all admin
consoles
are closed but it did not help.
Security is enabled on this system but the specific application server
instance that I am testing against does not have any resources protected
(The system only has global security enabled).
When doing a load test of 25 concurrent users and looking at DBMON I found
that the following query
select * from ejsadmin.SE_TABLE where MSG_ID = ? FOR UPDATE
had a maximum execution time of 33 seconds and an average of 0.091 seconds.
I also found that during that load test that the query was executed 1157
times and that 1153 of those required a full opens.
Is there a way to disabled this?
Do we have something incorrectly configured?
Thanks,
Etienne
-----Original Message-----
From: Frances Stewart [mailto:francess@us.ibm.com]
Sent: Thursday, March 21, 2002 5:59 PM
To: java400-l@midrange.com
Subject: Re: WebSphere and ejsadmin
Is it doing this continuously even after the ready state has been reached
and you are just running stuff in the application server? Do you have an
administrative console connected at all times or only as needed for
administartive tasks? Do you have security enabled or not?
Frances Stewart
WebSphere Application Server for iSeries 400
IBM Rochester
"Richards, Etienne
(CAP, PTL)" To:
"'java400-l@midrange.com'" <java400-l@midrange.com>
<Etienne.Richards@ cc:
penske.com> Subject: WebSphere and
ejsadmin
Sent by:
java400-l-admin@mi
drange.com
03/21/02 03:50 PM
Please respond to
java400-l
All,
When WebSphere 3.5.4 runs on the AS/400 it seems as if it is continuously
querying the ejsadmin library. The list of queries below were all executed
in one second.
Can anybody explain why this is done and if we can reduce these queries by
changing something? Most of the times these take about 10ms to complete but
I have found a few where it would take more than 2 seconds to complete.
update ejsadmin.LOCK_TABLE set VAL = ? where NAME = ?
select * from ejsadmin.REL_INSTANCE_TABLE where REL_ID = ? and SRC_ID = ?
and LINK_NAME = ?
update ejsadmin.LOCK_TABLE set VAL = ? where NAME = ?
update ejsadmin.LOCK_TABLE set VAL = ? where NAME = ?
select * from ejsadmin.APPSECURITY_TABLE where INSTANCE_ID = ?
update ejsadmin.LOCK_TABLE set VAL = ? where NAME = ?
select * from ejsadmin.REL_INSTANCE_TABLE where REL_ID = ? and SRC_ID = ?
and LINK_NAME = ?
update ejsadmin.LOCK_TABLE set VAL = ? where NAME = ?
Thanks,
Etienne
_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.
_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.
_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
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.
