Loading ...
Sorry, an error occurred while loading the content.
 

Three Tier & Four Tier

Expand Messages
  • David Kurtz
    My first reaction is that openning a panel/page with 2000 rows is not a good idea. One of the problem with panels that are this large is that the return
    Message 1 of 3 , Jul 1, 2003
      My first reaction is that openning a panel/page with 2000 rows is not a good
      idea.

      One of the problem with panels that are this large is that the return
      message is larger that the shared memory queue size used by Tuxedo and so
      the message is written to disk. You can see the message size in the tuxlog
      by setting 'chtr on' in tmadmin. Frankly, 20 seconds isn't bad for a panel
      with this many rows in 3-tier.

      I assume you mean in the 3-tier windows pstools.exe, and that we are on
      PeopleTools 8.x. Exactly which version of PeopleTools are you running?

      The windows client will connect to the WSL whereas the servlet to the JSL.
      These two listeners are very similar, but it is worth checking the
      parameters.

      The PIA and the windows client will use different tuxedo services that will
      use different pieces of code on the application server. The windows client
      will issue PPrLoad, the PIA will issue ICPanel. However, I agree that it is
      probably not a database problem. The same SQL will be issues by the ICPanel
      and PPrLoad services (if the PeopleTools objects are cached).

      One way to be sure that it isn't the app server is to enable the Tuxedo
      service trace (-r option) in the command line of the PSAPPSRV when it is
      started (see Advance Tuxedo document or Batch Performance Metrics
      presentation on Go-Faster website www.go-faster.co.uk). Then when it takes
      20 minutes to open in the PIA (and you can see that in the webserver access
      log) you can confirm that the application server service still only takes 20
      seconds.

      If the timing in the webserver access log does not match what you are seeing
      on the screen then you ether have a problem with the network or the
      PC/browser itself.

      The difference between the access log timing and the Tuxedo service trace
      timing can be accounted for by
      i) time spent on queues in Tuxedo - the service trace measures time
      executing on server process only
      With huge messages some time will be lost writing the message to disk
      ii) network interconnect between servlet and app server
      Unlikely, but if they are on different boxes test the transmission speed by
      copying a large file back and forth with ftp
      iii) time spent in the JVM
      The most likely candidate. How big is the JVM memory pool (see JVM startup
      command line)? With a page this big it is going to take time for the JVM to
      do its stuff. If the pool is very small it will have to make room for the
      new page. It would be interesting to know how big the Tuxedo message is
      because that will give you an idea of how much memory is needed in the JVM.


      However, it sounds like the REAL PROBLEM here is a DESIGN issue. Loading
      2000 rows into one panel at one time is really not a good idea. There are
      examples in Financials of a panel loading 50 or 100 rows of a voucher or
      journal which could have thousands of lines. Perhaps this would be a better
      approach.


      _________________________
      David Kurtz
      Go-Faster Consultancy Ltd.
      tel: +44 (0)7771 760660
      fax: +44 (0)7092 348865
      mailto:david.kurtz@...
      web: www.go-faster.co.uk
      PeopleSoft DBA Forum: http://groups.yahoo.com/group/psftdba

      ________________________________________________________________________

      Message: 1
      Date: Mon, 30 Jun 2003 08:23:59 -0000
      From: "salu_tj" <salu_j@...>
      Subject: Three Tier & Four Tier

      We have a page that displays 2000 records in three tier that comes up
      in twenty seconds. But in four tier (Web Server) it taks twenty
      minutes.

      I figure that it is not a database problem. If it was a missing index
      or something it would not have come up that quick in three tier. Am I
      right in assuming that?

      Also the three tier and the Web Server point to the same app server
      domain. Since they point to the same domain , I believe they should
      be performing the same. I see the Jolt connection as being the only
      difference. Please correct me if I am wrong.

      I would like any suggestions as to where to start looking. It only
      certain pages that are slow.

      Hope to hear from some of you.

      Thanks
    • David Kurtz
      There are specific answers to specific points below but this is the important bit: Performance in the windows client doesn t count. It is a different code
      Message 2 of 3 , Jul 3, 2003
        There are specific answers to specific points below but this is the
        important bit:

        Performance in the windows client doesn't count. It is a different code
        line, it uses different application server services. It is no longer a
        supported run time environment. In PeopleTools 8.4x there isn't a
        pstools.exe! The return message from the application server for the
        transaction on PIA -v- Windows will be different, and will be a different
        size. The HTML, graphics and javascript are all generated in the
        application server, so the PIA message is much larger.
        Its apples and pairs.



        changetrace(chtr) (-m machinename) (-g groupname) (-i srvid) newspec
        yes - this command enhances the tuxlog output. But don't leave it on for
        any length of time in production - it generates a lot of trace file and
        impacts performance while doing so.

        Heres a PT7.5 example

        192640.GO-FASTER-1!PSAPPSRV.277: TRACE:at: { tpservice({"PprLoad", 0x0,
        0x17f7a30, 214, 0, 0, {942087529, 0, 40}})
        192640.GO-FASTER-1!PSAPPSRV.277: TRACE:at: { tpalloc("CARRAY", "", 8192)
        192640.GO-FASTER-1!PSAPPSRV.277: TRACE:at: } tpalloc = 0x1814bd8
        192640.GO-FASTER-1!PSAPPSRV.277: TRACE:at: { tpreturn(2, 0, 0x1814bd8,
        2312, 0x0)
        192640.GO-FASTER-1!PSAPPSRV.277: TRACE:at: } tpreturn [long jump]
        192640.GO-FASTER-1!PSAPPSRV.277: TRACE:at: } tpservice

        The tuxedo documentation explains the parameters to the tpservice and
        tpreturn calls.
        The example trace above shows that the PprLoad service call message is 214
        bytes, and the return message is 2312 bytes (and it dynamically allocated
        8Kb of working space)

        The queue size is one of the shared memory Unix kernel parameters. These
        are machine wide.

        It is exactly the same on Windows. There is a 'Tuxedo IPC Helper' service
        that provides support for the shared memory system calls that are a part of
        the Unix kernel. The kernel parameters can be adjusted via the Tuxedo Icon
        in the control panel.

        It is very difficult to directly detect that the message is written to disk.
        Disk I/O statistics might show it up. Some will always be written to disk -
        like the results of a query that returns 10Mb. If it is happening a lot you
        sometimes see tx* files in the /tmp directory. This is where the file has
        not been cleared out. I don't know exactly why this happens but it does.

        From the tuxlog you can calculate a distribution of message sizes and so
        pick a queue size that will hold most messages. Then you have to consider
        the possibility of more than one nessage on a queue. For PeopleTools 8.x,
        based on doing this on a number of live systems in the past, I would suggest
        at least 128Kb, and possibly as much as 512Kb depending on how busy.

        Jolt compression should not be used because that will only affect the
        traffic between the webserver and the app server. Generally, if they aren't
        on the same server then there should be a very good link between them. That
        is why the default compression threshold is 1000000. You've said that they
        are coresident - so you don't need jolt compression. I would actually
        suggest setting it to 2,147,483,647. This is both the default and maximum
        value and so no compression is done.

        The Tuxedo service trace can be enabled by adding a -r to the command line
        of the individual server process.
        I suggest editing the ubx for all PS servers. The -e parameter qualifies
        the name of the trace file. This is specified at queue level so the queue
        name has been hard coded in the file and it is written to the LOGS
        directory.

        ...
        CLOPT="{$Trace\TuxedoServiceTrace} -e {LOGDIR}{FS}APPQ.stderr
        {$PSAPPSRV\Spawn Server} -s@..{FS}psappsrv.lst -- -C {CFGFILE} -D {$Domain
        Settings\Domain ID} -S PSAPPSRV"
        ...

        I have added a new paramter Trace\TuxedoServiceTrace to the psapsprv.cfg at
        the bottom of the Trace section

        ...
        ;-------------------------------------------------------------------------
        TuxedoServiceTrace=-r

        [Cache Settings]
        ...

        The result is that in the ubb file you get

        ...
        CLOPT="-r -e D:\ps\hr8\appserv\hr8d\LOGS\APPQ.stderr -p
        1,600:1,1 -s@..\psappsrv.lst -s@..\psqcksrv.lst -sICQuery -sSqlQuery:SqlRequ
        est -- -C psappsrv.cfg -D simple -S PSAPPSRV"
        ...


        The servlet engine is built into Weblogic (as opposed to Apache using
        Jserv). But both still run a separate JVM. Since you have PT8.19 you
        should be running Java 1.3 and so you can increase the JVM beyond 64M - I
        would not recommend this on Java 1.2. 256M is a reasonable size. This
        value is set in the command line of the JVM.

        ...\java -ms64m -mx64m -classpath ...

        So in the above example both the minimum and maximum size limits of the java
        pool is 64M. So the pool is always 64M. This pool is used for working
        storage by the servlets that run in the JVM. This is not the total memory
        overhead of the JVM proceses.

        The are some recommendations in the PeopleSoft Red Paper for On-line
        performance - The version for PT8.4 is better and mostly applicable to 8.1.



        Unfortunately I do not know exactly where in GL is the example that loads
        rows into a page in batches (eg rows 51-100 of 200). There is an example of
        it in journal processes. While it may solve your panel problem it may not
        be efficient from the point of view of the database. But it might be the
        lesser of two evils.


        _________________________
        David Kurtz
        Go-Faster Consultancy Ltd.
        tel: +44 (0)7771 760660
        fax: +44 (0)7092 348865
        mailto:david.kurtz@...
        web: www.go-faster.co.uk
        PeopleSoft DBA Forum: http://groups.yahoo.com/group/psftdba
      Your message has been successfully submitted and would be delivered to recipients shortly.