Le 7/9/13 3:23 PM, Slavomir Kocka a écrit : > Ok, > > Well, we are running inside VM on HDD for server usage (Guess 10000 spins/s), > but I believe, there are not SSD drives. > In fact, we are using JMS to "buffer" writes, and simulate transactional > behaviour (in case user is not added due to any reason, JMS container rolls > back operation, and tries next time) > > As I told we need to add accounts in normal speed. So really, tens of writes > per sec. are just fine, and I believe, hardware is more than sufficient... > Target is like 6000 accounts within few hours. AS this addition is buffered > by JMS, there is no HUGE load... > > Today we will move those LDAP servers to dedicated VM machines (this time > ubuntu), and will see... > I'll post here, if I get some results... > > We will also review our JMS config... > > Just last question for now. Do you have some syntetic tests with some > parallel writes/reads?
No, but as I said, writes are really a bootleneck. We have tested the server with 100 clients reading entries in the server as fast as possible, and the server is capable of delivering around 13 000 entries per second to the 100 clients as a whole (ie, roughly 130/s to each client). If you have some writes at the same time, the performances will just be impacted heavily. As I said, we are working on a better solution, based on a MVCC backend. The biggest advantage of MVCC is that reads can now be processed while a write is being processed. As writes will also be sequential, we will be able to remove many locks all over the server. We are not far from having something that work, we just have a couple of issues with indexes on Attributes accepting multiple values. Most of the tests are passing but two as of today, and we hope to fix them this week. Btw, the read perfs are also better, with an improvement of around 50% If you are interested in testing such a backend as soon as we get the bugs fixed, just let me know, we can provide some guidance. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
