Hello

Want a hyperlink in one of the attributes like this : http://Someserver/someDir/perl.pl#subject

In this way I should be able to redirect to a certain part of the html that the perl script is generating. When I setup this manually it works. ( typing directly the html link into the attribute )

 
When I put the html link into elog config file it will never show up the correct format : everything after the '#' is translated into the digit 1. ( So you get  http://Someserver/someDir/perl.pl1 . ) 

I tried to escape with \# used quoting " and '. No luck.  Tried to use the a , No luck. 

I've tested with several versions of elog but it seems that it has never worked. 

Allow HTML = 1 dit not work for me.

Has it to do with the autoincrement  ? ( Subst Number = XYZ-##### ) I think so because of the 1 that is returned if i use a http link . When I use the same link  http://Someserver/someDir/perl.pl#subject a second time i'll get back :
http://Someserver/someDir/perl.pl2 . So it seems that the auto increment feature plays a role in this one. 

Can this be done in the attributes of elog.? Can I have a # in a hyperlink ?

Thanks for your time.

Nobody needed such a functionality so far. I implemented it for you in SVN revision 2449. So you can simply escape it like "\#" 

Our group is interested in installing elog on a small/low-cost processing platform so that we can provide ready-to-run systems for our collaborators to use.  We selected a candidate platform form Technologic Systems, their wifibox-2 (http://www.embeddedarm.com/products/board-detail.php?product=TS-WIFIBOX-2).  This product is based on the TS7553 CPU board (http://www.embeddedarm.com/products/board-detail.php?product=TS-7553#) which has a 250MHz Cavium ARM9 CPU.

We have had good success getting the elogd executable cross-compiled for use on this platform and have a working system.  However, we are having significant issues with performance.  When we click the "New" item to enter a new event there is a noticable delay.  When clicking "Submit" there is a delay of approximately 10 seconds before the browser window displays the new event.  With the elogd running on other platforms (Virtual Machine or netbook) the delays for these actions are very small - typically less than a second or imperceptible.

So here are some specific questions:

- Is it reasonable to expect a 250 MHz ARM processor to serve an elog logbook with user acceptable performance?

- Our cfg file is attached.  Is there anything in the cfg file creating this performance problem.

- I have spent some time looking at this, and suspect that the delay is due to the cpu load of all the string manipulation and comparison operations (1200 calls to getcfg() on a submit).  Are there other candidate sources of performance issues that should be considered?

- Does anyone have any suggestions on how to improve our performance?

- Does anyone have a suggestion for an alternative small and low-cost COTS platform to use to host the elogd application?  (We would prefer to attain satisfactory performance on the Wifibox-2.)

Thanks for any help that can be offered.

Tim

Hi!

Looking at your config file it seems that a lot of the attributes are not user-specified but rather auto-generated content. You may want to consider using the elog client to submit such entries; this might avoid performance issues related to communication of the server with the web browser used for entry generation. This way, event entries can even be automatically created by other software rather than having a user to submit them.

Yoshio

 Yoshio,

Thanks for the suggestion.

We have actually tried running the elog server with a very minimal set of attributes, all of which were human entries, and still had response times that were entirely unacceptable.  So, unfortunately this path won't solve all our issues.

tt

Yes there is lots of string handling in elogd, but compared with PHP this is still faster. The getcfg() call actually caches the contents of the config file to improve its performance. I stopped optimization when the response was quick on a 800 MHz Pentium originally, but your 250 MHz ARM might be slower. What you can try is to

1) Verify that the CPU is really the limit, just check that the CPU is at 100% with elogd during your 10 second response time. On some installations, the submit command triggers some email notification, and actually the email server was the bottleneck.

2) If it's indded the CPU for elogd, run it under the gcc profiler. Identify which routines take most CPU and let me know. Maybe I can do something about that.

- Stefan

 Stefan,

Thanks for your feedback. 

We had confirmed that the CPU load is running at at least 95% while these requests are being processed.  Additionally, we were attempting to use gprof to determine where the code was spending its time.  We have had several problems with trying to use gprof on that platform, both with using it for elog (we get seg faults) and then with using it on a small program created to test gprof on our particular setup (program runs; we get an output file; but all routines show that zero seconds were used).  So, unfortunately, I can not, at this point, provide a good idea of which routines are using the most CPU on this platform.  If we are able to get profiling results on this particular platform, I will certainly share them with you.

A possibly more relevant angle is that we have determined that executing floating-point operations seems to have a drastic impact on software execution times.  Can you point us to routines in the elogd code where floating point operations are taking place?

Thanks,

Tim

As far as I can remember there is no floating point in elog.