ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
182
|
Sat Jan 4 17:55:49 2003 |
| Etienne Van Caillie | etienne.vancaillie@mba.be | Comment | | | Re: logbook db size causing very slow response | > Was wondering if there were any tweaks/suggestions for improving the
> logbooks responsiviness. Our logbook was started 31 July 01. Since that
> time we have went from 1 logbook to 4 logbooks. Logbook 1 having 2651
> entries, logbook 2 having 300 entries, and the last 2 are new logbooks, so
> only a few entries.
>
> When user launches the logbook website, it takes considerable time to bring
> the site up. It seems to be directly related to the number of entries in
> the logbook. If I set up a dummy site with a couple logbooks and only a
> few entries, the logbook is very fast coming up as well as saving entries.
>
> Another thing that seems to slow the site down, is the number of users in
> the elog notification list (those who've subscribed). When you save a log
> entry, it takes around 30sec or longer for it to actually complete the
> save. If I remove the list of users from the notification list and just
> have a few, the save is very fast.
>
>
> Thanks in advance,
>
> Eric
2600 entries is too much for this application as it load the all files
in computer memory
expand the server memory
Are you running on linux or Windows ? I suggest linux (faster)
We are working on the C source to move all data from flat to database like
SQL or mysql
when a parameter flag like 'status' = "OK" for instance
I suggest also to split in several logbook
but this is depend on your 'ELOG' parametrisation and logics
If your data are not 'sensitive' I can check on my linux server
Etienne |
183
|
Sat Jan 4 20:07:20 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Comment | | | Re: logbook db size causing very slow response | > Another thing that seems to slow the site down, is the number of users in
> the elog notification list (those who've subscribed). When you save a log
> entry, it takes around 30sec or longer for it to actually complete the
> save. If I remove the list of users from the notification list and just
> have a few, the save is very fast.
This problem will be fixed in version 2.2.5. Prior to 2.2.5, individual
emails were sent to all recipients. Since each email takes 0.5-1 sec., this
procedure can be very long. From 2.2.5 on, only one email is sent, but to
all recipients. The disadvantage of this method is that the "Mail to:" field
contains the email addresses of all recipients, so each recipient knows the
addresses of the other, which is maybe not always what you want. I put a new
option to discard the "Mail to:" field, but some systems the consider the
mail with a missing "Mail to:" field as spam mail. 2.2.5 will be released in
a couple of days.
> 2600 entries is too much for this application as it load the all files
> in computer memory
> expand the server memory
> Are you running on linux or Windows ? I suggest linux (faster)
> We are working on the C source to move all data from flat to database like
> SQL or mysql
> when a parameter flag like 'status' = "OK" for instance
> I suggest also to split in several logbook
> but this is depend on your 'ELOG' parametrisation and logics
>
> If your data are not 'sensitive' I can check on my linux server
>
> Etienne
It is not correct that all files are loaded into memory. Only the index
resides in memory, the data stays on disk. In my environment, I see no speed
difference between Windows and Linux. Moving to SQL will certainly not speed
up the responsiveness in my opinion. So before working on that, create a SQL
database with your 2600 entries and see how fast you can make queries on
them.
The problem with the slow response is new to me. Other users mentioned no
problem with logbooks with several throusand entries (except for the "find"
command). But I will have a look myself in the next feature and see if I can
make things better.
- Stefan |
231
|
Wed Feb 19 14:48:56 2003 |
| Heiko Scheit | h.scheit@mpi-hd.mpg.de | Comment | | | Re: Participation on development of ELOG | > > We are interested in using your ELOG (which we consider to be a wonderful
> > application) even more. We would like to make a few adaptations in your
> > source code, above all to add some functionality that we are missing.
> >
> > I was wondering if there is a way we could coordinate the development
> > together. For instance, would it be of your interest to receive the code
> > adaptations we do and implement it in your future releases?
>
> Sure, I'm very interested in those and ready to merge it into the main
> development tree.
>
> - Stefan
I think it is very good to include this in elog, but,
since this is also a big security risk (especially if people are
running elogd as root) I would suggest a compile time option to
enable this, like: gcc... -DALLOW_SCRIPT ...
The default should be that it is disabled.
Maybe one should only allow it if the user running elogd is NOT root.
Heiko |
236
|
Tue Feb 25 22:18:57 2003 |
| Aamir Khan | aamir@aamir.uk.com | Comment | | | Security (passwords over web browser) | Stefan - Just to say that this is an excellent piece of work well done.
I have just started an internal company Elog server, couple of
clarifications :
1) is there a way around seeing the password in text when self regestering,
if I turn this option off when the user changes his password will this
password still be seen?
2) I have changed all the files to be owned on my RedHat Server by the
user:group as elog:elog and set and moved the logbooks to another directory
other than in /usr/local/elog namely /home/elog/logbooks, my concern is is
I was to upgrade to a newer version would it be a simple install over the
top? any caveats?
thanks again an absolute dream program.
kind regards Aamir |
239
|
Wed Feb 26 10:34:12 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Comment | | | Re: Security (passwords over web browser) | > Stefan - Just to say that this is an excellent piece of work well done.
Thanks.
> 1) is there a way around seeing the password in text when self
regestering,
> if I turn this option off when the user changes his password will this
> password still be seen?
Where did you see the password? Was it on this logbook or on your own? Did
you use "self register" equal 3 or 2? The password should never be visible
in plain text, so after you submit it (during registration or login), the
page gets immediately redirected since the password is contained in the
URL. After the redirection, it is not visible any more. Now it might happen
that the redirection takes a few seconds, depending on the network speed,
then you see it for this few seconds. But in an intranet installation, this
should not happen.
> 2) I have changed all the files to be owned on my RedHat Server by the
> user:group as elog:elog and set and moved the logbooks to another
directory
> other than in /usr/local/elog namely /home/elog/logbooks, my concern is
is
> I was to upgrade to a newer version would it be a simple install over the
> top? any caveats?
Yes, if you upgrade, the new version will again to into /usr/local/elog
unless you tell "rpm" to relocate the package. Unfortunately I'm not a
specialist with "rpm", but you might figure it out yourself (just try to
reinstall the same version and look where the files go wiht "rpm -ql elog"). |
273
|
Mon Apr 7 23:00:48 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Comment | | | Passwords might have changed for logbook "Forum" | A problem (elog:272) with certain passwords has been fixed in version
2.3.5 of ELOG. This forum runs the updated version, which can cause login
problems. All users with a password length of 3,6,9,12,... characters
cannot login with their old password anymore. They have to click
on "Forgot password?" in the login screen to have the system create a new
password for them and send it to their registered email address. In case
no email address has been registered, one can send me directly an email
(stefan.ritt@psi.ch). After one receives the new password via
email, one can log in again and change the password to the old one, which
then gets registered correctly. I apologize for any inconvenience.
- Stefan |
362
|
Wed Jun 4 10:47:36 2003 |
| Etienne Van Caillie | etienne.vancaillie@mba.be | Comment | | | rhis logbook | I suggest to add an attributes like OS
MOptions OS = linux, windows2000, windowsXP¨, windows2003
to indicate on which version we are speaking |
363
|
Wed Jun 4 11:14:32 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Comment | Other | | Re: rhis logbook | > I suggest to add an attributes like OS
>
> MOptions OS = linux, windows2000, windowsXP¨, windows2003
>
> to indicate on which version we are speaking
Good idea, I added a "ELOG Version" as well. |
|