• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Performance of ScheduledExecutor?

 
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All,

I am trying to write a simple message broker that can handle in-time and delayed requests.
I wanted to use Executors.newSingleThreadExecutor() combined with a Callables.

What I found is that performance degrades significantly if I use just in-time requests.

Request:


Broker:



TestCode:


My test includes 10 threads constantly pumping requests in the broker and timer that puts delayed message every 200 millsec. The throughput is:
Time: 5 sec
# of delayed messages: 24
# of messages: 356732
Av time: 0.1366528749551489

If I modify the broker to use 2 executors for in-time and delayed requests, the performance is significantly better:


Output:

Time: 5 sec
# of delayed messages: 24
# of messages: 434754
Av time: 0.11181648599102487

Any idea why 2 threaded app with 2 queues that have to be linked is faster than single threaded with one priority queue?
Any way to optimize?


 
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yaroslav,

In the implementation that has two queues, you are processing the messages in parallel (assuming you have multiple processors). Even though in the first implementation you are using a priority queue (which should help process the messages more efficiently), you're still processing the messages serially. Each message being added to the queue also has the overhead of calculating its priority (albeit that is small), and you are probably resizing the underlying array more frequently since the messages may be queuing up faster than you can process them.

Jeff
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic