Re: How does POE speed up operation in reality?

DBI is generally not CPU bound on the client side.  Again, it's a case  
where the client spends its time waiting idly, so this may be made non- 
blocking.  A number of components have been written to help you  
execute DBI requests in the background.

A simple user lookup (presumably to authenticate a user) may take on  
the order of a few hundredths of a second, possibly longer if the  
table is large and poorly indexed, you mistakenly prepare() the select  
statement each time, or your mysqld or network are saturated.  None of  
these problems are insurmountable:

Upgrade your mysqld.
Upgrade your network.
Properly index your table.
Shard your database.
....

You seem to be seeking examples where POE isn't necessarily  
appropriate.  I recommend looking for CPU-bound problems, since that's  
where POE doesn't directly help.  Even in the CPU-bound case, a  
subthread or child process can externalize and parallelize the work.   
POE can continue doing non-blocking work in the meantime, and it can  
be notified when the side thread or process is done.

-- 
Rocco Caputo - [email protected]


On May 2, 2009, at 03:03, Roy M. wrote:

> Hi.
>
> On Sat, May 2, 2009 at 2:56 PM, Rocco Caputo <[email protected]>  
> wrote:
>> Incorrect.  A lot of the work of transferring a file is waiting for  
>> the data
>> to arrive.  POE can wait for data to arrive in parallel without  
>> threading.
>>
>> POE::Component::Client::FTP may or may not be programmed to allow  
>> this, but
>> POE can do it.  It's a common misunderstanding to say "POE" when  
>> you mean "a
>> module using POE".  POE's authors have little control over how it's  
>> used.
>>
>
>
> What if I have some blocking operation within a callback, e.g. MySQL
> query in `authenticated` method in POE::Component::Client::FTP ?
>
> I think unless I make it run as parellel, the bottomneck still exist
> as it is single threaded?
>
>
> Thanks.