adding profiling to GemStone

Hi,

I want to reuse the current Seaside-Pharo-Development-Core-Profiler
classes in GemStone. So I moved the general classes to
Seaside-Development-Core-Profiler and created a hook that implements
Pharo and GemStone specific profiling in
Seaside-Pharo-Development-Core-Profiler and
Seaside-GemStone-Core-Profiler respectively.

I made some changes in Seaside-Development and
Seaside-Pharo-Development here: https://github.com/finworks/Seaside30.

Is this change helpful for Seaside?

The GemStone version is simplistic at the moment; I'm really battling
to get it to work in GemStone. My problem is that the block being
profiled does not return; the response notification seem to block in
GemStone and does not return in #handleFiltered:. I would like to
incorporate ProfMonitor, but I'm not even getting as far as measuring
the time it took to execute #handleFiltered:.

Does anyone have an idea how I can profile seaside requests in GemStone?

Thanks
Otto
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I think (I am not sure) that what I did was to simply surround the
> #handleRequest: of the adaptor I was using with a ProfMonitor script.
> Example...I modify WAServerAdaptor:
>
> WAServerAdaptor >> handleRequest: aRequestContext
> "Pass the request context to the appropriate request handler."

Well, I thought that this was what I tried, but maybe not. I'll try
again. Thanks.

> Notice that I remember doing this in the Zinc adaptor but I guess it would
> be fine here as well.

It could just make a difference; I'll try there as well.

> Ideally, I would love an inspect here at the end to inspect the results in
> GemTools, but since it runs in its own gem it is difficult to get an
> inspector in GemTools (we discussed this with Dale in a separate mail). So I
> simply write the string to a file.

The profiler tool in Seaside allows one to keep results in an object,
which I suppose one can inspect. I'm trying to write a GS version.

> The profile also write is own file with the results. Send #fileName to the
> monitor and you would get something like '/tmp/gem26398.pro'. I thought I
> could recreate back a profiler instance and open the results with such a
> file, but i didn't find it. That's why for the moment I was simply writing
> the string into a file.
>
> Hope this helps,

Thanks, I'll give it a shot.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>> I think (I am not sure) that what I did was to simply surround the
>> #handleRequest: of the adaptor I was using with a ProfMonitor script.
>> Example...I modify WAServerAdaptor:
>>
>> WAServerAdaptor >> handleRequest: aRequestContext
>> "Pass the request context to the appropriate request handler."
>
> Well, I thought that this was what I tried, but maybe not. I'll try
> again. Thanks.

Works nicely, thanks. Using ProfMonitor because ProfMonitorTree gave
me a stack overflow though - infinite recursion. But I'm still running
2.4.4.4. Should upgrade.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Tue, Dec 31, 2013 at 3:03 PM, Otto Behrens <[hidden email]> wrote:
> Hi,
>
> I want to reuse the current Seaside-Pharo-Development-Core-Profiler
> classes in GemStone.

I believe I saw a profiler one but maybe my memory is playing tricks with me.

Yes, once you have a running version and know which hooks you need.

> The GemStone version is simplistic at the moment; I'm really battling
> to get it to work in GemStone. My problem is that the block being
> profiled does not return; the response notification seem to block in
> GemStone and does not return in #handleFiltered:. I would like to
> incorporate ProfMonitor, but I'm not even getting as far as measuring
> the time it took to execute #handleFiltered:.
>
> Does anyone have an idea how I can profile seaside requests in GemStone?

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>> I made some changes in Seaside-Development and
>> Seaside-Pharo-Development here: https://github.com/finworks/Seaside30.
>>
>> Is this change helpful for Seaside?
>
> Yes, once you have a running version and know which hooks you need.

The version I've got here:
https://github.com/finworks/Seaside30/tree/portProfilerToolToGemStone
works in Pharo. It just moves some code around and created some hooks.

But in GemStone it still hangs. This is the crux of the code:

WAProfilerItem | profile: aBlock
        | result |
        self startProfiling.
        result := self runProfilerOn: aBlock.
        self endProfiling.
        ^ result

WAProfilerItem moved to Seaside-Development. startProfiling and
endProfiling simply records the start and end time stamps.

WAPharoProfilerItem | runProfilerOn: aBlock
        tally := MessageTally new.
        tally reportOtherProcesses: false.
        ^ tally spyEvery: 1 on: aBlock

Pharo specific subclass that is in Seaside-Pharo-Development.

WAGemStoneProfilerItem runProfilerOn: aBlock
        ^ aBlock value

The GS specific subclass in Seaside-GemStone-Development. The idea is
that it runs ProfMonitor. But we're not getting to that point yet.
aBlock value does not return.

WAProfilerFilter | handleFiltered: aRequestContext
        | item |
        item := self itemClass request: aRequestContext request copy.
        [ item profile: [ super handleFiltered: aRequestContext ] ]
                ensure: [ items := items copyWith: item ]

The itemClass method is loaded with either Seaside-Pharo-Development
or Seaside-GemStone-Development. Not sure if this is the most elegant
way of getting platform specific behaviour here. If you have a better
one, please let me know.

Thanks
Otto
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Otto,

I will try to look into the profiler issues for GemStone ... I'm not familiar with the Seaside Profiler code ... I wrote a nice profiler for Seasdie3.8 way back when, but that work never got ported to Seaside3.0 ...

Dale

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email], "Seaside - general discussion" <[hidden email]>
| Sent: Tuesday, December 31, 2013 6:03:17 AM
| Subject: [Glass] adding profiling to GemStone
|
| Hi,
|
| I want to reuse the current Seaside-Pharo-Development-Core-Profiler
| classes in GemStone. So I moved the general classes to
| Seaside-Development-Core-Profiler and created a hook that implements
| Pharo and GemStone specific profiling in
| Seaside-Pharo-Development-Core-Profiler and
| Seaside-GemStone-Core-Profiler respectively.
|
| I made some changes in Seaside-Development and
| Seaside-Pharo-Development here:
| https://github.com/finworks/Seaside30.
|
| Is this change helpful for Seaside?
|
| The GemStone version is simplistic at the moment; I'm really battling
| to get it to work in GemStone. My problem is that the block being
| profiled does not return; the response notification seem to block in
| GemStone and does not return in #handleFiltered:. I would like to
| incorporate ProfMonitor, but I'm not even getting as far as measuring
| the time it took to execute #handleFiltered:.
|
| Does anyone have an idea how I can profile seaside requests in
| GemStone?
|
| Thanks
| Otto
| _______________________________________________
| Glass mailing list
| [hidden email]
| http://lists.gemtalksystems.com/mailman/listinfo/glass
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Otto,

I've pulled your portProfilerToolToGemStone branch over to the glassdb repo where we'll be able to share code ... I should be able to spend some time tomorrow working on this...

Dale

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email], "Seaside - general discussion" <[hidden email]>
| Sent: Tuesday, December 31, 2013 6:03:17 AM
| Subject: [Glass] adding profiling to GemStone
|
| Hi,
|
| I want to reuse the current Seaside-Pharo-Development-Core-Profiler
| classes in GemStone. So I moved the general classes to
| Seaside-Development-Core-Profiler and created a hook that implements
| Pharo and GemStone specific profiling in
| Seaside-Pharo-Development-Core-Profiler and
| Seaside-GemStone-Core-Profiler respectively.
|
| I made some changes in Seaside-Development and
| Seaside-Pharo-Development here:
| https://github.com/finworks/Seaside30.
|
| Is this change helpful for Seaside?
|
| The GemStone version is simplistic at the moment; I'm really battling
| to get it to work in GemStone. My problem is that the block being
| profiled does not return; the response notification seem to block in
| GemStone and does not return in #handleFiltered:. I would like to
| incorporate ProfMonitor, but I'm not even getting as far as measuring
| the time it took to execute #handleFiltered:.
|
| Does anyone have an idea how I can profile seaside requests in
| GemStone?
|
| Thanks
| Otto
| _______________________________________________
| Glass mailing list
| [hidden email]
| http://lists.gemtalksystems.com/mailman/listinfo/glass
|
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email], "Seaside - general discussion" <[hidden email]>
| Sent: Tuesday, December 31, 2013 6:03:17 AM
| Subject: [Glass] adding profiling to GemStone
|

....

| The GemStone version is simplistic at the moment; I'm really battling
| to get it to work in GemStone. My problem is that the block being
| profiled does not return; the response notification seem to block in
| GemStone and does not return in #handleFiltered:. I would like to
| incorporate ProfMonitor, but I'm not even getting as far as measuring
| the time it took to execute #handleFiltered:.

Otto,

Just to get onto the same page, when I load Seaside from the portProfilerToolToGemStone branch, I get a MNU in my browser (see attach png)...

I'm working in 3.x (3.2 actually ... using tODE), so if you are seeing something different, then I will need to switch to 2.4.4...

Dale
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Otto,

I created a pull request[1] that fixes the problems that I ran into with this code.

I "fixed the problem with the profiled block not returning" by putting in an ensure block ... AFAIK, when one is working with #handleFiltered:, the code that follows the block does not get executed because continuations are getting created and normal block execution does not apply ... I looked at the other filter tools and it looks like they were all using ensure blocks to perform work "after block execution" and that grick worked for WAProfilerItem>>profile too.

Once I got past that I ran into an issue with  WAHttpVersion>>= and its interaction with WAGemStoneInspector...

I haven't done anything more with the profile, but it is tempting to port the Seaside2.8 code to Seaside3.0, since I'm in the neighborhood:)

Dale

[1] https://github.com/finworks/Seaside30/pull/1
[2] https://github.com/finworks/Seaside30/pull/1/files#diff-c0eef7b0cdc9950e3b3d984ae86197eaL2

----- Original Message -----
| From: "Dale K. Henrichs" <[hidden email]>
| To: "Otto Behrens" <[hidden email]>
| Cc: [hidden email], "Seaside - general discussion" <[hidden email]>
| Sent: Sunday, January 5, 2014 10:08:24 AM
| Subject: Re: [Glass] adding profiling to GemStone
|
|
|
| ----- Original Message -----
| | From: "Otto Behrens" <[hidden email]>
| | To: [hidden email], "Seaside - general discussion"
| | <[hidden email]>
| | Sent: Tuesday, December 31, 2013 6:03:17 AM
| | Subject: [Glass] adding profiling to GemStone
| |
|
| ....
|
| | The GemStone version is simplistic at the moment; I'm really
| | battling
| | to get it to work in GemStone. My problem is that the block being
| | profiled does not return; the response notification seem to block
| | in
| | GemStone and does not return in #handleFiltered:. I would like to
| | incorporate ProfMonitor, but I'm not even getting as far as
| | measuring
| | the time it took to execute #handleFiltered:.
|
| Otto,
|
| Just to get onto the same page, when I load Seaside from the
| portProfilerToolToGemStone branch, I get a MNU in my browser (see
| attach png)...
|
| I'm working in 3.x (3.2 actually ... using tODE), so if you are
| seeing something different, then I will need to switch to 2.4.4...
|
| Dale
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I created a pull request[1] that fixes the problems that I ran into with this code.
>
> I "fixed the problem with the profiled block not returning" by putting in an ensure block ... AFAIK, when one is working with #handleFiltered:, the code that follows the block does not get executed because continuations are getting created and normal block execution does not apply ... I looked at the other filter tools and it looks like they were all using ensure blocks to perform work "after block execution" and that grick worked for WAProfilerItem>>profile too.

Thanks, Dale. I can do more with the profile now.

> I haven't done anything more with the profile, but it is tempting to port the Seaside2.8 code to Seaside3.0, since I'm in the neighborhood:)

Are you talking about glassdb/Seaside30? Is there some porting work to
be done in here? Perhaps it's worth it to go for Seaside 3.1. Let me
know where I can help.

Thanks
Otto
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: "Dale K. Henrichs" <[hidden email]>
| Cc: [hidden email], "Seaside - general discussion" <[hidden email]>
| Sent: Sunday, January 5, 2014 12:15:32 PM
| Subject: Re: [Glass] adding profiling to GemStone
|
| > I created a pull request[1] that fixes the problems that I ran into
| > with this code.
| >
| > I "fixed the problem with the profiled block not returning" by
| > putting in an ensure block ... AFAIK, when one is working with
| > #handleFiltered:, the code that follows the block does not get
| > executed because continuations are getting created and normal
| > block execution does not apply ... I looked at the other filter
| > tools and it looks like they were all using ensure blocks to
| > perform work "after block execution" and that grick worked for
| > WAProfilerItem>>profile too.
|
| Thanks, Dale. I can do more with the profile now.

I'm pretty familiar with the gory details of the GemStone profiler, if you want some more help...

|
| > I haven't done anything more with the profile, but it is tempting
| > to port the Seaside2.8 code to Seaside3.0, since I'm in the
| > neighborhood:)
|
| Are you talking about glassdb/Seaside30? Is there some porting work
| to
| be done in here? Perhaps it's worth it to go for Seaside 3.1. Let me
| know where I can help.

I was thinking glassdb/Seaside30 since that's where you're doing the current profiling work...

Dale
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside