I've configured a Timestamp signer to sign with lunasa, however I noticed it is very very slow (3 seconds per timestamp).
Is there anything I can do to speedup the signer?
I think it is so slow because it always open/closes the connection to the DB: is there a way to configure a kind of 'connection pool' ?
Thanks,
Massimiliano
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is the output of the client tool provided with signserver (sleep 50ms) :
INFO got reply after 2736 ms
INFO TImeStampRequest validated
INFO got reply after 2739 ms
INFO TImeStampRequest validated
INFO got reply after 2660 ms
INFO TImeStampRequest validated
INFO got reply after 2658 ms
INFO TImeStampRequest validated
INFO got reply after 2630 ms
INFO TImeStampRequest validated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, I've been able to make one step further: the problem is the 'ARCHIVE=true' that I really need….
Is there a way to make the ARCHIVE operation faster??
Thanks,
Massimiliano
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Then its either your database that is slow or the archiver implementation. The current archiver has some short-comings in that it stores the data in an large XML serializable form in the database. From SignServer 3.2.1 it will be possible to add custom archiver implementations and you could than add another archiver if you want.
Best regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all.
I made some further investigations with AppDynamics.
There is a VERY SLOW operation inside the SignServer code (WorkerSessionBean.java at row 362) that takes more thank 1 second to complete.
Is there any easy way to make it faster?
Noone has ever used the archiving feature?
Regards,
Massimiliano
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In SignServer 3.2.0 and in the pasted code line 362 is the one that starts with "archiveDataService.create(". What that does is to call ArchiveDataService.create() which inserts the data to the database. Do you have the timings for the ArchiveDataService as well? I can not see anything in it there that should take any noticeable time more then the actual database persistence.
Regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Call graph from /signserver/process
Start time: 02:45:20 PM
Snapshot ID: 02c2b829-1430-43b3-ba99-05d3539276f0
java.lang.Thread:run (method time = 0 ms, total time = 609 ms)
HTTPServlet:service:803 (method time = 0 ms, total time = 609 ms)
HTTPServlet:service:710 (method time = 0 ms, total time = 609 ms)
Servlet - GenericProcessServlet:doPost:245 (method time = 0 ms, total time = 609 ms)
Servlet - GenericProcessServlet:processRequest:336 (method time = 0 ms, total time = 609 ms)
EJB - WorkerSessionBean:process:362 (method time = 586 ms, total time = 586 ms)
com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate:commit:87 (method time = 0 ms, total time = 23 ms)
com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction:commit:135 (method time = 0 ms, total time = 23 ms)
com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple:commitAndDisassociate:1389 (method time = 0 ms, total time = 23 ms)
com.arjuna.ats.arjuna.AtomicAction:commit:177 (method time = 0 ms, total time = 23 ms)
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator:end:86 (method time = 0 ms, total time = 23 ms)
com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator:beforeCompletion:247 (method time = 0 ms, total time = 23 ms)
com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple:beforeCompletion:114 (method time = 23 ms, total time = 23 ms)
JDBC(23 ms): [0]
[0]
PREPARED STATEMENT BATCH
insert into ArchiveData (time, type, signerid, archiveid, requestIssuerDN, requestCertSerialnumber, requestIP, archiveData, uniqueId) values (?, ?, ?, ?, ?, ?, ?, ?, ?)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suspect it is the serialization of the data that takes time. As mentioned before, the current archiver uses an XML serialization which in this case means that each byte requires 40 bytes in serialized form. This is an known issue tracked as https://jira.primekey.se/browse/DSS-409 and currently scheduled for SignServer 3.3.1.
Regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all.
I've configured a Timestamp signer to sign with lunasa, however I noticed it is very very slow (3 seconds per timestamp).
Is there anything I can do to speedup the signer?
I think it is so slow because it always open/closes the connection to the DB: is there a way to configure a kind of 'connection pool' ?
Thanks,
Massimiliano
Java Enterprise uses connection pools. I don't know why it is slow for you, for us we can get hundreds of signatures per second.
Cheers,
Tomas
Do you mean I should try installing java_ee instead of simple JDK?
Thanks,
Max-
This is the output of the client tool provided with signserver (sleep 50ms) :
INFO got reply after 2736 ms
INFO TImeStampRequest validated
INFO got reply after 2739 ms
INFO TImeStampRequest validated
INFO got reply after 2660 ms
INFO TImeStampRequest validated
INFO got reply after 2658 ms
INFO TImeStampRequest validated
INFO got reply after 2630 ms
INFO TImeStampRequest validated
If it can be of any help, I'm using JAVA 1.7.0_01 on Windows 2008 R2
Regards,
Massimiliano
Ok, I've been able to make one step further: the problem is the 'ARCHIVE=true' that I really need….
Is there a way to make the ARCHIVE operation faster??
Thanks,
Massimiliano
Then its either your database that is slow or the archiver implementation. The current archiver has some short-comings in that it stores the data in an large XML serializable form in the database. From SignServer 3.2.1 it will be possible to add custom archiver implementations and you could than add another archiver if you want.
Best regards,
Markus
Hi all.
I made some further investigations with AppDynamics.
There is a VERY SLOW operation inside the SignServer code (WorkerSessionBean.java at row 362) that takes more thank 1 second to complete.
Is there any easy way to make it faster?
Noone has ever used the archiving feature?
Regards,
Massimiliano
Forgot to say: the DB insert require just some ms.
What version of SignServer? Can you paste the line, with a few surounding lines so we don't have to search around for something in blind?
As I said, WorkerSessionBean.java line 362.
The code is:
if (res instanceof IArchivableProcessResponse) { final IArchivableProcessResponse arres = (IArchivableProcessResponse) res; if (awc.getProperties().getProperty(SignServerConstants.ARCHIVE, "FALSE").equalsIgnoreCase("TRUE")) { if (arres.getArchiveData() != null) { final String requestIP = (String) requestContext.get(RequestContext.REMOTE_IP); final X509Certificate clientCert = (X509Certificate) requestContext.get( RequestContext.CLIENT_CERTIFICATE); archiveDataService.create( ArchiveDataVO.TYPE_RESPONSE, workerId, arres.getArchiveId(), clientCert, requestIP, arres.getArchiveData()); } else { LOG.error("Error archiving response generated of signer " + workerId + ", archiving is not supported by signer."); } } }In SignServer 3.2.0 and in the pasted code line 362 is the one that starts with "archiveDataService.create(". What that does is to call ArchiveDataService.create() which inserts the data to the database. Do you have the timings for the ArchiveDataService as well? I can not see anything in it there that should take any noticeable time more then the actual database persistence.
Regards,
Markus
Follows everything I have
I suspect it is the serialization of the data that takes time. As mentioned before, the current archiver uses an XML serialization which in this case means that each byte requires 40 bytes in serialized form. This is an known issue tracked as https://jira.primekey.se/browse/DSS-409 and currently scheduled for SignServer 3.3.1.
Regards,
Markus
See my "My contribution to SignServer archivers" post, it can be useful to solve this problem.