Michael,
Michael Bell wrote:
It would be really interesting for me to know how fast create_pin is.
Could you run the batchprocessor only with one step for each function
and then check the speed for the single funtions? This would allow us to
find the functions which consume the most time and per
hi Chris,
Chris Covell wrote:
OK, yes, I can do all of this. If I have the use Apache::Leak commented
out then the single bp to create a pin is successful. If I include the
use Apache::Leak, then I get lots of errors in the error log and the bp
fails saying that there is already a PIN (!).
This
Michael,
Michael Bell wrote:
I added Apache::Leak to bpDoFunction. It is deactivated by default
but you can use it for searching memory leaks.
OK, I have now istalled mod_perl which contains Apache::Leak and can use
openca_start successfully calling the module!
The debugging is a little bit tric
Hi Chris,
OK, I have upgraded to Perl 5.8.5, built from sources, and upgraded to
the OpenCA CVS latest (the top Change in the CHANGES file is: "no longer
create RDNs...".
But my 3000 batch run still takes close to 3 hours. My memory is still
running at 99%.
The leakage of create_pin is on Perl
Michael,
perhaps a small notice for all who perform performance tests. OpenCA
heavily use Perl's eval. The problem is that eval had several memory
leaks. Perl 5.8.5 reports in it's CHANGES area several bugfixes related
to eval.
OK, I have upgraded to Perl 5.8.5, built from sources, and upgraded
Michael,
Michael Bell wrote:
100 batch2 minutes 11 seconds
1000 batch33 minutes 22 seconds
3000 batch3 hours 30 minutes 43 seconds
I have re-tested using the bpDoStep command you sent, and got the following:
3000 batch 2 hours 52 minutes
Obviously we are going in the right directio
Hi guys,
perhaps a small notice for all who perform performance tests. OpenCA
heavily use Perl's eval. The problem is that eval had several memory
leaks. Perl 5.8.5 reports in it's CHANGES area several bugfixes related
to eval.
I added Apache::Leak to bpDoFunction. It is deactivated by default
Hi Chris,
As the batch size gets bigger, the time to complete the batch increases
in a non linear mannor. some examples are:
100 batch2 minutes 11 seconds
1000 batch33 minutes 22 seconds
3000 batch3 hours 30 minutes 43 seconds
To make it short - there is big memory leak :(
It looks li
Chris Covell wrote:
So if you have some time then you can start of course a small project to
fix it :) I will have some time in the next week. So perhaps I can have a
look at this stuff. It should be some kind of copy and paste from logging
or db stuff.
I am much happier you doing it, if you have t
Michael,
On Thursday 17 June 2004 14:45, [EMAIL PROTECTED] wrote:
> there is an area "export/import commits" which do the serial handling. I
> planned to replace the simple textfile by a dbm-file with a btree which
> should be much faster (log n instead of n per access) but I had no time
> until no
Hi Chris,
there is an area "export/import commits" which do the serial handling. I
planned to replace the simple textfile by a dbm-file with a btree which
should be much faster (log n instead of n per access) but I had no time
until now. The implementation should be really easy because we only nee
Chris Covell wrote:
I have edited the 3_VALID_CERTIFICATE.log file so that it contains 1000 -
1 (this is so that only the first 1000 certs are exported). After 20
minutes of starting the process I can see all of the certificates to be
exported apear on the client screen. After a futher 15 m
12 matches
Mail list logo
