> Is there something else  which is making this difficult to do?

Not really, but hsearch() & Co. are not available under Windows, so I have to extract the
source code from the GNU C libarary or so. Since the last discussion I had lots of other
topics on my to-do list, such as mirroring and cloning, but the speed issue is getting more
and more up on the priority list.

> > Is there something else  which is making this difficult to do?
> 
> Not really, but hsearch() & Co. are not available under Windows, so I have to extract the
> source code from the GNU C libarary or so. Since the last discussion I had lots of other
> topics on my to-do list, such as mirroring and cloning, but the speed issue is getting more
> and more up on the priority list.

Speaking of windows I'd like to note that when I moved my call tracking config from a slow BSD
system (PPro 200Mhz) to a faster windows system (P3 733M) I noted a huge slow down in the
interface.  Talking about perhaps 1-2 seconds before to 10-15 seconds after.  Using
sysinternals file monitor I see that elogd is hammering each log file in the directory.  Not
sure what else is going on.  309 log files - only 1.25Meg.  

Anything I can do short of pruning down the files?

[Edit:  In both cases above my default view is filtered and sorted - so that I only see things
with a specific status.  Taking away the filtering resolves this hit - but does not explain the
speed difference between platforms.]

-D

This is a very nice measurement you made and helps me a lot. I will 
incorporte your suggestions into the next version. Under Windows however, 
there is no -HUP signal, so that won't work for them. But what I can easily 
do is to check for new configuration/language file once every access, not 
once every loc() or getcfg(). I till think about.

Thanks again,

  Stefan

I implemented the new scheme where 

- under Windows, the configuration is only checked once every access

- under Unix, the configuration is read initially, and on every -HUP signal

This should speed up the server considerably. The next bottleneck is the 
rsputs2() function, which requires quite some computing power in order to find 
any "http://", "//", etc. strings in every output. If anybody knows a 
more clever way of coding that, please let me know.

The new version is under CVS.

> I implemented the new scheme where 
> 
> - under Windows, the configuration is only checked once every access
> 
> - under Unix, the configuration is read initially, and on every -HUP signal
> 
> This should speed up the server considerably. The next bottleneck is the 
> rsputs2() function, which requires quite some computing power in order to find 
> any "http://", "//", etc. strings in every output. If anybody knows a 
> more clever way of coding that, please let me know.
> 
> The new version is under CVS.

may be use the logic in the 'format' attribute
like 'email', http, ftp 
so elog will test only on these attributes

> any way to specify that a particular option be in a date format or even 
> the ability to specifiy the category must be of a particular format:
> -must be a number 
> -must be a date
> -must be alpha
> -must be certain length

Put on the wish list as well.