| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
67273
|
Mon May 14 22:19:50 2012 |
 | Tim Thiel | tt2005@thieleng.com | Question | Linux | 2.9.0 | Re: HW Requirements to run elog / Performance issues running on ARM |
| 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 |
|
67275
|
Tue May 15 08:35:16 2012 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.9.0 | Re: HW Requirements to run elog / Performance issues running on ARM |
| 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. |
|
69817
|
Wed Jul 31 14:21:21 2024 |
| Stefan Ritt | I cstefan.ritt@psi.ch | Bug report | All | 3.1.5 | Re: HTTP headers should be parsed case insensitive | I changed elog to interprete the content-length header case in-sensitive and committed the change. Can you try again?
Stefan
| André wrote: |
|
I'm trying to run elog behind haproxy, but get the error "Invalid Content-Length in header" on posting.
As stated in the manual, haproxy rewrites all headers to lower case.
elogd parses the content-length header case sensitive which is against the HTTP RFC. This might also apply to other headers that get parsed.
For now I'm using the workaround from the manual:
global
h1-case-adjust content-length Content-Length
h1-case-adjust content-type Content-Type
backend elog
option h1-case-adjust-bogus-server
server elog 127.0.0.1:8080
But as the manual states, this should not be used as a permanent solution.
|
|
|
1056
|
Tue Apr 5 22:45:22 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | | | | Re: HTML-File as attachement | > When I upload a HTML-File as attachement the file is shown as the
> HTML-source and not as the formatted text. Is there a possibility to see the
> HTML-attachements as formatted text like images are shown as images?
I could turn the ASCII display off, but the result is not always what you want.
If you have a HTML file without the <html>, <header> and <body> tags, it's ok.
But if you have these tags in your HTML (and this is the normal case), the
resulting page has these tags twice, once from the ELOG page and once from the
attachment. This confuses some browsers, so the resulting page might look
strange. A solution would be to strip these tags from the attachment, but for
that I would have to interprete the HTML attachment completely, which is too
much work.
So I will turn the ASCII display off in the next release, but be prepared to see
some nonexpected results. |
|
1058
|
Wed Apr 6 14:45:22 2005 |
| Becher | lehmannth@12move.de | | | | Re: HTML-File as attachement | Yesterday I mad a little experiment:
I copied in OpenOffice the content from my HTML file, which was not shown correctly
in ELOG, to a new HTML file, uploaded it in ELOG, and now my file was shown
correctly formatted. The only one problem is that not all lines are shown, in the
last line is written ...1753 more lines... . How can I show all lines? Do I have to
recompile ELOG? |
|
1059
|
Wed Apr 6 14:56:09 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | | | | Re: HTML-File as attachement | > Yesterday I mad a little experiment:
> I copied in OpenOffice the content from my HTML file, which was not shown correctly
> in ELOG, to a new HTML file, uploaded it in ELOG, and now my file was shown
> correctly formatted. The only one problem is that not all lines are shown, in the
> last line is written ...1753 more lines... . How can I show all lines? Do I have to
> recompile ELOG?
The reason for the "...1753 more lines..." is the following: Sometimes people upload
really huge files (10 MB or so). If they are displayed as ASCII attachments, each time
you access the entry you have to DOWNLOAD 10 MB. Sometimes even the browser crashes.
That's why I limited the display of the ASCII attachments to the first 1000 lines. To
see the complete file, just lick on the attachment name.
Concerning the inline display of HTML documents, I'm currently thinking of checking if
there is an <HTML> or <BODY> statement inside the file. If not, it might be just some
HTML fraction in which case it could be shown. If yes, it cannot be shown inline, but
if you click on it's name a new browser windows is opened containing the full document.
Does that sound reasonable to you? |
|
1061
|
Wed Apr 6 21:26:19 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | | | | Re: HTML-File as attachement | Ok, I turned display of HTML attachments completely off in 2.5.8-3. So if one wants to see
it, on has to click on it. Otherwise there is no way to ensure a correct web page, so
people would complain again that the page does not pass the HTML validator if someone
attached an invalid HTML file. |
|
1062
|
Wed Apr 6 23:02:47 2005 |
 | Becher | lehmannth@12move.de | | | | Re: HTML-File as attachement | I think this is reasonable. All the HTML-files which I want insert (created with the software
INCA) are not shown correctly. My testfiles made with OpenOffice are shown correctly. Maybe
you have the time to program an option for the attachement "Show inside/Show in new window or
tab", so that the user can choose, how his HTML file is shown. Similiar to the option "Submit
as HTML text". |
|