Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

PB Jaguar Performance Basics?

13 posts in General Discussion (old) Last posting was on 2000-03-29 17:33:03.0Z
Andrew Hart Posted on 2000-03-24 17:48:53.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 24 Mar 2000 11:48:53 -0600
From: Andrew Hart <Andrew_Hart@harcourt.com>
Organization: The Psychological Corporation
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: PB Jaguar Performance Basics?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 84
NNTP-Posting-Host: 167.208.175.68
Message-ID: <347_38DBAA85.58B42791@harcourt.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25740
Article PK: 155789

We have a two-tier PB application which we are about to begin converting
into an N-Tier Jaguar app. In the two tier app, a simple maintenance
datawindow gets about 8 rows from a table and displays it. The results
are almost instantaneous. We wrote a simple component to do the same
thing: it uses a datastore to get the results, then uses GetFullState
to blob it and return it to the client which uses SetFullState to
display it in the datawindow. The result is that there is a delay of a
couple of seconds before the datawindow appears populated on the client.

My boss is somewhat concerned over this and so I'm starting to dive into
some basic performance issues. I don't have much experience profiling
performance on PB, much less in EAS 3.5. I've read all the articles in
this newsgroup I could find related to our scenario and have read the
relevant articles on SDN, but I have a few questions:

Since the PB VM is used to build a trace file and since, as I understand
it, the client PB app will have it's own VM and the components running
on the Jaguar Server will be in different VMs, is it possible to use
these Tracetree objects to profile performance across the client app to
the component running on Jaguar and back? Or, would you need to do
profiling on the components separately? If it it the latter, would it
component have to generate it's own trace file which you would then need
to analyze separately?

Maybe a better question is: what's the best way to go about profiling a
distributed app like this?

What would be some general PB performance guidelines to follow as we
make the transition to n-tier?

In a data maintenance scenario, my understanding of the possible
techniques are:

a.) GetFullState in component, send blob to client. Client uses
SetFullState. Client uses GetFullState and sends blob with changes
back. Component uses SetFullState and updates the database.
Advantages: component can be stateless. Disadvantages: Sending the
full state back and forth, of course.

b.) GetFullState in component, send blob to client. Client uses
SetFullState. After changes, client uses GetChanges and sends back
only the mods to the component. Component uses SetChanges and updates
database. Advantages: reduced network traffic. Disadvantages: Need
Stateful component.

c.) Sending resultsets (which are basically strings, right).
Advantages: Faster. Disadvantages: Would need to deploy
datawindows with client apps and the learning curve involved
since I've yet to do this.

Are there any good techniques to reduce the perceived lag in response
time? One thing I thought about was that perhaps in the initialization
of the client, we might transfer datawindows to the client as a blob
and get set up. Then, from that point on, we switch over to
transferring result sets.

I think that's enough for y'all to get where I'm coming from. The stats
in document, "Sybase EAS 3.0 - PB Windows NT Performance" are
impressive, but don't really mean much to us. Given that we simply want
to write PB clients accessing PB (or Java) components in an N-Tier app,
what should we do? Upgrading server/network hardware isn't much of an
option at this point, as that would take many, many months to wend it's
way through the bureacracy.


Alex Whitney Posted on 2000-03-24 20:59:28.0Z
Newsgroups: sybase.public.easerver
From: "Alex Whitney" <awhitney@dyn-data.com>
Subject: Re: PB Jaguar Performance Basics?
Date: Fri, 24 Mar 2000 14:59:28 -0600
Lines: 94
Organization: Dynamic Data Solutions
X-Newsreader: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
NNTP-Posting-Host: 207.127.151.128
Message-ID: <347_qynVuSdl$GA.298@forums.sybase.com>
References: <347_38DBAA85.58B42791@harcourt.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25726
Article PK: 154334

If I may jump in here as well with a couple of tips.

1. The first time you call a component, it's going to be slow as the
component has to be loaded and then executed. This is PAINFULLY obvious in
doing demo's if you have not 'pre-loaded' the components already. In real
life only the early birds would see this load time. I am assuming that you
are using stateless and pooled components.

2. Use NATIVE database drivers. PB does a lot of chatter using ODBC and to a
lesser extent JDBC drivers when getting a connection from the connection
cache. Doesn't matter if the connection is already cached or not, the PB
side ODBC drivers have interrogate the DB every time you do a connect.

Alex

--
_________________________________________________________

Alex Whitney
CPD Professional
Dynamic Data Solutions, Inc.
Enterprise Application Studio 3.0 Consulting and Training
http://www.dyn-data.com

Andrew Hart wrote in message <38DBAA85.58B42791@harcourt.com>...
>
>We have a two-tier PB application which we are about to begin converting
>into an N-Tier Jaguar app. In the two tier app, a simple maintenance
>datawindow gets about 8 rows from a table and displays it. The results
>are almost instantaneous. We wrote a simple component to do the same
>thing: it uses a datastore to get the results, then uses GetFullState
>to blob it and return it to the client which uses SetFullState to
>display it in the datawindow. The result is that there is a delay of a
>couple of seconds before the datawindow appears populated on the client.
>
>My boss is somewhat concerned over this and so I'm starting to dive into
>some basic performance issues. I don't have much experience profiling
>performance on PB, much less in EAS 3.5. I've read all the articles in
>this newsgroup I could find related to our scenario and have read the
>relevant articles on SDN, but I have a few questions:
>
>Since the PB VM is used to build a trace file and since, as I understand
>it, the client PB app will have it's own VM and the components running
>on the Jaguar Server will be in different VMs, is it possible to use
>these Tracetree objects to profile performance across the client app to
>the component running on Jaguar and back? Or, would you need to do
>profiling on the components separately? If it it the latter, would it
>component have to generate it's own trace file which you would then need
>to analyze separately?
>
>Maybe a better question is: what's the best way to go about profiling a
>distributed app like this?
>
>What would be some general PB performance guidelines to follow as we
>make the transition to n-tier?
>
>In a data maintenance scenario, my understanding of the possible
>techniques are:
>
>a.) GetFullState in component, send blob to client. Client uses
>SetFullState. Client uses GetFullState and sends blob with changes
>back. Component uses SetFullState and updates the database.
>Advantages: component can be stateless. Disadvantages: Sending the
>full state back and forth, of course.
>
>b.) GetFullState in component, send blob to client. Client uses
>SetFullState. After changes, client uses GetChanges and sends back
>only the mods to the component. Component uses SetChanges and updates
>database. Advantages: reduced network traffic. Disadvantages: Need
>Stateful component.
>
>c.) Sending resultsets (which are basically strings, right).
>Advantages: Faster. Disadvantages: Would need to deploy
> datawindows with client apps and the learning curve involved
>since I've yet to do this.
>
>Are there any good techniques to reduce the perceived lag in response
>time? One thing I thought about was that perhaps in the initialization
>of the client, we might transfer datawindows to the client as a blob
>and get set up. Then, from that point on, we switch over to
>transferring result sets.
>
>I think that's enough for y'all to get where I'm coming from. The stats
>in document, "Sybase EAS 3.0 - PB Windows NT Performance" are
>impressive, but don't really mean much to us. Given that we simply want
>to write PB clients accessing PB (or Java) components in an N-Tier app,
>what should we do? Upgrading server/network hardware isn't much of an
>option at this point, as that would take many, many months to wend it's
>way through the bureacracy.
>
>


Jim O'Neil [Sybase] Posted on 2000-03-24 22:35:11.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 24 Mar 2000 17:35:11 -0500
From: "Jim O'Neil [Sybase]" <joneil@sybase.com>
Organization: Sybase, Inc.
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: PB Jaguar Performance Basics?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 134
NNTP-Posting-Host: joneil-nt.sybase.com 204.167.42.111
Message-ID: <347_38DBED9F.BDA52E14@sybase.com>
References: <347_38DBAA85.58B42791@harcourt.com> <347_qynVuSdl$GA.298@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25719
Article PK: 155775


Alex Whitney wrote:

> If I may jump in here as well with a couple of tips.
>
> 1. The first time you call a component, it's going to be slow as the
> component has to be loaded and then executed. This is PAINFULLY obvious in
> doing demo's if you have not 'pre-loaded' the components already. In real
> life only the early birds would see this load time. I am assuming that you
> are using stateless and pooled components.
>
> 2. Use NATIVE database drivers. PB does a lot of chatter using ODBC and to a
> lesser extent JDBC drivers when getting a connection from the connection
> cache. Doesn't matter if the connection is already cached or not, the PB
> side ODBC drivers have interrogate the DB every time you do a connect.
>
> Alex
>
> --
> _________________________________________________________
>
> Alex Whitney
> CPD Professional
> Dynamic Data Solutions, Inc.
> Enterprise Application Studio 3.0 Consulting and Training
> http://www.dyn-data.com
>
> Andrew Hart wrote in message <38DBAA85.58B42791@harcourt.com>...
> >
> >We have a two-tier PB application which we are about to begin converting
> >into an N-Tier Jaguar app. In the two tier app, a simple maintenance
> >datawindow gets about 8 rows from a table and displays it. The results
> >are almost instantaneous. We wrote a simple component to do the same
> >thing: it uses a datastore to get the results, then uses GetFullState
> >to blob it and return it to the client which uses SetFullState to
> >display it in the datawindow. The result is that there is a delay of a
> >couple of seconds before the datawindow appears populated on the client.
> >
> >My boss is somewhat concerned over this and so I'm starting to dive into
> >some basic performance issues. I don't have much experience profiling
> >performance on PB, much less in EAS 3.5. I've read all the articles in
> >this newsgroup I could find related to our scenario and have read the
> >relevant articles on SDN, but I have a few questions:
> >
> >Since the PB VM is used to build a trace file and since, as I understand
> >it, the client PB app will have it's own VM and the components running
> >on the Jaguar Server will be in different VMs, is it possible to use
> >these Tracetree objects to profile performance across the client app to
> >the component running on Jaguar and back? Or, would you need to do
> >profiling on the components separately? If it it the latter, would it
> >component have to generate it's own trace file which you would then need
> >to analyze separately?
> >
> >Maybe a better question is: what's the best way to go about profiling a
> >distributed app like this?
> >
> >What would be some general PB performance guidelines to follow as we
> >make the transition to n-tier?
> >
> >In a data maintenance scenario, my understanding of the possible
> >techniques are:
> >
> >a.) GetFullState in component, send blob to client. Client uses
> >SetFullState. Client uses GetFullState and sends blob with changes
> >back. Component uses SetFullState and updates the database.
> >Advantages: component can be stateless. Disadvantages: Sending the
> >full state back and forth, of course.
> >
> >b.) GetFullState in component, send blob to client. Client uses
> >SetFullState. After changes, client uses GetChanges and sends back
> >only the mods to the component. Component uses SetChanges and updates
> >database. Advantages: reduced network traffic. Disadvantages: Need
> >Stateful component.
> >
> >c.) Sending resultsets (which are basically strings, right).
> >Advantages: Faster. Disadvantages: Would need to deploy
> > datawindows with client apps and the learning curve involved
> >since I've yet to do this.
> >
> >Are there any good techniques to reduce the perceived lag in response
> >time? One thing I thought about was that perhaps in the initialization
> >of the client, we might transfer datawindows to the client as a blob
> >and get set up. Then, from that point on, we switch over to
> >transferring result sets.
> >
> >I think that's enough for y'all to get where I'm coming from. The stats
> >in document, "Sybase EAS 3.0 - PB Windows NT Performance" are
> >impressive, but don't really mean much to us. Given that we simply want
> >to write PB clients accessing PB (or Java) components in an N-Tier app,
> >what should we do? Upgrading server/network hardware isn't much of an
> >option at this point, as that would take many, many months to wend it's
> >way through the bureacracy.
> >
> >

I just wanted to add a brief note on the ODBC chatter - yes there is quite a bit
of it - but we are working on tuning what it there (for instance eliminating
multiple trips to the PBODB INI file) and trying to cache some of the
information more cleverly, so hopefully you will see performance increase -
probably in the PB8 timeframe. Just by eliminating sections of that file that
you aren't using, you'll see a noticeable performance boost. It's unlikely
though that it will approach the speed of native connections, since by nature
the ODBC interface has to be rather generic whereas the native drivers 'know'
what they're targeting.
--
Jim O'Neil
Senior Technical Support Engineer
Sybase, Inc


Alex Whitney Posted on 2000-03-26 15:54:43.0Z
Newsgroups: sybase.public.easerver
From: "Alex Whitney" <awhitney@dyn-data.com>
Subject: Re: PB Jaguar Performance Basics?
Date: Sun, 26 Mar 2000 09:54:43 -0600
Lines: 142
Organization: Dynamic Data Solutions
X-Newsreader: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
NNTP-Posting-Host: 56K-219.LVL3TNT1.pdq.net 216.118.42.219
Message-ID: <347_ODUN0xzl$GA.201@forums.sybase.com>
References: <347_38DBAA85.58B42791@harcourt.com> <347_qynVuSdl$GA.298@forums.sybase.com> <347_38DBED9F.BDA52E14@sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25706
Article PK: 155762

Could you add a bit to your "eliminating sections of that file" statement?
Specifically which sections are you referring to?

Agreement on your usage of ODBC Vs others with one caveat; as I don't
believe there is no 'native' driver for ASA is there? You have to use ODBC
to access this.

Nice to hear that someone is working on tuning the PB ODBC driver.

Alex

--
_________________________________________________________

Alex Whitney
CPD Professional
Dynamic Data Solutions, Inc.
Enterprise Application Studio 3.0 Consulting and Training
http://www.dyn-data.com

Jim O'Neil [Sybase] wrote in message <38DBED9F.BDA52E14@sybase.com>...
>Alex Whitney wrote:
>
>> If I may jump in here as well with a couple of tips.
>>
>> 1. The first time you call a component, it's going to be slow as the
>> component has to be loaded and then executed. This is PAINFULLY obvious
in
>> doing demo's if you have not 'pre-loaded' the components already. In real
>> life only the early birds would see this load time. I am assuming that
you
>> are using stateless and pooled components.
>>
>> 2. Use NATIVE database drivers. PB does a lot of chatter using ODBC and
to a
>> lesser extent JDBC drivers when getting a connection from the connection
>> cache. Doesn't matter if the connection is already cached or not, the PB
>> side ODBC drivers have interrogate the DB every time you do a connect.
>>
>> Alex
>>
>> --
>> _________________________________________________________
>>
>> Alex Whitney
>> CPD Professional
>> Dynamic Data Solutions, Inc.
>> Enterprise Application Studio 3.0 Consulting and Training
>> http://www.dyn-data.com
>>
>> Andrew Hart wrote in message <38DBAA85.58B42791@harcourt.com>...
>> >
>> >We have a two-tier PB application which we are about to begin converting
>> >into an N-Tier Jaguar app. In the two tier app, a simple maintenance
>> >datawindow gets about 8 rows from a table and displays it. The results
>> >are almost instantaneous. We wrote a simple component to do the same
>> >thing: it uses a datastore to get the results, then uses GetFullState
>> >to blob it and return it to the client which uses SetFullState to
>> >display it in the datawindow. The result is that there is a delay of a
>> >couple of seconds before the datawindow appears populated on the client.
>> >
>> >My boss is somewhat concerned over this and so I'm starting to dive into
>> >some basic performance issues. I don't have much experience profiling
>> >performance on PB, much less in EAS 3.5. I've read all the articles in
>> >this newsgroup I could find related to our scenario and have read the
>> >relevant articles on SDN, but I have a few questions:
>> >
>> >Since the PB VM is used to build a trace file and since, as I understand
>> >it, the client PB app will have it's own VM and the components running
>> >on the Jaguar Server will be in different VMs, is it possible to use
>> >these Tracetree objects to profile performance across the client app to
>> >the component running on Jaguar and back? Or, would you need to do
>> >profiling on the components separately? If it it the latter, would it
>> >component have to generate it's own trace file which you would then need
>> >to analyze separately?
>> >
>> >Maybe a better question is: what's the best way to go about profiling a
>> >distributed app like this?
>> >
>> >What would be some general PB performance guidelines to follow as we
>> >make the transition to n-tier?
>> >
>> >In a data maintenance scenario, my understanding of the possible
>> >techniques are:
>> >
>> >a.) GetFullState in component, send blob to client. Client uses
>> >SetFullState. Client uses GetFullState and sends blob with changes
>> >back. Component uses SetFullState and updates the database.
>> >Advantages: component can be stateless. Disadvantages: Sending the
>> >full state back and forth, of course.
>> >
>> >b.) GetFullState in component, send blob to client. Client uses
>> >SetFullState. After changes, client uses GetChanges and sends back
>> >only the mods to the component. Component uses SetChanges and updates
>> >database. Advantages: reduced network traffic. Disadvantages: Need
>> >Stateful component.
>> >
>> >c.) Sending resultsets (which are basically strings, right).
>> >Advantages: Faster. Disadvantages: Would need to deploy
>> > datawindows with client apps and the learning curve involved
>> >since I've yet to do this.
>> >
>> >Are there any good techniques to reduce the perceived lag in response
>> >time? One thing I thought about was that perhaps in the initialization
>> >of the client, we might transfer datawindows to the client as a blob
>> >and get set up. Then, from that point on, we switch over to
>> >transferring result sets.
>> >
>> >I think that's enough for y'all to get where I'm coming from. The stats
>> >in document, "Sybase EAS 3.0 - PB Windows NT Performance" are
>> >impressive, but don't really mean much to us. Given that we simply want
>> >to write PB clients accessing PB (or Java) components in an N-Tier app,
>> >what should we do? Upgrading server/network hardware isn't much of an
>> >option at this point, as that would take many, many months to wend it's
>> >way through the bureacracy.
>> >
>> >
>
>I just wanted to add a brief note on the ODBC chatter - yes there is quite
a bit
>of it - but we are working on tuning what it there (for instance
eliminating
>multiple trips to the PBODB INI file) and trying to cache some of the
>information more cleverly, so hopefully you will see performance increase -
>probably in the PB8 timeframe. Just by eliminating sections of that file
that
>you aren't using, you'll see a noticeable performance boost. It's unlikely
>though that it will approach the speed of native connections, since by
nature
>the ODBC interface has to be rather generic whereas the native drivers
'know'
>what they're targeting.
>--
>Jim O'Neil
>Senior Technical Support Engineer
>Sybase, Inc
>
>


Jim O'Neil [Sybase] Posted on 2000-03-27 14:30:59.0Z
Newsgroups: sybase.public.easerver
Date: Mon, 27 Mar 2000 09:30:59 -0500
From: "Jim O'Neil [Sybase]" <joneil@sybase.com>
Organization: Sybase, Inc.
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: PB Jaguar Performance Basics?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 193
NNTP-Posting-Host: joneil-nt.sybase.com 204.167.42.111
Message-ID: <347_38DF70A3.67B7BF45@sybase.com>
References: <347_38DBAA85.58B42791@harcourt.com> <347_qynVuSdl$GA.298@forums.sybase.com> <347_38DBED9F.BDA52E14@sybase.com> <347_ODUN0xzl$GA.201@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25663
Article PK: 155727

Well, depending on what ODBC driver/drivers you are using, you only need to
include the sections in the PBODB INI that are relevant to that particular
driver. For ASA for instance, you'd want the [Adaptive Server Anywhere]
section, the WATCOM50_SYNTAX, STANDARD_DATETIME, ASA_FUNCTIONS, and the
WATCOM_SPECIALDATATYPES sections. Additionally, much of what's there is really
important at design time versus run-time, so you could probably get rid of a few
more sections depending on the functionality of your components. Since that
file is now around 60+KB, skinnying it down to a couple of K will speed up the
accesses that the PBODB70.DLL makes.

You could use jConnect with ASA, but there is something similar to the PBODB INI
file for JDBC connections from PowerBuilder as well. It's a 'built-in' registry
that can be extended/overriden with NT registry entries, but I *think* that it's
far less overhead than the ODBC INI file. Conceptually, you should be able to
use the ct-lib driver with ASA, since ASA now supports TDS; however, it's
unsupported and I believe you can't really even get connected. Those should not
be insurmountable problems, but would require development time on this end, and
frankly I don't think there's enough demand to warrant it.

Jim

Alex Whitney wrote:

> Could you add a bit to your "eliminating sections of that file" statement?
> Specifically which sections are you referring to?
>
> Agreement on your usage of ODBC Vs others with one caveat; as I don't
> believe there is no 'native' driver for ASA is there? You have to use ODBC
> to access this.
>
> Nice to hear that someone is working on tuning the PB ODBC driver.
>
> Alex
>
> --
> _________________________________________________________
>
> Alex Whitney
> CPD Professional
> Dynamic Data Solutions, Inc.
> Enterprise Application Studio 3.0 Consulting and Training
> http://www.dyn-data.com
>
> Jim O'Neil [Sybase] wrote in message <38DBED9F.BDA52E14@sybase.com>...
> >Alex Whitney wrote:
> >
> >> If I may jump in here as well with a couple of tips.
> >>
> >> 1. The first time you call a component, it's going to be slow as the
> >> component has to be loaded and then executed. This is PAINFULLY obvious
> in
> >> doing demo's if you have not 'pre-loaded' the components already. In real
> >> life only the early birds would see this load time. I am assuming that
> you
> >> are using stateless and pooled components.
> >>
> >> 2. Use NATIVE database drivers. PB does a lot of chatter using ODBC and
> to a
> >> lesser extent JDBC drivers when getting a connection from the connection
> >> cache. Doesn't matter if the connection is already cached or not, the PB
> >> side ODBC drivers have interrogate the DB every time you do a connect.
> >>
> >> Alex
> >>
> >> --
> >> _________________________________________________________
> >>
> >> Alex Whitney
> >> CPD Professional
> >> Dynamic Data Solutions, Inc.
> >> Enterprise Application Studio 3.0 Consulting and Training
> >> http://www.dyn-data.com
> >>
> >> Andrew Hart wrote in message <38DBAA85.58B42791@harcourt.com>...
> >> >
> >> >We have a two-tier PB application which we are about to begin converting
> >> >into an N-Tier Jaguar app. In the two tier app, a simple maintenance
> >> >datawindow gets about 8 rows from a table and displays it. The results
> >> >are almost instantaneous. We wrote a simple component to do the same
> >> >thing: it uses a datastore to get the results, then uses GetFullState
> >> >to blob it and return it to the client which uses SetFullState to
> >> >display it in the datawindow. The result is that there is a delay of a
> >> >couple of seconds before the datawindow appears populated on the client.
> >> >
> >> >My boss is somewhat concerned over this and so I'm starting to dive into
> >> >some basic performance issues. I don't have much experience profiling
> >> >performance on PB, much less in EAS 3.5. I've read all the articles in
> >> >this newsgroup I could find related to our scenario and have read the
> >> >relevant articles on SDN, but I have a few questions:
> >> >
> >> >Since the PB VM is used to build a trace file and since, as I understand
> >> >it, the client PB app will have it's own VM and the components running
> >> >on the Jaguar Server will be in different VMs, is it possible to use
> >> >these Tracetree objects to profile performance across the client app to
> >> >the component running on Jaguar and back? Or, would you need to do
> >> >profiling on the components separately? If it it the latter, would it
> >> >component have to generate it's own trace file which you would then need
> >> >to analyze separately?
> >> >
> >> >Maybe a better question is: what's the best way to go about profiling a
> >> >distributed app like this?
> >> >
> >> >What would be some general PB performance guidelines to follow as we
> >> >make the transition to n-tier?
> >> >
> >> >In a data maintenance scenario, my understanding of the possible
> >> >techniques are:
> >> >
> >> >a.) GetFullState in component, send blob to client. Client uses
> >> >SetFullState. Client uses GetFullState and sends blob with changes
> >> >back. Component uses SetFullState and updates the database.
> >> >Advantages: component can be stateless. Disadvantages: Sending the
> >> >full state back and forth, of course.
> >> >
> >> >b.) GetFullState in component, send blob to client. Client uses
> >> >SetFullState. After changes, client uses GetChanges and sends back
> >> >only the mods to the component. Component uses SetChanges and updates
> >> >database. Advantages: reduced network traffic. Disadvantages: Need
> >> >Stateful component.
> >> >
> >> >c.) Sending resultsets (which are basically strings, right).
> >> >Advantages: Faster. Disadvantages: Would need to deploy
> >> > datawindows with client apps and the learning curve involved
> >> >since I've yet to do this.
> >> >
> >> >Are there any good techniques to reduce the perceived lag in response
> >> >time? One thing I thought about was that perhaps in the initialization
> >> >of the client, we might transfer datawindows to the client as a blob
> >> >and get set up. Then, from that point on, we switch over to
> >> >transferring result sets.
> >> >
> >> >I think that's enough for y'all to get where I'm coming from. The stats
> >> >in document, "Sybase EAS 3.0 - PB Windows NT Performance" are
> >> >impressive, but don't really mean much to us. Given that we simply want
> >> >to write PB clients accessing PB (or Java) components in an N-Tier app,
> >> >what should we do? Upgrading server/network hardware isn't much of an
> >> >option at this point, as that would take many, many months to wend it's
> >> >way through the bureacracy.
> >> >
> >> >
> >
> >I just wanted to add a brief note on the ODBC chatter - yes there is quite
> a bit
> >of it - but we are working on tuning what it there (for instance
> eliminating
> >multiple trips to the PBODB INI file) and trying to cache some of the
> >information more cleverly, so hopefully you will see performance increase -
> >probably in the PB8 timeframe. Just by eliminating sections of that file
> that
> >you aren't using, you'll see a noticeable performance boost. It's unlikely
> >though that it will approach the speed of native connections, since by
> nature
> >the ODBC interface has to be rather generic whereas the native drivers
> 'know'
> >what they're targeting.
> >--
> >Jim O'Neil
> >Senior Technical Support Engineer
> >Sybase, Inc
> >
> >


Bill Green[TeamSybase] Posted on 2000-03-24 21:52:09.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 24 Mar 2000 16:52:09 -0500
From: "Bill Green[TeamSybase]" <bill.green@teamsybase.com>
Reply-To: bill.green@teamsybase.com
Organization: TeamSybase
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: PB Jaguar Performance Basics?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 139
NNTP-Posting-Host: threshold3.jpmorgan.com 169.71.1.12
Message-ID: <347_38DBE388.46EF804B@teamsybase.com>
References: <347_38DBAA85.58B42791@harcourt.com> <347_qynVuSdl$GA.298@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25722
Article PK: 155778

In other words, it can sometimes make sense to write a Service component whose
sole job it is to perform the CreateInstance (or equavilent) of your components.
As the Service component is only launched once, it can very effectively be used
as a loader as well as any other "Service" tasks. It could also effectively be
setup to be pretty expandable by getting the objects to create from a set of
parameters within the server....

Bill

Alex Whitney wrote:

> If I may jump in here as well with a couple of tips.
>
> 1. The first time you call a component, it's going to be slow as the
> component has to be loaded and then executed. This is PAINFULLY obvious in
> doing demo's if you have not 'pre-loaded' the components already. In real
> life only the early birds would see this load time. I am assuming that you
> are using stateless and pooled components.
>
> 2. Use NATIVE database drivers. PB does a lot of chatter using ODBC and to a
> lesser extent JDBC drivers when getting a connection from the connection
> cache. Doesn't matter if the connection is already cached or not, the PB
> side ODBC drivers have interrogate the DB every time you do a connect.
>
> Alex
>
> --
> _________________________________________________________
>
> Alex Whitney
> CPD Professional
> Dynamic Data Solutions, Inc.
> Enterprise Application Studio 3.0 Consulting and Training
> http://www.dyn-data.com
>
> Andrew Hart wrote in message <38DBAA85.58B42791@harcourt.com>...
> >
> >We have a two-tier PB application which we are about to begin converting
> >into an N-Tier Jaguar app. In the two tier app, a simple maintenance
> >datawindow gets about 8 rows from a table and displays it. The results
> >are almost instantaneous. We wrote a simple component to do the same
> >thing: it uses a datastore to get the results, then uses GetFullState
> >to blob it and return it to the client which uses SetFullState to
> >display it in the datawindow. The result is that there is a delay of a
> >couple of seconds before the datawindow appears populated on the client.
> >
> >My boss is somewhat concerned over this and so I'm starting to dive into
> >some basic performance issues. I don't have much experience profiling
> >performance on PB, much less in EAS 3.5. I've read all the articles in
> >this newsgroup I could find related to our scenario and have read the
> >relevant articles on SDN, but I have a few questions:
> >
> >Since the PB VM is used to build a trace file and since, as I understand
> >it, the client PB app will have it's own VM and the components running
> >on the Jaguar Server will be in different VMs, is it possible to use
> >these Tracetree objects to profile performance across the client app to
> >the component running on Jaguar and back? Or, would you need to do
> >profiling on the components separately? If it it the latter, would it
> >component have to generate it's own trace file which you would then need
> >to analyze separately?
> >
> >Maybe a better question is: what's the best way to go about profiling a
> >distributed app like this?
> >
> >What would be some general PB performance guidelines to follow as we
> >make the transition to n-tier?
> >
> >In a data maintenance scenario, my understanding of the possible
> >techniques are:
> >
> >a.) GetFullState in component, send blob to client. Client uses
> >SetFullState. Client uses GetFullState and sends blob with changes
> >back. Component uses SetFullState and updates the database.
> >Advantages: component can be stateless. Disadvantages: Sending the
> >full state back and forth, of course.
> >
> >b.) GetFullState in component, send blob to client. Client uses
> >SetFullState. After changes, client uses GetChanges and sends back
> >only the mods to the component. Component uses SetChanges and updates
> >database. Advantages: reduced network traffic. Disadvantages: Need
> >Stateful component.
> >
> >c.) Sending resultsets (which are basically strings, right).
> >Advantages: Faster. Disadvantages: Would need to deploy
> > datawindows with client apps and the learning curve involved
> >since I've yet to do this.
> >
> >Are there any good techniques to reduce the perceived lag in response
> >time? One thing I thought about was that perhaps in the initialization
> >of the client, we might transfer datawindows to the client as a blob
> >and get set up. Then, from that point on, we switch over to
> >transferring result sets.
> >
> >I think that's enough for y'all to get where I'm coming from. The stats
> >in document, "Sybase EAS 3.0 - PB Windows NT Performance" are
> >impressive, but don't really mean much to us. Given that we simply want
> >to write PB clients accessing PB (or Java) components in an N-Tier app,
> >what should we do? Upgrading server/network hardware isn't much of an
> >option at this point, as that would take many, many months to wend it's
> >way through the bureacracy.
> >
> >

--
Bill Green[TeamSybase]

-----------------------------------------------------------
Good Links to know, good places to go:

Sybase Developer Network (SDN) - http://www.sybase.com/sdn
Find things like:
-- Print to PDF component
-- Lotus Notes E-Mail component
-- Taking existing PB apps to the web white paper

PFC Guide - http://www.pfcguide.com
Power3 - Custom Training - http://www.power3.com
-----------------------------------------------------------


Bill Green[TeamSybase] Posted on 2000-03-24 18:32:01.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 24 Mar 2000 13:32:01 -0500
From: "Bill Green[TeamSybase]" <bill.green@teamsybase.com>
Reply-To: bill.green@teamsybase.com
Organization: TeamSybase
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: PB Jaguar Performance Basics?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 167
NNTP-Posting-Host: threshold3.jpmorgan.com 169.71.1.12
Message-ID: <347_38DBB4A1.5082DBEB@teamsybase.com>
References: <347_38DBAA85.58B42791@harcourt.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25737
Article PK: 155786

Unfortunately, you're falling into a trap that a lot of people fall into
initially. You're comparing a datawindow retrieve with a distributed
retrieve. Just on the face of it, compare the work being done:

Local:
Datawindow.Retrieve() I'm done

Remote:
Create Connection
ConnectToServer
CreateInstance
Database Connect
Datastore Setup
Component.Retrieve
datastore.Retrieve
Get Data (using Getfullstate, generateresultset etc)
Send data back to client
Load data into datawindow (using setfullstate, createfrom etc)


Obviously, the remote version is going to take longer for an individual
retrieve. Going distributed is not about getting equal data-retrieval
performance, but about getting overall more scalability (connection pooling,
instance pooling, load balancing), more reliability (failover, clustering
etc), more capability (access CORBA, Java, EJB, PB, Com components without
caring which is which etc), more Managability (components in one central
location, not hundreds of client sites), more maintainability (single copy
of business logic vs. logic scattered through various and sundry
applications), more Flexibility (access the same components from PB,
Browser, Java etc), and much more.

If you do a compare of executing a function (for example that builds a
string containing the alphabet), and call the function from your local
workstation and from the remote server, you will see that the function
executes in comparable time.

There are things you can do to improve performance from the server to the
client, (like compressing resultsets etc), but you should not consider
performance of an individual aspect of your application a measuring point
for determining the performability (new word I just made up) of distributed
components.

My recommendation to you is to do tests that would be more comparable.
Individual functions, retrievals are ok to get an idea, but you need to
measure much more overall. Basically, if you take a C++ component and deploy
it in any application server, the functions in that component will perform
slower overall than if they ran locally, so you're actually measuring a
given and getting too afraid of potentially meaningless numbers. (For
example, change your retrieve to do a 4-table join returning about 1100 rows
of data - then do your performance measurement again). Try measuring how
long it takes for 20 client workstations to retrieve that data using normal
2-tier, then measure against using n-tier. Try again with 100 users. The
performance benefits come from higher loads, not individual tasks.


Hope this helps,
Bill Green

Andrew Hart wrote:

> We have a two-tier PB application which we are about to begin converting
> into an N-Tier Jaguar app. In the two tier app, a simple maintenance
> datawindow gets about 8 rows from a table and displays it. The results
> are almost instantaneous. We wrote a simple component to do the same
> thing: it uses a datastore to get the results, then uses GetFullState
> to blob it and return it to the client which uses SetFullState to
> display it in the datawindow. The result is that there is a delay of a
> couple of seconds before the datawindow appears populated on the client.
>
> My boss is somewhat concerned over this and so I'm starting to dive into
> some basic performance issues. I don't have much experience profiling
> performance on PB, much less in EAS 3.5. I've read all the articles in
> this newsgroup I could find related to our scenario and have read the
> relevant articles on SDN, but I have a few questions:
>
> Since the PB VM is used to build a trace file and since, as I understand
> it, the client PB app will have it's own VM and the components running
> on the Jaguar Server will be in different VMs, is it possible to use
> these Tracetree objects to profile performance across the client app to
> the component running on Jaguar and back? Or, would you need to do
> profiling on the components separately? If it it the latter, would it
> component have to generate it's own trace file which you would then need
> to analyze separately?
>
> Maybe a better question is: what's the best way to go about profiling a
> distributed app like this?
>
> What would be some general PB performance guidelines to follow as we
> make the transition to n-tier?
>
> In a data maintenance scenario, my understanding of the possible
> techniques are:
>
> a.) GetFullState in component, send blob to client. Client uses
> SetFullState. Client uses GetFullState and sends blob with changes
> back. Component uses SetFullState and updates the database.
> Advantages: component can be stateless. Disadvantages: Sending the
> full state back and forth, of course.
>
> b.) GetFullState in component, send blob to client. Client uses
> SetFullState. After changes, client uses GetChanges and sends back
> only the mods to the component. Component uses SetChanges and updates
> database. Advantages: reduced network traffic. Disadvantages: Need
> Stateful component.
>
> c.) Sending resultsets (which are basically strings, right).
> Advantages: Faster. Disadvantages: Would need to deploy
> datawindows with client apps and the learning curve involved
> since I've yet to do this.
>
> Are there any good techniques to reduce the perceived lag in response
> time? One thing I thought about was that perhaps in the initialization
> of the client, we might transfer datawindows to the client as a blob
> and get set up. Then, from that point on, we switch over to
> transferring result sets.
>
> I think that's enough for y'all to get where I'm coming from. The stats
> in document, "Sybase EAS 3.0 - PB Windows NT Performance" are
> impressive, but don't really mean much to us. Given that we simply want
> to write PB clients accessing PB (or Java) components in an N-Tier app,
> what should we do? Upgrading server/network hardware isn't much of an
> option at this point, as that would take many, many months to wend it's
> way through the bureacracy.

--
Bill Green[TeamSybase]

-----------------------------------------------------------
Good Links to know, good places to go:

Sybase Developer Network (SDN) - http://www.sybase.com/sdn
Find things like:
-- Print to PDF component
-- Lotus Notes E-Mail component
-- Taking existing PB apps to the web white paper

PFC Guide - http://www.pfcguide.com
Power3 - Custom Training - http://www.power3.com
-----------------------------------------------------------


Andrew Hart Posted on 2000-03-24 20:21:12.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 24 Mar 2000 14:21:12 -0600
From: Andrew Hart <Andrew_Hart@harcourt.com>
Organization: The Psychological Corporation
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: PB Jaguar Performance Basics?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 34
NNTP-Posting-Host: 167.208.175.68
Message-ID: <347_38DBCE37.637CA7E6@harcourt.com>
References: <347_38DBAA85.58B42791@harcourt.com> <347_38DBB4A1.5082DBEB@teamsybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25732
Article PK: 155781

Mark, thanks for the tip on using a stateless component with
GetChanges/SetChanges. I'll try that out.

Bill, I understand your points. I think the concern of my boss was that
because we're deploying this 2-tier prototype to a limited set of users while we
undertake the partitioning of the prototype into a final n-tier version, the
final version might be perceived by the users as "slower". I guess the real
question is, is this an application that needs to be distributed in the first
place? I.e., if there's not going to be a need to scale this application up,
will we realize enough benefits from doing it in a distributed manner to
compensate for the increased network traffic and slower response time?

(Hey, I took this job to work with this technology, so I vote yes, but...)

Anyway, you've given me some good information to use as ammo, and I appreciate
it.

As to my original question in a simpler form: Is there a way to profile the
remote execution of PB components? I've never played around with any of those
objects, but intend to this afternoon.

"Bill Green[TeamSybase]" wrote:

> Unfortunately, you're falling into a trap that a lot of people fall into
> initially. You're comparing a datawindow retrieve with a distributed
> retrieve. Just on the face of it, compare the work being done:

[..]


Bill Green[TeamSybase] Posted on 2000-03-24 20:39:16.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 24 Mar 2000 15:39:16 -0500
From: "Bill Green[TeamSybase]" <bill.green@teamsybase.com>
Reply-To: bill.green@teamsybase.com
Organization: TeamSybase
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: PB Jaguar Performance Basics?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 86
NNTP-Posting-Host: threshold3.jpmorgan.com 169.71.1.12
Message-ID: <347_38DBD274.36780419@teamsybase.com>
References: <347_38DBAA85.58B42791@harcourt.com> <347_38DBB4A1.5082DBEB@teamsybase.com> <347_38DBCE37.637CA7E6@harcourt.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25730
Article PK: 154337

Sorry. I never answered your original question. (Meant to, but got sidetracked with
the other gunk).

While turning on profiling from the development environment will do between little
and nothing to help you once running distributed components, you can still get to
some profiler information. There are a bunch of profiling functions to activate, run
and stop profiling from within your code. I have these wrapped into a window that I
use to activate profiling for my client-server applications. I started wrapping
these into a component that I could use anywhere but never finished it. So, the
answer is that you can use profiling yourself, the fact is that you will have to
also write the profiler activation code yourself (unles someone already has this for
a distributable component).

You can also run the profiler on your client application only which will show you
the function call made to the server component and how long it actually takes etc,
but will not profile the remote component as part of the application as a whole.

Also, while I'm thinking about it, I wanted to highlight one point that you made as
a reason for going to distributed development. It's actually a very important one. I
highlight this during our training classes.

"People move to distributed development because it's cool and that's what developers
want to work on".

May sound stupid, but if you want to keep developers, or attract new ones, you have
to be considering this tact.

regards,
Bill

Andrew Hart wrote:

> Mark, thanks for the tip on using a stateless component with
> GetChanges/SetChanges. I'll try that out.
>
> Bill, I understand your points. I think the concern of my boss was that
> because we're deploying this 2-tier prototype to a limited set of users while we
> undertake the partitioning of the prototype into a final n-tier version, the
> final version might be perceived by the users as "slower". I guess the real
> question is, is this an application that needs to be distributed in the first
> place? I.e., if there's not going to be a need to scale this application up,
> will we realize enough benefits from doing it in a distributed manner to
> compensate for the increased network traffic and slower response time?
>
> (Hey, I took this job to work with this technology, so I vote yes, but...)
>
> Anyway, you've given me some good information to use as ammo, and I appreciate
> it.
>
> As to my original question in a simpler form: Is there a way to profile the
> remote execution of PB components? I've never played around with any of those
> objects, but intend to this afternoon.
>
> "Bill Green[TeamSybase]" wrote:
>
> > Unfortunately, you're falling into a trap that a lot of people fall into
> > initially. You're comparing a datawindow retrieve with a distributed
> > retrieve. Just on the face of it, compare the work being done:
>
> [..]

--
Bill Green[TeamSybase]

-----------------------------------------------------------
Good Links to know, good places to go:

Sybase Developer Network (SDN) - http://www.sybase.com/sdn
Find things like:
-- Print to PDF component
-- Lotus Notes E-Mail component
-- Taking existing PB apps to the web white paper

PFC Guide - http://www.pfcguide.com
Power3 - Custom Training - http://www.power3.com
-----------------------------------------------------------


Andrew Hart Posted on 2000-03-24 22:33:55.0Z
Newsgroups: sybase.public.easerver
Date: Fri, 24 Mar 2000 16:33:55 -0600
From: Andrew Hart <Andrew_Hart@harcourt.com>
Organization: The Psychological Corporation
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: PB Jaguar Performance Basics?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 46
NNTP-Posting-Host: 167.208.175.68
Message-ID: <347_38DBED53.768116D9@harcourt.com>
References: <347_38DBAA85.58B42791@harcourt.com> <347_38DBB4A1.5082DBEB@teamsybase.com> <347_38DBCE37.637CA7E6@harcourt.com> <347_38DBD274.36780419@teamsybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25720
Article PK: 155777

Hey Bill,

I first tried out the global application capture and, as you said, it only profiled the
client application. That was what I would have expected, as well. So, I stuck this
code into the activate event of my component... along with the corresponding TraceEnd
and TraceClose statements in the deactivate event.

TraceOpen("n_jag_diff.pbp",Clock!);
TraceEnableActivity(ActTrace!);
TraceBegin("n_jag_diff:activate");

No problemo. It created the pbp file in the %JAGUAR%\devbin directory. So, I grabbed
that file and carried it down to my workstation and tried to open it with the profile,
but I get the message: "The Source Libraries cannot be found, so the model cannot be
built."

So, this means I'm going to have to dig deeper, right... I see references in the help
text for analyzing a trace file programmatically. In fact, it says right there that the
PBD or PBL file must be available an in the same location as when the trace file was
built. For some reason, I'm unable to find that PROFILE.PBL file or the "sample profile
application" that is referred to. I'll keep looking.

> [...] I have these wrapped into a window that I
> use to activate profiling for my client-server applications. I started wrapping
> these into a component that I could use anywhere but never finished it. So, the
> answer is that you can use profiling yourself, the fact is that you will have to
> also write the profiler activation code yourself (unles someone already has this for
> a distributable component).
>
> You can also run the profiler on your client application only which will show you
> the function call made to the server component and how long it actually takes etc,
> but will not profile the remote component as part of the application as a whole.


Bill Green[TeamSybase] Posted on 2000-03-28 15:35:22.0Z
Newsgroups: sybase.public.easerver
Date: Tue, 28 Mar 2000 10:35:22 -0500
From: "Bill Green[TeamSybase]" <bill.green@teamsybase.com>
Reply-To: bill.green@teamsybase.com
Organization: TeamSybase
X-Mailer: Mozilla 4.6 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Hart <Andrew_Hart@harcourt.com>
Subject: Re: PB Jaguar Performance Basics?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 72
NNTP-Posting-Host: threshold3.jpmorgan.com 169.71.1.12
Message-ID: <347_38E0D13A.EBDEE5C4@teamsybase.com>
References: <347_38DBAA85.58B42791@harcourt.com> <347_38DBB4A1.5082DBEB@teamsybase.com> <347_38DBCE37.637CA7E6@harcourt.com> <347_38DBD274.36780419@teamsybase.com> <347_38DBED53.768116D9@harcourt.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25477
Article PK: 155559

No, you're ok. In order to view the profile files, you must be in the application you were
profiling, so make sure you select your Server application (in development) before trying to
view the trace file. Also, the profile viewer is not in a separate application anymore. PB7
has the Profiler tools under

File | New | Tools

What it's saying is that it must be able to resolve the source code libraries in order to
give you the profile information.



HTH,

Bill

Andrew Hart wrote:

> Hey Bill,
>
> I first tried out the global application capture and, as you said, it only profiled the
> client application. That was what I would have expected, as well. So, I stuck this
> code into the activate event of my component... along with the corresponding TraceEnd
> and TraceClose statements in the deactivate event.
>
> TraceOpen("n_jag_diff.pbp",Clock!);
> TraceEnableActivity(ActTrace!);
> TraceBegin("n_jag_diff:activate");
>
> No problemo. It created the pbp file in the %JAGUAR%\devbin directory. So, I grabbed
> that file and carried it down to my workstation and tried to open it with the profile,
> but I get the message: "The Source Libraries cannot be found, so the model cannot be
> built."
>
> So, this means I'm going to have to dig deeper, right... I see references in the help
> text for analyzing a trace file programmatically. In fact, it says right there that the
> PBD or PBL file must be available an in the same location as when the trace file was
> built. For some reason, I'm unable to find that PROFILE.PBL file or the "sample profile
> application" that is referred to. I'll keep looking.
>
> > [...] I have these wrapped into a window that I
> > use to activate profiling for my client-server applications. I started wrapping
> > these into a component that I could use anywhere but never finished it. So, the
> > answer is that you can use profiling yourself, the fact is that you will have to
> > also write the profiler activation code yourself (unles someone already has this for
> > a distributable component).
> >
> > You can also run the profiler on your client application only which will show you
> > the function call made to the server component and how long it actually takes etc,
> > but will not profile the remote component as part of the application as a whole.

--
Bill Green[TeamSybase]

-----------------------------------------------------------
Good Links to know, good places to go:

Sybase Developer Network (SDN) - http://www.sybase.com/sdn
Find things like:
-- Print to PDF component
-- Lotus Notes E-Mail component
-- Taking existing PB apps to the web white paper

PFC Guide - http://www.pfcguide.com
Power3 - Custom Training - http://www.power3.com
-----------------------------------------------------------


Andrew Hart Posted on 2000-03-29 17:33:03.0Z
Newsgroups: sybase.public.easerver
Date: Wed, 29 Mar 2000 11:33:03 -0600
From: Andrew Hart <Andrew_Hart@harcourt.com>
Organization: The Psychological Corporation
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: PB Jaguar Performance Basics: Resolution
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 79
NNTP-Posting-Host: 167.208.175.68
Message-ID: <347_38E23E4F.8E2A4185@harcourt.com>
References: <347_38DBAA85.58B42791@harcourt.com> <347_38DBB4A1.5082DBEB@teamsybase.com> <347_38DBCE37.637CA7E6@harcourt.com> <347_38DBD274.36780419@teamsybase.com> <347_38DBED53.768116D9@harcourt.com> <347_38E0D13A.EBDEE5C4@teamsybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25353
Article PK: 155453

FWIW: Since this thread was taken to email, I thought I'd summarize what we found out: (I hate
following a thread and getting only the problem exposition, not the resolution...)

The profiling application was changed to an integrated tool in PB7. The quickest and easiest
way to profile an application is to go to the Systems Option dialog (I had to add it to my
toolbar), select the "Profiling" tab, and enable tracing. This generates a file with a PBP
extension. Then, select File | New| Tools and select one of the profiling tools, then select
the PBP file that was created. You can also generate this PBP file by using the Trace functions
in powerscript, eg., TraceOpen, TraceBegin, TraceEnd, TraceClose.

If you're working at a workstation and your client app is invoking Jaguar components, the trace
file will not detail the execution of the Jaguar component, because it's executing on another
machine, in another PB virtual machine. The tracing on the client app will just show the total
time spent in that call.

To profile a jaguar component, you must generate a PBP trace file on the jaguar server itself.
To do that, you need to execute the powerscript tracing function mentioned above in the code of
your component. If you don't specify a fully qualified filename of the trace file, it looks
like it gets created in the %JAGUAR%/devbin directory.

Then, the problem is how to analyze the trace file. In the PBP file itself, are hard coded
references to the PBD files in the jaguar repository. I couldn't just open those files with the
profiling tools from my workstation using the same procedure as described above, because the
path to the library source files could not be resolved. You get the error: The Source
Libraries cannot be found, so the model cannot be created.

The options to resolve this are to: a) recreate the path to the source libraries for your
development environment, or b) analyze the trace file programmatically in the Jaguar component
itself ( or another one).

For me, I tried option (b) first and added trace functions to my base ancestor Jaguar component
and then created a component that would analyze the PBP file and create a text file. Since
Jaguar was installed on drive D of our server, for me option (a) meant remapping my CDROM to
another drive letter, creating a share to drive D on the server, mapping drive D to that server
share. I was then able to open the PBP files on the server just fine using the profiling tools
in the PB7 IDE.

While I didn't test this, I assume that if Jaguar had been installed on drive C of the server,
that I could have created an analogous directory structure with the library on my workstation,
such as C:\Program Files\Sybase\Jaguar CTS
3.0\Repository\Component\file_utils\n_jag_diff\C2\file_utils.pbd. (Note: because of "cookies",
this directory path would change, so you'd have to keep track of it...)

Finally, if the Jaguar server had been installed on my development machine, and I was calling
components on Localhost, this probably would have never even been an issue to begin with.


Mark Maslow Posted on 2000-03-24 17:59:03.0Z
Newsgroups: sybase.public.easerver
From: "Mark Maslow" <mark.maslow@sierraclub.org>
Subject: Re: PB Jaguar Performance Basics?
Date: Fri, 24 Mar 2000 09:59:03 -0800
Lines: 81
Organization: Sierra Club
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
NNTP-Posting-Host: machine001.sierraclub.org 207.90.163.1
Message-ID: <347_bOfTfubl$GA.34@forums.sybase.com>
References: <347_38DBAA85.58B42791@harcourt.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:25739
Article PK: 155790

You can do option b with a stateless component. The client can call
getChanges on its datawindow or datastore and send them to the server, where
a stateless component can apply the changes to an empty datastore and
update. This works just fine (since 3.0.1).

Using resultsets should improve performance, but is a fair amount of
coding - unless you use the framework provided by Dynamic Data Solutions
(dyn-data.com). Carson may want to add a little pitch here ...

Mark Maslow

Andrew Hart <Andrew_Hart@harcourt.com> wrote in message
news:38DBAA85.58B42791@harcourt.com...
>
> We have a two-tier PB application which we are about to begin converting
> into an N-Tier Jaguar app. In the two tier app, a simple maintenance
> datawindow gets about 8 rows from a table and displays it. The results
> are almost instantaneous. We wrote a simple component to do the same
> thing: it uses a datastore to get the results, then uses GetFullState
> to blob it and return it to the client which uses SetFullState to
> display it in the datawindow. The result is that there is a delay of a
> couple of seconds before the datawindow appears populated on the client.
>
> My boss is somewhat concerned over this and so I'm starting to dive into
> some basic performance issues. I don't have much experience profiling
> performance on PB, much less in EAS 3.5. I've read all the articles in
> this newsgroup I could find related to our scenario and have read the
> relevant articles on SDN, but I have a few questions:
>
> Since the PB VM is used to build a trace file and since, as I understand
> it, the client PB app will have it's own VM and the components running
> on the Jaguar Server will be in different VMs, is it possible to use
> these Tracetree objects to profile performance across the client app to
> the component running on Jaguar and back? Or, would you need to do
> profiling on the components separately? If it it the latter, would it
> component have to generate it's own trace file which you would then need
> to analyze separately?
>
> Maybe a better question is: what's the best way to go about profiling a
> distributed app like this?
>
> What would be some general PB performance guidelines to follow as we
> make the transition to n-tier?
>
> In a data maintenance scenario, my understanding of the possible
> techniques are:
>
> a.) GetFullState in component, send blob to client. Client uses
> SetFullState. Client uses GetFullState and sends blob with changes
> back. Component uses SetFullState and updates the database.
> Advantages: component can be stateless. Disadvantages: Sending the
> full state back and forth, of course.
>
> b.) GetFullState in component, send blob to client. Client uses
> SetFullState. After changes, client uses GetChanges and sends back
> only the mods to the component. Component uses SetChanges and updates
> database. Advantages: reduced network traffic. Disadvantages: Need
> Stateful component.
>
> c.) Sending resultsets (which are basically strings, right).
> Advantages: Faster. Disadvantages: Would need to deploy
> datawindows with client apps and the learning curve involved
> since I've yet to do this.
>
> Are there any good techniques to reduce the perceived lag in response
> time? One thing I thought about was that perhaps in the initialization
> of the client, we might transfer datawindows to the client as a blob
> and get set up. Then, from that point on, we switch over to
> transferring result sets.
>
> I think that's enough for y'all to get where I'm coming from. The stats
> in document, "Sybase EAS 3.0 - PB Windows NT Performance" are
> impressive, but don't really mean much to us. Given that we simply want
> to write PB clients accessing PB (or Java) components in an N-Tier app,
> what should we do? Upgrading server/network hardware isn't much of an
> option at this point, as that would take many, many months to wend it's
> way through the bureacracy.
>
>