Impact on performance by excessive getenv()

[Raghava_1]

Hi,

There is a process (lets call it our_server). our_server calls getenv() excessively. We have around 500 environment variables which our_server (and all other processes forked off by our_server) might refer to during their time.

Would accessing too many env variables, using getenv() or calling getenv() many times impact the performance of the process? Is there a better alternative (populating a list and accessing the value from it?) Please suggest.

When a getenv is done, would it do a linear search for the said variable in the list of env variables to fetch the value?

Is it possible to identify (from outside the running program) the most highly used environment variable? [like an alternative for Sun's dtrace on HPUX]

Please let me know.

Thanks!
raghava

[DeafFrog]

Hi ,

Not sure , but can the wdb utility be of help.

regards ,
FrogIsDeaf

[Duncan Edmonstone]

I'm no programmer, but I suspect the _short_ answer to your question is yes it will cause a performance issue (I seem to recall a similar problem in Oracle if you set things up wrong) - Hopefully Dennis H will look at this thread and can probably give you a better answer...

You don't mention whether you're on PA-RISC or Integrity and waht OS version, but assuming you are on Integrity, for software to get to the bottom of your problem - I'd take a look at caliper...

http://www.hp.com/go/caliper

If you are on HP-UX11iv3 (11.31) you might also want to look and see if the following helps:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1414797

(although you didn't mention that your app was multi-threaded)

HTH

Duncan

[Laurent Menase]

if you are able to recompile your application define a
getenv() which calls _getenv() in your process and count for each program how many time it calls it for every env variable.
If you can't rebuild there are also some other way to build a shared lib which is preloaded before the libc and overload the getenv() - you also could implement your own hashed getenv() there for instance-

A linear search is indeed made over env variable since it is a unordered table of pointers to different env variables. ( like argv ones but pointed by "char **environ;)
The search always starts at environ[0]


You can build a new env variable table before calling child processes, setting the most used first.

[Raghava_1]

@laurent && @duncan: Thanks!

@duncan: This indeed was found using caliper itself. :) caliper reports show that getenv() took a sizable chunk of processing time and hence we started looking into it. But we are not sure if there are only few of those environmental variables which cause this concern. BTW, am working on an HP-UX 11.31 ia64 machine. And our app is not multi-threaded.

@laurent: I would be able to rebuild the whole set of app.
>>your own hashed getenv()
That is the idea. We are working on it.

Thanks again!

[Dennis Handly · Accepted solution]

You don't want to call getenv(3) excessively. If you call it, you should cache the value.

Each call to getenv(3) has to lock a mutex, if threaded.
There is an enhanced getenv(3) for performance you can download for 11.31, Getenv-Perf-Enh:
http://docs.hp.com/en/5992-3373/ch10s04.html
https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=GetenvPerf

>Is there a better alternative (populating a list and accessing the value from it?)

Well, if readonly, copy from your environment to a global variable. Or if you really need access based on strings, a map.

>When a getenv is done, would it do a linear search for the said variable in the list of env variables to fetch the value?

Yes, unless Getenv-Perf-Enh creates a map?

>Is it possible to identify (from outside the running program) the most highly used environment variable?

If you have to identify it, you are making way too many calls to getenv(3)!

>But we are not sure if there are only few of those environmental variables which cause this concern.

I'm not sure you care about "few" or not. Just don't call getenv(3) so much. In particular you should NOT be using local time. I.e. all timestamps should be time_t.

>Duncan: you might also want to look and see if the following helps: threadId=1414797

(That's this thread.)

[Duncan Edmonstone]

Dennis,

> >Duncan: you might also want to look and
> see if the following helps: threadId=1414797
>
> (That's this thread.)

D'oh! meant to post the link to Getenv-Perf-Enh

Duncan