eddie
Active Member
Has anyone seen performance issues with placing the Java serialized objects in DB2 on an AS400 ENT instead of hosting them on the same physical JAS server in SQL Server or Oracle?
wainwrr
Well Known Member
We're running 3 JAS servers so the serialized objects live in the main ORACLE database om its own server with all the otehr JDE objects (and the Webspere config). I guess putting a database on each server might boost things but we'd have to get 3 more ORACLE licenses and ensure the objects were in step (although it might provide an interesting test scenario we don't currently have)
It's only lightly loaded with users at present but teh time to get serialised objects seems good (and that's with caching off as we're doing a bunch of development we want to propogate quickly). Where we see delays is in building forms with big multi line grids and I suspect that's got a lot more to do with inefficient or missing indexes.
It's only lightly loaded with users at present but teh time to get serialised objects seems good (and that's with caching off as we're doing a bunch of development we want to propogate quickly). Where we see delays is in building forms with big multi line grids and I suspect that's got a lot more to do with inefficient or missing indexes.
rjjump
Active Member
Hi Kent,
Initially when we first started testing with Xe early releases, the
workload due to JSO, (Java serialized objects), access was pretty high.
I'm not sure if our test environment was set up correctly or if it was
something in the code, but it didn't appear that caching was working very
well. Subsequent testing was much better and we saw that, once the objects
are cached, the resource utilization due to JSO access is minimal.
I'm pretty sure the JSOs are still cached upon first access per JVM, (java
virtual machine), after that a time stamp or something like that is
compared to determine if the cached copy needs to be refreshed. So the
first time an application is accessed, the reponse will be slower. If the
JSOs are stored remotely from the JAS server, the access is probably a
little slower than if it is local, but the big performance hit is the fact
that it isn't in cache, not necessarily that it is remote or local. So, if
people are working in the same applications a lot, chances are the objects
they are using are in cache and it doesn't really matter where the JSOs are
stored, other than the very first access. If they are jumping around from
application to application, or you need good response on the first access,
then storing the objects locally on the JAS server would probably provide
the best performance, although I'm not really sure how much better it would
be than storing remotely.
Our standard recommendation is to keep the JSOs with the rest of the
database, no matter where the JAS server functions are being run. This
avoids having separate database licesnse, and separate admin, and I don't
think the initial performance hit is enough to warrant the extra database.
Best regards,
Rob
Rob Jump
Sizing Specialist
IBM/J.D. Edwards International Competency Center
303-334-1054
[email protected]
www.ibm-jdedwards.com
kent_maguire <[email protected]>@jdelist.com on 04/24/2002
05:05:29 PM
Initially when we first started testing with Xe early releases, the
workload due to JSO, (Java serialized objects), access was pretty high.
I'm not sure if our test environment was set up correctly or if it was
something in the code, but it didn't appear that caching was working very
well. Subsequent testing was much better and we saw that, once the objects
are cached, the resource utilization due to JSO access is minimal.
I'm pretty sure the JSOs are still cached upon first access per JVM, (java
virtual machine), after that a time stamp or something like that is
compared to determine if the cached copy needs to be refreshed. So the
first time an application is accessed, the reponse will be slower. If the
JSOs are stored remotely from the JAS server, the access is probably a
little slower than if it is local, but the big performance hit is the fact
that it isn't in cache, not necessarily that it is remote or local. So, if
people are working in the same applications a lot, chances are the objects
they are using are in cache and it doesn't really matter where the JSOs are
stored, other than the very first access. If they are jumping around from
application to application, or you need good response on the first access,
then storing the objects locally on the JAS server would probably provide
the best performance, although I'm not really sure how much better it would
be than storing remotely.
Our standard recommendation is to keep the JSOs with the rest of the
database, no matter where the JAS server functions are being run. This
avoids having separate database licesnse, and separate admin, and I don't
think the initial performance hit is enough to warrant the extra database.
Best regards,
Rob
Rob Jump
Sizing Specialist
IBM/J.D. Edwards International Competency Center
303-334-1054
[email protected]
www.ibm-jdedwards.com
kent_maguire <[email protected]>@jdelist.com on 04/24/2002
05:05:29 PM
