Performance

[Ryan Smith]

In recent months, queue_classic has been deployed to several large scale environments. Needless to say, there have been a few performance concerns. Most of the feedback I have received has been something along the lines of "My workers slow down over time." 

I have been doing some science on queue_classic in order to better understand the performance implications of the system. To be honest, I am not sure that I have found anything of interest. Nevertheless, here are my findings....

Experiment 1 - LISTEN / NOTIFY Test

Environment

Open 2 psql consoles. In the first console, execute `LISTEN chan;`

In the second console, setup an infinite loop that notifies on chan. 

Observe memory / cpu usage using OSX's activity monitor for 0.5 hours.

Results

Not surprisingly, postgresql handled the task without alarm. Memory usage was less than 10MB during the exercise. CPU usage was minimal.

Experiment 2 - LISTEN / NOTIFY Test

Environment

Open 2 irb (ruby 1.9.2) sessions.

require 'queue_classic' in both.

In the first session, I executed: `1_000_000.times { |i| QC.enqueue("TestCollection.append", i) }`

In the second session, I defined TestCollection as such: 

class TestCollection

  @@data = []

  def self.append(i)

    @@data << i

  end 

end

I then started the worker: `QC::Worker.new.start`

Results

This experiment took an hour +/- to complete. 

Postgres Usage

The worker and the producer were using < 10MB of memory and an average of 50% CPU utilization.

Ruby Usage

The worker and the producer were using < 300MB of memory and an average of 10% CPU utilization.

Conclusion

I have no idea. I am going to continue thinking about the system and will check back shortly with any insight I can come across. 

I would appreciate your help in this ventrue. 

Thank you all.

[Daniel Farina]

On Thu, Aug 11, 2011 at 11:13 PM, Ryan Smith <ry...@heroku.com> wrote:
> In recent months, queue_classic has been deployed to several large
> scale environments. Needless to say, there have been a few performance
> concerns. Most of the feedback I have received has been something along the
> lines of "My workers slow down over time."
> I have been doing some science on queue_classic in order to better
> understand the performance implications of the system. To be honest, I am
> not sure that I have found anything of interest. Nevertheless, here are my
> findings....
> Experiment 1 - LISTEN / NOTIFY Test
> Environment
> Open 2 psql consoles. In the first console, execute `LISTEN chan;`
> In the second console, setup an infinite loop that notifies on chan.
> Observe memory / cpu usage using OSX's activity monitor for 0.5 hours.
> Results
> Not surprisingly, postgresql handled the task without alarm. Memory usage
> was less than 10MB during the exercise. CPU usage was minimal.

Hmm. How did you run this experiment, exactly? I suspect if you were
using so little memory that either NOTIFY wasn't spinning fast enough
or you were running identical NOTIFYs in one transaction, which get
folded to exactly one entry. For example, running:

DO $$
BEGIN
LOOP
perform pg_notify('queue_classic', random()::text); END LOOP;
END; $$
;

In a backend will result in much faster accrual of memory usage than
you describe (and certainly this approach could be 'improved' to
occupy more memory faster. Note that this loop will never actually
notify any backends because it runs in a transaction and your only
choice will be to cancel it and all its notifies.

Secondly, when it comes to testing the client, we know that psql
drains notifications because it dumps them all to the terminal and is
done with them. What you may have noticed is that it only does so
when one has done some 'stuff' on the database connection, like
"select 1;". In libpq, the completely statementless version of 'check
for some input' is 'consume input', and it is necessary to call this
at least once to ensure the client buffers the notifies to have a
chance to reproduce this behavior.

--
fdr