Genexus applications generated for C# have slower 64-bit performance compared to 32-bit execution

Asked

Viewed 316 times

0

I have a problem in an application made in Genexus that doesn’t seem to me with much sense.

My Genexus settings are:

Genexus X Evolution 2 Upgrade 7 Build 109528
Generator C#
Environments I tested: Oracle, Postgresql and SQL Server

When I run a certain routine with the pool on IIS configured with the "Enable 32-bit applications" option active, the routine takes 1 second to run. If I disable this option on IIS and make the application run in 64 bits, it takes about 5, 6 seconds.

I generated the logs of the execution of the procedure in both 32 and 64 bits and came across these lines:

64 bits:

08:47:03,059 [1] DEBUG DataStoreProvider - Start DataStoreProvider.Ctr, Parameters: handle '1', dataStoreHelper:GeneXus.Programs.pft0027p__default
08:47:03,059 [1] DEBUG GxDataStore - Setting handle '1'
08:47:06,126 [1] DEBUG DataStoreProvider - Start DataStoreProvider.execute, Parameters: handle '1'
08:47:06,141 [1] DEBUG Cursor - Start Cursor.createCursor, Parameters: handle '1', state '1'

32 bits:

08:47:36,938 [1] DEBUG DataStoreProvider - Start DataStoreProvider.Ctr, Parameters: handle '1', dataStoreHelper:GeneXus.Programs.pft0027p__default
08:47:36,938 [1] DEBUG GxDataStore - Setting handle '1'
08:47:36,993 [1] DEBUG DataStoreProvider - Start DataStoreProvider.execute, Parameters: handle '1'
08:47:36,993 [1] DEBUG Cursor - Start Cursor.createCursor, Parameters: handle '1', state '1'

The difference in execution from one architecture to another, at least in this part of the execution, is in the line where the log says "Setting Handle".

If anyone has any ideas that could shed some light on me, I’d really appreciate it.

performance iis genexus 64-bits 32-bits

  • I have some questions: 1) Does this time difference even happen by running this object a second time ? because the first time can happen yes it takes a few seconds. 2) If the time is maintained, we would have to analyze what the pft0027p program does, especially before the first batch of data. To see if it is using any feature that is not optimized for 64 bits.

  • Thanks for the contact Pablo, let’s get to the clarifications: 1) The exorbitant time difference happens only once, in the second goes almost instantaneous... the question is that with the pool Recycle the problem happens again... 2) In case the time does not stay in the second execution of the routine, it is fast...

1 answer

0

This initial time is because of the compilation that ASP.NET, which causes all aspnet temporals to be loaded every time you change the bin folder (a new compiled Assembly or some change in the web.config). (more details here)

There is an optimization that can be used mainly in prototyping environments (where this kind of changes can happen more often).

It consists of placing this configuration on web.config (requires Framework 4.0)

<system.web>
    <httpRuntime requestValidationMode="2.0" targetFramework="4.5" />
    <compilation optimizeCompilations="true">
      <assemblies />
    </compilation>
</system.web>

This configuration is automatically generated from Genexus 15 Upgrade 5 (SAC #41361)

  • Pablo, thank you so much for your help. .

  • Pablo, I did the tests here and unfortunately it didn’t work out the way I expected, after a re-cycle in the application pool the application continued to get slow in the first run of a routine, thing that the second time the routine runs before recycling the pool doesn’t happen... =(

  • Jose, restarting the pool doesn’t have this 32-bit delay? because this initial delay can be presented when restarting the pool, but in any case (32 or 64 bits). The optimization that I commented applies when making updates. If the problem only happens with 64, then I think it would be better to send an example code (xpz) to the support get with Profiler. With this we can see the cause of the delay.

Browser other questions tagged performance iis genexus 64-bits 32-bits

You are not signed in. Login or sign up in order to post.