🚀 go-pugleaf

Java doesn't give you that kind of low-level access.

How exactly do you plan to use the extra CPU time?  Surely if your other
threads are busy enough they will consume all available CPU.

-- 
Check out our latest white papers at
http://www.datadevelopment.com/papers/index.html

BladeNET Scores With Borland Enterprise Tools
Team Development with JBuilder and Borland Enterprise Server

Dolphin Data Development Ltd.
http://www.datadevelopment.com/

"Oliver Young" <no@spam.please> wrote in message
news:3f38e1a6$1@newsgroups.borland.com...
>
>     I'm using threads in my app, but I'd like to use them more efficient
> then at the present. How can I get info about CPU usage and then start
more
> threads if CPU usage is at low level? Is there a better way?
>
>

> How exactly do you plan to use the extra CPU time?
I'm trying to send as much as it is possible e-mails per minute. I'd like to
start more threads if there is a lot of free CPU time. I belive number of
started threads is dependant of CPU power. Am I wrong?

> Surely if your other threads are busy enough they will
> consume all available CPU.
Yes, but I was thinking that I should start 5 threads on P II 450 MHz, and
15 threads on P III 1,0 GHz, and 30 threads on P4 2,4 GHz. Am I wrong?

Oliver Young wrote:

> 
> > How exactly do you plan to use the extra CPU time?
> I'm trying to send as much as it is possible e-mails per minute. I'd
> like to start more threads if there is a lot of free CPU time. I
> belive number of started threads is dependant of CPU power. Am I
> wrong?

Quite possibly; the optimum number of worker threads in such a system
will also be affected by contention for shared resources between
threads (i.e. how much time threads spend waiting for resources to
become available) and, in this case, the network.

How are these e-mails being sent? Are you performing mx lookups, or
just fowarding to an SMTP server? In the first case it makes some sense
to have multiple threads processing jobs, although the network and the
machine will still have an affect on how many it's worth having. In the
second case, everything's being pushed to a single socket anyway, so
network access (at least) will have to be single-threaded.


> > Surely if your other threads are busy enough they will
> > consume all available CPU.
> Yes, but I was thinking that I should start 5 threads on P II 450
> MHz, and 15 threads on P III 1,0 GHz, and 30 threads on P4 2,4 GHz.
> Am I wrong?

Depends what they're doing, whether they're all doing it at the same
time, etc etc.

There are no hard and fast numbers in concurrency requirements, even
for a given machine - it depends upon work load as well.

If you describe a bit more about your architecure (provided this isn't
spam software :) I'll try and make some more concrete reccomendations.

> How are these e-mails being sent? Are you performing mx lookups, or
What are mx lookups?

> just fowarding to an SMTP server?
Yes, but first they are digitally signed and/or encrypted. It is SMIME.

> although the network and the
> machine will still have an affect on how many it's worth having.
Yes, I've tested it on different PC configurations and faster PCs send more
mails per minute.

> In the
> second case, everything's being pushed to a single socket anyway, so
> network access (at least) will have to be single-threaded.
I'm using Bouncy Castle libraries. I'm not dealing with network at all.

> There are no hard and fast numbers in concurrency requirements, even
> for a given machine - it depends upon work load as well.
Can I start high fixed number (i.e. 30) of threads on any machine? Will that
(high number of threads) slow down slow machines?

> If you describe a bit more about your architecure (provided this isn't
> spam software :) I'll try and make some more concrete reccomendations.
No, it is not spam software. :) My mail app will send digitally signed
(and/or encrypted) invoices to the customers (companies).

Thank you.

"Oliver Young" <no@spam.please> writes:

> What are mx lookups?

DNS lookups for mail exchange (MX) records for a domain. usually you
just deliver mail to a local SMTP server's spooling and let it look it
up for you later. The alternative is to find a MX for each recipient's
domain and deliver to the local users directly.

Oliver Young wrote:

> > just fowarding to an SMTP server?
> Yes, but first they are digitally signed and/or encrypted. It is
> SMIME.

Which may well benefit from some paralell processing....

> > In the
> > second case, everything's being pushed to a single socket anyway, so
> > network access (at least) will have to be single-threaded.
> I'm using Bouncy Castle libraries. I'm not dealing with network at
> all.

AFAICS, they just supply javax.mail providers for SMIME, so the network
access will be provided by Java Mail transport?

I think in this case the benefits of threading are dubious; each thread
will have the lengthy task of establishing a connection to the server,
and then sending the mail, whereas a single transport could pluck
processed messages from a queue and manage the connection
appropriately. Once they get to the SMTP server they'll (more than
likely) all be going in the same queue anyway.

> > There are no hard and fast numbers in concurrency requirements, even
> > for a given machine - it depends upon work load as well.
> Can I start high fixed number (i.e. 30) of threads on any machine?
> Will that (high number of threads) slow down slow machines?

Not significantly  - you need 100's or 1000's before the context
switching between threads starts to cause problems.

I see a number of possibilities: 

 - Thread per task: 
   Messages are submitted to the system and placed in a queue. A
seperate thread takes jobs from the queue and performs the S/MIME
encryption on the them, and then places them in another queue (or the
same one with some sort of status indicator). A final thread then pulls
encrypted messages from this queue and pushes them through the
transport.

 - Thread per job 
   Messages are submitted to the system, into a queue. A thread grabs
them from the queue and performs both the encryption and network access
on them.

 - Mixture 
   Many threads available for (say) encryption. Single thread
performing (say) network access.


Ideally you want an archtiecture than can support all three of these
modes and be changed at runtime either due to configuration changes or
to load managing policy. A decent thread pool implementation will help
with this, and other aspects of thread management. You will also
benefit from having a configurable queue that can change it's
prioritizing basis (Least Recently Submitted, Highest Priority etc.).