This is not really a bug, but elogd was getting really slow with our
logbook. It took about 4 1/2 seconds just to get the default page in
threaded mode with 15 entries. The logbook has in total about 2000
entries, though.
After playing around with the compiler option '-gp' and gprof the
problem was found: loc() is called about 18000 times per logbook
access! (Attached you can find the gprof output. There might be
other places where to save time: e.g. getcfg().) The function loc()
calls stat every time to check if the language file was updated and
this takes a long time especially over NFS.
The quick solution for me was to just replace loc() with 'char
*loc(char *orig) {return orig;}'. Therefore, I cannot use the
localization that I used anymore, which is not a big problem at the
moment. After that the time to download the default page was only
0.16 s; almost a factor of 30 faster!
I would suggest to only read the language file (AND also the config
file!) once upon startup. After changing things one has to restart
elogd, which is not so nice, but the long delay is not acceptable.
Another option not to restart elogd is to make elogd respond to a
signal (e.g. kill -HUP) to reread the config and language files. |
impossible to create the moptions with
-a Type#0="%D1%"
-a Itel#0="%zItel%"
the variable are set to
set D1=Tel
set zItel=Tel.gif
other standard option work fine
does anybody has good experience with elog.exe command ?
elog -h 'my site elo' -p 83 -l 'my logbook' -a Phone="%2" -a Contact="%3 %
4" -a Type#0="%D1%" -a Cat="%5" -a Itel#0="%zItel%" "%6 %7 %8 %9"
----------------------------- here are the config in elog
[titiPHONE]
Comment = PhoneList
Find menu text = menu/titiphone_top.html
Data dir = prive_Etienne/PhoneList
Guest Menu commands = Help
Find Guest Menu Commands = Help
Attributes = Phone, Itel, Dossier, Ext_direct, Societe, Contact, Cat,Type,
Prive, Email, Adress, City, Relation, By
Quick filter = Itel,Type,Dossier,Date,Prive
Roptions Prive = no,CD,EC,MD,NB,TR,TV,AH,NW,JW,Manon
IOptions Itel = Tel.gif, TelDirect.gif, Fax.gif, Gsm.gif, Tel2.gif,
TelHome.gif,TelFax.gif,TelHelp.gif
ROptions Type = Tel,TelDirect,Fax,Gsm,Tel2,Home,Combine,TelHelp
Preset Itel = Tel.gif
Preset Type = Tel
Preset Prive = no
Preset Email =
Display mode = Summary
Thread Icon = Itel
Thread display = $Phone,$Contact,$Dossier,$Societe($Type/$prive) |
> We have been using Elog successfully as a shiftlog book for over a month
> now, but I recently ran into an annoying bug, I think.
> We had a thread that was created and was being replied to over several
> days. We first replied to the original thread and then each subsequent
> reply was a reply of the previous reply. When the thread reached above 13
> of these, the elogd.exe would crash everytime a user attempted to select
> the logbook that contained the enormous thread.
> I found the only workaround was to manually delete the offending entry
> from the log file and to instruct my users to not reply to replies unless
> absolutely necessary. I have been able to replicate this error across the
> rest of my logbooks as well. If there is any more information you may
> need, please feel free to contact me.
Sorry my late reply, I was pretty busy these days...
I tried to reporduce your problem, but without success. Have a look at
http://midas.psi.ch/elogdemo/Linux/32
where I replied 20 times producing a very long thread without any problem. So
can you reproduce your problem? I suspect that there was some other problem,
since the number of replies is internally not limited in any way. If you
again get into a situation where elodg.exe crashes on the *DISPLAY* of some
message, you can send me the offending file xxxxxxa.log directly by email and
I can analyze it. Only if I can reproduce a problem, I can fix it.
- Stefan |
> I don't see anyway to define a log as an attribute. May be I just don't understand
> something. I have more than 50 logs anyway.
What I meant was having only one logbook, and having the server as an attribute like
Attributes = Server, Type, ....
Options Server = Server1, Server2 (just the names of your current logbooks)
...
If you have already 50 logbooks this would require quite some work of course, but it might
something for the future. I don't know if this fits into your requirements. If not, please
let me know your complete scheme (current attributes and logbooks), then I can think about. |