I was curious to see what kind of negative performance effect a large number of accounts has on bitcoind. The results are not pretty. My tests were not particularly scientific, but here's what I've learned.

Methodology

I created 50K accounts in an empty wallet with a small balance. The resulting wallet file is approximately 13MB. Creating accounts takes approximately 0.03 seconds per account.


I then executed a sequence of 10K random transfers between these accounts. These transfers take approximately 0.1 seconds each, on average. Again, this is in an empty wallet, and all of these transfers are internal to the wallet (no transactions are actually sent to the bitcoin network).


Next, I executed the following sequence of external transfers (i.e. actual network transactions), on each transfer sending funds from a random account to another random account.

• send 100 transfers
• send 500 transfers
• send 10 transfers
• send 50 transfers

Results

After each step above, I recorded the size of the wallet file, the time it took for bitcoind to start up (i.e. initialize by reading the wallet and other database files), and the time it took to actually execute the transfers. Here is the summary of my results:


The results are surprisingly bad. File wallet.dat ballooned to 85MB (!) after only 660 transfers. I have no idea what could possibly take up so much space, but I'll try to inspect the file using BerkeleyDB tools and will add to this post if I gain some insight.

The really bad news is that transfers end up taking several seconds each, on average. As expected the duration increases as the number of transactions in the wallet goes up.

I inspected the bitcoind logs and it appears that most of the delay is because wallet.dat is flushed to disk after each transfer.

Other Observations
I was able to severely corrupt the wallet file by terminating bitcoind process. I did not lose any keys, but the account balance information was corrupted. In essence I was able to lose track of what the correct balance is in each account without any effort at all.

Conclusions
Others have said, both here in this forum and elsewhere: don't use Accounts in a server environment. More importantly, bitcoind itself does not seem to be suitable for any type of system where a large number of transactions is expected to occur. A different solution is needed. There is only one commercial, enterprise-level solution I am aware of (https://bitsofproof.com/?page_id=323).

Additionally, BerkeleyDB (which bitcoind uses to store account, address, and all other data) does not appear to be a sufficiently robust solution if you really care about account balances. I do not know enough about it to comment but it is possible that it would perform better if it were implemented differently. For example, I would like to see an option for transactional replication of all wallet data to a separate disk or server. This would at least ensure an internally-consistent copy of the wallet database exists. As things stand now, if the wallet file gets corrupted, everything is lost, and I was able to corrupt the file very easily (and unintentionally).

I am contemplating starting an open source alternative to the built-in bitcoind account management infrastructure. It would still use bitcoind for interfacing with the network, but would use a more robust database setup to store and handle account data. More about this in a separate post.

Account Weaknesses
Since the accounts feature was introduced, several services have used it to keep track of customer's bitcoin balances and have had the following problems:

Wallet backups are an issue; if you rely on a good backup of wallet.dat then a backup must be done every time an address is associated with an account and every time the 'move' command is used.
The accounts code does not scale up to thousands of accounts with tens of thousands of transactions, because by-account (and by-account-by-time) indices are not implemented. So many operations (like computing an account balance) require accessing every wallet transaction.
Most applications already have a customer database, implemented with MySQL or some other relational database technology. It is awkward at best to keep the bitcoin-maintained Berkely DB wallet database and the application database backed up and synchronized at all times.

Before you can query arbitrary transactions, add the txindex=1 entry to your config file, and then reindex Bitcoind.this is standard.

As usual there are circumstances you should be aware of, if its not fully synced it will fail. If you recorded an incoming payment I'd at zero confirmations then you have malleability to worry about.

There is an issue with the gpu mining pool....

why are you so angry? because you have your opinion, not enough?

now which will be the opinion of many, so break the pools

If that's the case, please move along.  Thank you for your input,  however, the pro's of this algorithm outweigh the con's such as difficulty assembling a pool.  You can't blame the "coin" for pools getting dos'd...that's just absurd.

Unfortunately, we do not need more exchanges, but more pool

Yes. I mined several CDC from your pool and payed and over 200 confirmations on my wallet. But many many transactions become 0 confirm.

Example: First then all transactions was confimations over 200.

"Status: 0/unconfirmed
Date: 4/6/2014 16:26
From: unknown
To: BsM96vCgSNTjmK54zT8U5Pfjd3eWP1gWzk (own address)
Credit: 1032.818347 CDC
Net amount: +1032.818347 CDC
Transaction ID: a922832860298121313b8a5aff7d0473f9b291410d7b638097fc37fa943142c7
"
and
"Status: 0/unconfirmed
Date: 4/6/2014 17:00
From: unknown
To: BsM96vCgSNTjmK54zT8U5Pfjd3eWP1gWzk (own address)
Credit: 1112.601872 CDC
Net amount: +1112.601872 CDC
Transaction ID: bfe8f622303659aacd73eff8b02c03cbc46730eee5ea347bc0426b3dabc5d83e"

and

"Status: 0/unconfirmed
Date: 4/6/2014 17:53
From: unknown
To: BsM96vCgSNTjmK54zT8U5Pfjd3eWP1gWzk (own address)
Credit: 1013.311012 CDC
Net amount: +1013.311012 CDC
Transaction ID: 712910e38f600836737deb094bd44950b9004e95502a3f90c04ef85be3cd8fc5
"

Where is my coins? and some remain coins on your pool when classic interface (now you have new pool interface)