GC problem using Snap

[Eric Wong]

Hi,

I wrote a simple server using Snap-0.6.1 and snaplet-hdbc-0.6.2.2. When profiling the app, I find that it spends about 65% of time doing GC. After investigating my code for a long time, I found no problem there. 

So I disabled all the real code, leaving only the bare-bone snap structure, I don't use heist either. Then I start the server and stop it later, without processing any request, it spent 32% of the time doing GC.

Then I enable snaplet-hdbc, only init it with code to connect to a mysql server. Then start and stop the server, without processing any request either, it spent 60% of the time doing GC.

Then I create a new app with "snap init" and compile the default template app and run it. So it uses heist this time and it spent about 60% of the time doing GC.

So, is this a known problem? Does the new version improve on this aspect?

Thanks.

Eric

[MightyByte]

Eric,

Try with snaplet-hdbc-0.7. I talked to the author (CC'd) and he said
that 0.6 had some issues. I also tried your startup and shutdown test
with snap-website and I get 30% GC time. snap-website uses the Heist
snaplet and the static pages snaplet but not the hdbc snaplet, which
suggests that this issue is unique to snaplet-hdbc and not an
across-the-board issue with the overall snaplet system.

On Thu, Dec 15, 2011 at 10:38 AM, MightyByte <might...@gmail.com> wrote:

[Gregory Collins]

On Thu, Dec 15, 2011 at 4:54 PM, MightyByte <might...@gmail.com> wrote:

Eric,

Try with snaplet-hdbc-0.7.  I talked to the author (CC'd) and he said
that 0.6 had some issues.  I also tried your startup and shutdown test
with snap-website and I get 30% GC  time.  snap-website uses the Heist
snaplet and the static pages snaplet but not the hdbc snaplet, which
suggests that this issue is unique to snaplet-hdbc and not an
across-the-board issue with the overall snaplet system.

I'm not sure that's necessarily true -- the process of looking into this has led us to a couple of performance problems in Heist and xmlhtml that we're in the middle of fixing. 

G

--
Gregory Collins <gr...@gregorycollins.net>