The simplest thing to do is eliminate the queue. Just say that when you try to create a PDF, it sees if one is being created, and if it is it just retries later. Eventually you get through. Simple, dumb, and in my experience almost always sufficient.

If you want to get fancier, have a simple job table. When you ask for a PDF, it adds a record saying that person X wants PDF Y. A process is sitting there creating PDFs, which are placed in a temporary area for a bit, then cleaned up. At any time through a simple query you can see where someone is in line. If the person doesn't pick it up in time, they lose and have to resubmit the request. (With some cleverness you can do quite a bit with a surprisingly simple job system...)

The next simplest is to modify the job table to allow people to cancel jobs. Again, the default is that work gets done, but people can remove their job from the queue.

After that you can modify it to say that any job that is not updated regularly to say that you're still waiting is considered cancelled. And there you have it.

BTW while you're optimizing this, note that while you might not be able to create 500 PDFs at once, you'll probably be able to create 5 at once faster than 5 sequentially. So introduce some naive parallelism by having 5 workers trying to take jobs. That will improve throughput, and will also keep one person with a large job from blocking everyone else until their job is done.

I wish I could double-++ this!

About the only thing I'd add would be a way to cancel an in-progress job (not simply remove one from the waiting-to-be-processed queue).

Come to think of it, I wish *life* had an "oops, I didn't mean to do *that*" button....

-- WARNING: You are logged into reality as root.

The following may help. Note that this hasn't been tested beyond the sample code given so the handling for data in addition to the ID had not been checked.

use warnings;
use strict;

package Fifo;

sub new {
  my $self = [];
  return bless $self;
}

sub push {
  my $self = shift;
  my $id = shift;
  
  if (@_) {
    push @$self, [$id, \@_];
  } else {
    push @$self, $id;
  }
  return scalar @$self;
}

sub pull {
  my $self = shift;
  return shift @$self;
}

sub remove {
  my $self = shift;
  my $id = shift;
  
  for (reverse 0..$#$self) {
    my $item = $self->[$_];
    my $itemId = ref $item ? $item->[0] : $item;
    splice @$self, $_, 1 if $itemId eq $id
  }
}
  
1;

package main;

my $fifo = Fifo->new;

$fifo->push ('First person');
$fifo->push ('Second person');
$fifo->push ('Third person');

$fifo->remove ('Second person');

print "$_\n" while defined ($_ = $fifo->pull);
[download]

Prints:

First person
Third person
[download]

• Why don't you just buy a faster/bigger server?
• Why don't you try some in-memory caching with your webserver?

Both are great questions.



Why don't you just buy a faster/bigger server?



I have no control over the hardware what so ever. So it's not up to me to get a new server.



Why don't you try some in-memory caching with your webserver?



Good idea but not practical as the PDF is created on the fly depending upon the search done by the user. Also we don't want the information cached anywhere for security purposes.

Good ideas though.


BMaximus