> When I create a new logbook (I used an existing one as a template) elog  
> does not works anymore...  

Fixed in CVS.

> 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

> 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

> 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.

In Version 2.2.5, the responsiviness to large (>1000 entries) logbooks has 
been improved dramatically. If no filtering is applied, a page from the 
logbook listing should be displayed with a response time independent of the 
logbook size (I tried 8000 entries). Only when a filter or sort option is 
applied, all entries have to be searched which takes ~5sec for 8000 entries 
on a 1.2 GHz Windows XP Laptop, which is the same speed as before.

> 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.

Another trick for large logbooks is to divide them into a logbook with 
recent entries and one with old entries (archive), like I did now in this 
forum. One can enable the "copy to" command for the administrator, who then 
can copy regularly old entries to the archive, keeping the recent logkook 
reasonable small with a good responsiviness. If one wants to search then the 
old messages, one can still go to the archive, but then the search command 
takes longer.

> 1. shellonsubmit command : give the possibility to execute external 
> program from elog by sending specific parameter (user/logbook/message ID)
> 
> 2. elog log file in xml format : give a better view on what happens with 
> users see attachments easy to push the files to excel or sql database.

I'm happy to include these functions in the source code, please send them 
to me.

> 3. synchronisation to mySql or SQL server through perl routine and the 
> shellonsubmit command
> this will push any new/edit/delete command in sql server so we keep a 
> full historic off all transaction in ELOG

Can you please put this perl routine into the "Contributions" section

> 4. sms gateway : from elog entry we send sms message throught internet 
> gateway (perl routine)

Same as above.

> other projet : 
> we use a logbook from our external phone call
> 
> from our telephone connected to RS232 and/or TAPI interface we keep the 
> phone number and try to find the name from sql server : if found 
> we want to push an automatic entry in elog and fill specific field like 
> name/contact/last phone call....
> 
> I will ask to Stephan Ritt what's the best way to include our routine in 
> his standard source ?

As I said, put the perl programs into the "Contributions" logbook, send the 
C source code modifications to me.

> could we create a specific logbook for the wishlist
> in elog/contribution may be some parameters for the actual status of the 
> project ? 

Good idea, will do so.

Tomas send you by mail the source files and documentation in English



> > 1. shellonsubmit command : give the possibility to execute external 
> > program from elog by sending specific parameter (user/logbook/message ID)
> > 
> > 2. elog log file in xml format : give a better view on what happens with 
> > users see attachments easy to push the files to excel or sql database.
> 
> I'm happy to include these functions in the source code, please send them 
> to me.
> 
> > 3. synchronisation to mySql or SQL server through perl routine and the 
> > shellonsubmit command
> > this will push any new/edit/delete command in sql server so we keep a 
> > full historic off all transaction in ELOG
> 
> Can you please put this perl routine into the "Contributions" section
> 
> > 4. sms gateway : from elog entry we send sms message throught internet 
> > gateway (perl routine)
> 
> Same as above.
> 
> > other projet : 
> > we use a logbook from our external phone call
> > 
> > from our telephone connected to RS232 and/or TAPI interface we keep the 
> > phone number and try to find the name from sql server : if found 
> > we want to push an automatic entry in elog and fill specific field like 
> > name/contact/last phone call....
> > 
> > I will ask to Stephan Ritt what's the best way to include our routine in 
> > his standard source ?
> 
> As I said, put the perl programs into the "Contributions" logbook, send 
the 
> C source code modifications to me.
> 
> > could we create a specific logbook for the wishlist
> > in elog/contribution may be some parameters for the actual status of the 
> > project ? 
> 
> Good idea, will do so.