Hi Martin, Thank you very much for your comments. Sorry for delayed answer: was traveling.
Martin Bartosch wrote: > IMO having multiple database connections should be no problem for a > modern database system. When forking a process, the kernel will > normally apply a copy-on-write policy on the variable data. The > program code should not be physically duplicated by a fork, I'd > expect the kernel to share the code between forked instances. So even > if you see multiple processes eating up 100 MB each, I'd expect a > real physical memory usage of much less. Please correct me, but modern behavior which you describe here is called threading technology. DB should be compiled with threading support enabled to achieve this. Also perhaps we need threaded perl to match treading functionality from the DBI/DBD side? We should at least stress this in docs. > With the current architecture in OpenXPKI we are limited to the > schemes that Net::Server offers. The preforking personality might be > usable for us, but the server architecture would have to be modified > somewhat to allow multiple client connection in one server process. > The main reason is the global CTX object which holds many resources > necessary for the daemon to work properly, including database handles > etc. > This can currently not easily be shared between concurring client > sessions living in the same server process. The fork() call > effectively isolates concurrent server processes. > Addressing this issue will be a major effort which personally I'd > like to address after the first release version. I agree that we > should have a look at this and optimize the server process. We have many servers (most probably running on the same host): 1) Apache 2) OX 3) DB 4) LDAP for CRL 5) LDAP for Certs 6) LDAP for Auth Each could either fork or (alternatively) thread, for each new user/request. You say that OX is hard to promote for support of threading. But all the rest servers can be. (Even sqlite has optional threading support.) Today we can adopt threading policy for all servers (with exception of OX). BTW, Net::Server has announced that threaded-capable personality is expected in the next version. > Question: do you really face perfomance problems in your environment? > In our project we are deploying OpenXPKI in a large scale environment > but we don't expect high load on the server. The main reason is that > the typical user will only access the server process about once a > year to obtain a new certificate, which should scale nicely even with > thousands of users. Agreed. But for me it would be a novelty if OX project declares that only 2-3 simultaneous users are allowed. All these worries started with the "DEBUG=1" problem. And I suspect that this could be due to too loose treating of resources. Because hanging of the OX server during tests is a crying sign about something absolutely impossible which is present in the OX code philosophy. Another idea presently under investigation here is a buggy DBD-SQLite driver: http://rt.cpan.org/Public/Dist/Display.html?Name=DBD-SQLite What exact versions of SQLite and of DBD-SQLite do you use at the testing host? All the best, Sergei ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
