I have a prototype working using threads that is marginally acceptable in performance; however, I know that I am losing performance because of the overhead associated with threads::queue and threads::shared.

I am sceptical that an IO-bound multi-processing solution is being limited by the performance of either Thread::Queue or threads::shared. Unless those modules are being used very badly.

By way of demonstrating the basis of my scepticism for your claim, this sends messages back and forth between two threads via two queues alternately. This is the very worst case scenario as every communication requires a context switch, with each thread doing almost nothing between context switches. Ie. This example defeats the purpose of using queues by forcing constant synchronisation between the threads. It would be very hard to use queues in a worse way than this.

#! perl -slw
use strict;
use Time::HiRes qw[ time ];
use threads;
use Thread::Queue;

$|++;

my $Qin = new Thread::Queue;
my $Qout = new Thread::Queue;

my $t1 = async {
    while( my $in = $Qin->dequeue ) {
       $Qout->enqueue( $in + 1 );
    }
};

my $start = time;
$Qin->enqueue( 1 );
while( my $in = $Qout->dequeue ) {
    $Qin->enqueue( $in + 1 );
    printf "\rMessages per second: %.3f",
        $in / ( time() - $start );
}

__END__
[13:29:53.76] c:\test>junk37
Messages per second: 21791.810Terminating on signal SIGINT(2)
Messages per second: 21791.633
[download]

As you can see, the results on my machine is that somewhat over 20,000 messages are exchanged every second, which means unless your web API calls are completing in less than half a millisecond, the queuing is not the source of your perceived performance limitations.

The bottom line is, I believe you are miss attributing the source of your problem with performance.

If you would post your code, I feel certain that I could resolve the issue for you quite quickly. If you don't wish to post proprietary code in public, I'd be willing to take a look in private.