Re: HW Requirements to run elog / Performance issues running on ARM, posted by Tim Thiel on Mon May 14 22:19:50 2012
|
Stefan Ritt wrote: |
Tim Thiel wrote: |
Yoshio Imai wrote: |
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 |
Re: HW Requirements to run elog / Performance issues running on ARM, posted by Stefan Ritt on Tue May 15 08:35:16 2012
|
Tim Thiel wrote: |
Stefan Ritt wrote: |
Tim Thiel wrote: |
Yoshio Imai wrote: |
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. |
Periodic backup doesn't work .., posted by Roland Gsell on Mon May 21 14:41:25 2012 
|
Hi,
I installed ELOG on other machine for making automatic backups. I copied the .cfg file to the slave and edited the .cfg file on the original machine (mirror server entries).
(automatic configuration with -C didn't work somehow - maybe a firewall problem)
Then I tried to synchronize manually, which works great.
I set the mirror cron = 0 7-18 * * 1-5, as written as example in the documents, but nothing happens at full hours.
There's something else strange: I can't access "https://lx0.mydomain.org/" or "http://lx1.mydomain.org:8082/" directly. The browser just keeps loading - showing an empty page (and an error message after a long while). I have to add the name of the logbook to the link. Why is that?
If I set different paths in the [global HBAR] and [global SMI] areas (like URL = https://lx0.mydomain.org/hbar/), I can access the links above (giving me the overview page as expected), but I can't access the logbooks itself anymore.
However, that's not a big problem (I can access the logbooks via direct link and see all the others in the same group and switch to them), but the backup thing is.
So, main machine is lx0.mydomain.org and the backup machine is lx1...
Attached are my config files.
I deleted many of the logbook specific entries, since they aren't important and just look like the first one.
Hope anyone can help,
Roland. |
Re: Periodic backup doesn't work .., posted by Roland Gsell on Tue Jun 12 10:38:34 2012
|
The synchronize feature is totally worthless to me.
First of all the automatic backup doesn't work - and nobody seems to know why - and pressing the synchronize button by hand from time to time also doesn't work if the entry is too big:
Error sending local entry: Error transmitting message
So, copying the files manually helps, but for this I don't need a "fancy" synchronize feature. |
Re: author field in reply, posted by Ken Harvey on Tue Jun 19 04:02:43 2012
|
I am a newbie to being the administrator to ELog, but have used it for a while now. We just updated and have the same issue with the reply now. Unfortunatley I am not much of a programmer, yet, still learning. In our config file it has "Preset Name = $long_name", "Preset Author = $long_name", "Preset on reply Author = $long_name". By looking in the Syntax of elogd.cfg section, it seems to be correct, but I am not sure. Can you give me a suggestion on how it should look? Or tell me why it is not working and lead me in the right direction on how to correctly set it up? Thank you for your time. |
Protect Selection page=1, posted by Ocane on Wed Jun 20 14:02:45 2012
|
Hi,
I have several top groups and each has several logbooks.
If I use the global option Protect Selection page=1 and Show top groups = 1, after an user logs in to the top group selection URL, the elog steers away from the top group selection page, and automatically brings him to the logbook selection page of the first top group. Is the elog programmed to exhibit this behavior?
What I would prefer is that, after an user logs in, the elog stays on the top group selection page, sine each user has his preferred destination, not always the logbooks in the first top group. Is there any setting I can use in the config file to do this?
(My users need to access different top groups and logbooks on regular basis).
Thank you and regards. |
Re: author field in reply, posted by Andreas Luedeke on Wed Jun 20 16:16:56 2012
|
Ken Harvey wrote: |
I am a newbie to being the administrator to ELog, but have used it for a while now. We just updated and have the same issue with the reply now. Unfortunatley I am not much of a programmer, yet, still learning. In our config file it has "Preset Name = $long_name", "Preset Author = $long_name", "Preset on reply Author = $long_name". By looking in the Syntax of elogd.cfg section, it seems to be correct, but I am not sure. Can you give me a suggestion on how it should look? Or tell me why it is not working and lead me in the right direction on how to correctly set it up? Thank you for your time. |
A common mistake is to think that "Author" is some kind of keyword: it is not.
You can use any defined attribute, if you want to use "Author" this attribute needs to be defined in the "Attributes=" command line.
Attributes = Author, ...
Then you can use the "Preset" command.
Preset Author = $long_name
Preset on reply Author = $long_name
I've just tested it with 2.9.0-2435 and it works fine.
If the following 4 line minimal logbook configuration does not work for 2.9.1, then please post again:
Attributes = Author
Preset Author = $long_name
Preset on reply Author = $long_name
Locked Attributes = Author
Cheers
Andreas |
Re: author field in reply, posted by Ken Harvey on Thu Jun 21 05:29:59 2012
|
Andreas Luedeke wrote: |
Ken Harvey wrote: |
I am a newbie to being the administrator to ELog, but have used it for a while now. We just updated and have the same issue with the reply now. Unfortunatley I am not much of a programmer, yet, still learning. In our config file it has "Preset Name = $long_name", "Preset Author = $long_name", "Preset on reply Author = $long_name". By looking in the Syntax of elogd.cfg section, it seems to be correct, but I am not sure. Can you give me a suggestion on how it should look? Or tell me why it is not working and lead me in the right direction on how to correctly set it up? Thank you for your time. |
A common mistake is to think that "Author" is some kind of keyword: it is not.
You can use any defined attribute, if you want to use "Author" this attribute needs to be defined in the "Attributes=" command line.
Attributes = Author, ...
Then you can use the "Preset" command.
Preset Author = $long_name
Preset on reply Author = $long_name
I've just tested it with 2.9.0-2435 and it works fine.
If the following 4 line minimal logbook configuration does not work for 2.9.1, then please post again:
Attributes = Author
Preset Author = $long_name
Preset on reply Author = $long_name
Locked Attributes = Author
Cheers
Andreas |
Thanks Andreas,
That cleared up a lot for me. With your information I was able to figure it out. I got rid of the Author and just went with Name, and now it all works good.
Again, thanks for your help,
Ken Harvey |
|