Looking for GnuPG-compatible library for server application
Werner Koch
wk at gnupg.org
Mon Oct 22 16:50:03 CEST 2012
On Sat, 20 Oct 2012 13:35, bernd at wauland.de said:
> Am I correct that each server thread requires its own GPGME/GnuPG
> instance? If that is the case, it would be nice if instances can be
> pooled as threads come and go frequently.
As of now each gpgme_ctx_t context object uses its own instance of an
engine (e.g. a gpg process). Thus you can setup your own CPU mapping by
using one context per CPU. There is however only one gpg-agent running;
if you handle only short messages, gpg-agent will be bottleneck, because
it is not multi-threaded but serializes all requests from all running
gpg processes. It should be possible to change the system so that it
works with several gpg-agents and may this way distribute the workload
onto several CPUs.
Pooling at the gpgme level can be done by the application. Due to the 1-to-1
relation between a context object and an engine, the caller may put a
context object into a pool (instead of releasing it) and later pick it
up from another thread.
> environment where there are some 20'000 *private* keys (and counting).
> From our experience gpg2 does not scale well with increasing number of
> private keys (although I have to admit that the project uses a very
That depends a bit on how you use it. If you do a key listing for each
operation, this might be a problem: Neither gpg, nor gpg-agent cache the
check for the private key file. 20000 private keys are not a very
common usage pattern.
Given that the private key check is is nothing more than an access(3)
with some IPC glue code; I doubt that the number of private keys is
actually the problem. The actual problem is the access to public key,
which still requires a linear search and parsing of the entire keyring.
We can do much faster here but the code is not yet complete (no real
need). Eventually we may add a DB backend to access the keys; the code
is well layered and can thus easily extended.
> I appriciate your offer to help. I will describe the problem, financial
> issues and timetables in a private email. I have to travel a lot the
> next five days (including meetings), so I am not sure if I can send that
> email before the next weekend. Hope you don't mind.
No problem. You may also phone me during office hours
<http://g10code.com>.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel
mailing list