[Glass] Profiling of Seaside code in Quuve

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Tue May 30 11:56:59 PDT 2017

Allen's answer to Mariano...

-------- Forwarded Message --------
Subject: 	Re: Profiling of Seaside code in Quuve
Date: 	Tue, 30 May 2017 11:13:47 -0700
From: 	Allen Otis <allen.otis at gemtalksystems.com>
To: 	Mariano Martinez Peck <marianopeck at gmail.com>
CC: 	Dale Henrichs <dhenrich at gemtalksystems.com>


I will try to reply to all of your emails since May 26  with one email .

There is not currently a way to get only the "STATISTICAL SAMPLING RESULTS"
printed.  You could use something like
    reportDownTo: 95
to exclude from the report methods below 95% of total time and thus
make the report a lot shorter.

I cannot find in the image comments where it says
    gcTime implies #real
All the  "gcTime implies" that I find in comments are of the form
   #gcTime implies default #cpu  and is in units of milliseconds

What version of GemStone are you running ?

How much temp obj memory are you configured for when you run
out of memory ?

For profiling a web framework, I recommend that your web frame work
provide a profile method something like this

classmethod: AFrameworkClass
profile: aBlock
   "commits an instance of ProfMonitor for later analysis"
   | p |
   (p := ProfMonitor new )
     setOptions: #(gcTime)  ;
     intervalNs: 200000 . "200 microsec,
              or replace with a value computed using ProfMonitor
   p startMonitoring.
   aBlock value .
   p stopMonitoring .
   "At this point p contains the filename to which profile data has
been written."
   UserGlobals at: #ProfInstance put: p .
   System commit

Then in a separate interactive session configured
with several GB of temp object memory,

   "Read the profile data file and generate the report.
   (UserGlobals at:#ProfInstance) reportAfterRunDownTo: 5

I would think that 2GB of temp obj memory should be enough
to analyze a file of 200000 sample points .
For this example
    ProfInstance instVarAt: 8
will return the number of sample points that were written to the file.

And after you are finished with generating the report
you may want to run

   (UserGlobals at: #ProfInstance) removeFile .
   UserGlobals removeKey: #ProfInstance .
   System commit .

There are a couple of problems in the current implementation of ProfMonitor
that make the above usage difficult to achieve and I have attached a patch
file to fix those.

Also the instance of ProfMonitor writes the sample file to the gem's current
directory, so the interactive session needs to run a gem in that same
directory, or else further edits to  ProfMonitor >> _openFileRead ,
and the call path from reportAfterRunDownTo: down to  _openFileRead
may be needed.


On Mon, May 29, 2017 at 6:15 AM, Mariano Martinez Peck
<marianopeck at gmail.com> wrote:
> Hi Allen,
> Thank you very much for reaching me out. I am very happy reading about
> #computeInterval: because I have a very nice profiling framework within my
> application which allows me to profile seaside requests from the web itself.
> However, one of the problems was that having a fixed interval is not good as
> I may profile different scenarios that take different time, and so, the
> numbers of samples may not be good for some scenarios.
> Before coming back to you with a higher resolution profiling, please allow
> me to improve my profiling framework with this new idea you gave me.
> Once again, thanks for your contact.
> Best regards,
> On Thu, May 25, 2017 at 8:07 PM, Allen Otis <allen.otis at gemtalksystems.com>
> wrote:
>> Mariano,
>> I have been looking at the ProfMonitor output in the file
>> RequestProfile2017-04-14T15_06_17_65757894515991-04_00.txt
>> which you sent to Norm Green .
>> We have higher resolution profiling methods available now ,
>> see the class methods with keyword  intervalNs: in ProfMonitor .
>> The method
>>   ProfMonitor class >> computeInterval:
>> will help you determine an appropriate argument to the intervalNs: keyword
>> .
>> Would you send us another ProfMonitor output  with high resolution
>> sampling ?
>> See my notes below.
>> I will be on vacation May 26 - May 29, so won't be looking at a
>> any new profiling data until next week.
>> Allen
>> --------------------------------------------
>> Your previous profiling run had elapsed time of 1394ms
>> topaz 1> run
>> ProfMonitor computeInterval: 1.4
>> %
>> 69999
>> So I would recommend something like
>>   intervalNs: 70000
>> for your next profiling run.
>> You should have GEM_TEMPOBJ_CACHE_SIZE at least 300MB  for the profiling.
>> If you have trouble with too many sample points , multiply the
>> result of   computeInterval:   by 2  or  4 .
>> ---------------
>> These are already in your GemStone image:
>> category: 'Estimating'
>> classmethod: ProfMonitor
>> computeInterval: unprofiledCpuTimeSeconds
>>  "Returns an estimated profiling interval in nanoseconds for an execution
>>   taking the specified amount of cpu time, to yield approximately
>>   100000 samples . For 100000 samples, GEM_TEMPOBJ_CACHE_SIZE should
>>   be set to at least 300MB to avoid AlmostOutOfMemory errors during
>> analysis
>>   phase."
>>  | ns |
>>  ns := (5.0 * unprofiledCpuTimeSeconds / 100000 / 1.0e-9 ) asInteger .
>>  ns < 1000 ifTrue:[ ns := 1000 ].
>>  ^ ns
>> %
>> category: 'Quick Profiling'
>> classmethod: ProfMonitor
>> monitorBlock: aBlock intervalNs: nanosecondsPerSample
>> "Profile the execution of a block and return a formatted report of the
>> results.
>>  The nanosecondsPerSample argument gives the CPU time interval
>>  between samples, and the results are reported down to methods that
>>  use 3% of the total time"
>> ^ self monitorBlock: aBlock
>>        downTo: 0.03
>>        intervalNs: nanosecondsPerSample
>>        options: #()
> --
> Mariano
> http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170530/57ced222/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch46903a.tpz
Type: application/octet-stream
Size: 813 bytes
Desc: not available
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170530/57ced222/attachment-0001.obj>

More information about the Glass mailing list