DX Application Performance Management

Expand all | Collapse all

.Net Agent Creation per Worker Process

  • 1.  .Net Agent Creation per Worker Process

    Posted Jul 16, 2012 08:43 AM
    Hi,

    I understand that the agents are created per worker process in .NET Application environment. In our environment we have one IntroscopeAgent.profile and the application is having 12 worker processes.

    So we get 12 agents get created, but all the agents are sharing the same agent profile.

    I have Two basic questions.

    1. What's difference between Native Profiler and Auto Probe?
    2. How do I Customize the agent creation and use differnt IntroscopeAgent.profile for each agent. This will help me to control the agent overhead.

    Regards,
    Amal


  • 2.  RE: .Net Agent Creation per Worker Process

    Posted Jul 30, 2012 01:07 PM
    Any assistance for Amal?

    Thanks!
    Mary


  • 3.  RE: .Net Agent Creation per Worker Process

    Posted Jul 30, 2012 03:09 PM
    Couple suggestions based on my limited .net experience.

    - if you had perfmon - it gets repeated for each agent(w3w) on that box. Very quickly they get out of hand and result in metric explosion.
    - turn them off by setting introscope.agent.perfmon.enable=false

    sorry i do not know how to customize .profile for each process


  • 4.  RE: .Net Agent Creation per Worker Process

    Posted Jul 31, 2012 01:19 AM
    Thanks a lot.

    I agree that we can reduce the overhead by disabling the Perfmon. The challenge is that we have single profile shared by all the agents. We need to monitor the perfmon metrics as well. So I'm trying for the possibilities of having individual profiles for each agent and control them.

    Regards,
    Amal


  • 5.  RE: .Net Agent Creation per Worker Process

    Posted Jul 31, 2012 12:10 PM
    I highly doubt you could use individual profile for each agent as they all get invoked internally


  • 6.  RE: .Net Agent Creation per Worker Process

    Posted Aug 08, 2012 05:19 AM

    Srikant.Noorani wrote:

    I highly doubt you could use individual profile for each agent as they all get invoked internally
    Yes, you can use individual profiles for each agent.


  • 7.  RE: .Net Agent Creation per Worker Process

    Posted Aug 08, 2012 10:32 AM
    Not a .net guy but I was looking for a response to this myself for couple of our .net deployments.

    Thanks a ton :)


  • 8.  RE: .Net Agent Creation per Worker Process

    Posted Aug 08, 2012 05:02 AM

    amalan_j wrote:

    Hi,

    I understand that the agents are created per worker process in .NET Application environment. In our environment we have one IntroscopeAgent.profile and the application is having 12 worker processes.

    So we get 12 agents get created, but all the agents are sharing the same agent profile.

    I have Two basic questions.

    1. What's difference between Native Profiler and Auto Probe?
    2. How do I Customize the agent creation and use differnt IntroscopeAgent.profile for each agent. This will help me to control the agent overhead.

    Regards,
    Amal
    Hi Amal,

    Below are the answers to your questions.

    Answer 1:
    NativeProfiler is the default instrumentation method for all .NET agents 9.0 and higher. AutoProbe is provided as an option for legacy compatibility issues.

    By default, .NET agents use NativeProfiler to instrument applications, and all applications (and application pools) that run under IIS are instrumented. The instrumentation does not change the functionality of your applications. The probes are inserted into the bytecode to record application activity and send this information to the Enterprise Manager.
    Note: When you install the .NET agent, you can choose NativeProfiler or AutoProbe to instrument your applications. AutoProbe is available primarily as a backup option for applications that cannot be instrumented with NativeProfiler or have legacy compatibility issues. CA Technologies recommends using NativeProfiler for all .NET agents unless you encounter compatibility issues.


    Answer 2:
    The .NET Framework permits configuration of application specific parameters using an optional XML format file with a .config extension.
    For ASP.NET applications, web.config is the main file for application-specific settings and configuration. This file is stored in the application root directory.
    For other .NET executables, the configuration file is named the same as the application appended with a .config extension. The file is stored in the same directory as the application executable. For example, for testapp.exe, the optional configuration file would be testapp.exe.config.

    It is possible to add Introscope specific configuration to the .config file. For example, parameters can be set that enable individual applications to reference their own instance of the IntroscopeAgent.profile file (to permit different applications to have different agent configurations), as well as to enable cross-process transaction correlation for web services.

    You basically create a separate IntroscopeAgent.profile for each of your applications. Then add a sectionGroup and section in the *.config file for your appliaction as follows:
    <configuration>
    <configSections>
    <sectionGroup>
    <sectionGroup name="com.wily.introscope.agent">
    <section name="env.parameters"type="System.Configuration.NameValueSectionHandler" />
    </sectionGroup>
    <configSections>
    <configuration>

    Then add new properties to the env.parameters section as follows:
    <com.wily.introscope.agent>
    <env.parameters>
    <add key="com.wily.introscope.agentProfile" value="e:\\junkyard\\dotnettest\\Agent.profile" />
    </env.parameters>
    </com.wily.introscope.agent>

    Repalce Agent.profile with the appropriate introscopeAgent.profile that you tailored for this application.

    For an example, see sample.exe.config file which is created in the %AGENT_HOME%\wily directory.

    Note: All this information is available in CA Wily Introscope .Net Agent Guide.pdf.

    Hope you are satisfied with the answers. If yes, please mark your question as resolved.

    Arij


  • 9.  RE: .Net Agent Creation per Worker Process

    Posted Aug 08, 2012 10:54 AM
    There is another option that we are using that is not documented but works that allows you to use the same agent profile for all agents but give each agent a specific name. This is useful if you are going to have the same configuration for all your agents except for the name.

    By default, when you install the .NET agent, it will set the following environment variable:


    com.wily.introscope.agentProfile = <path to agent profile>\IntroscopeAgent.profile

    This causes all .NET applications to use that file as it's agent profile unless you use the other suggestions to override it in the application's config file (e.g. web.config).

    To override the name, add the following to the application's config file:


    <sectionGroup name="com.wily.introscope.agent">


    <section name="env.parameters" type="System.Configuration.NameValueSectionHandler" />

    </sectionGroup>

    and...


    <com.wily.introscope.agent>


    <env.parameters>



    <add key="com.wily.introscope.agent.agentName" value="<specific name for this agent>" />


    </env.parameters>

    </com.wily.introscope.agent>

    If you ever need to vary the configuration for one or a few agents, you can always use the other approach to specify a unique agent profile.

    Hope this helps.


  • 10.  RE: .Net Agent Creation per Worker Process

    Posted Aug 08, 2012 11:31 AM
    So this way couldn't we make any property specific to a particular agent. for e..g

    <com.wily.introscope.agent>
    <env.parameters>
    <add key="Say my log folder for this agent" value="<specific log folder path of this agent>" />
    </env.parameters>
    </com.wily.introscope.agent>


  • 11.  RE: .Net Agent Creation per Worker Process

    Posted Aug 08, 2012 11:38 AM
    It may be possible... I've only tried it for the agentName.

    One thing to keep in mind is this is not documented and as such it may not be supported. I would definitely recommend retesting every time you upgrade to be sure things are still working.