Generic Scheduler - Design Patterns
As I'm slowly getting older, I encounter recurring problems , with perl and general practices being already decades old, one would think that there are well-tested and generic solutions.
One of those thingies is problem of generic hmm, message-scheduler or maybe switch.
You can see this in projects like alamin (sms gateway), varios MTAs, B2B solutions sending invoices, SNMP managent consoles etc..
One way of solving that is by using filesystem - aka spool directory.
Popular solution - shared space aka spool, multiple daemons handling messages - incoming, outgoing, processing...
Two mains choices - spool directory and sql table.
Requirements for spool:
- Ability to drop incoming message into it
- Ability to check emptiness of spool/list waiting msgs
- atomic operation for changing status of msgs ( processing, finished )
| Generic Scheduler - Design Patterns | | 2004.09.17-11:02.00
To: mcetra@navynet.it
Cc: linux-kernel@vger.kernel.org Subject: Re: Production comparison between 2.4.27 and 2.6.8.1 From: rwhron@earthlink.net X-Mailing-List: linux-kernel@vger.kernel.org X-Spam: no; 0.00; comparison:01 i've:01 xfs:01 mount:01 oss:01 sgi:01 dev:01 kernel:01 linux-kernel:01 majordomo:01 vger:01 tux:01 lkml:01 faq:01 size:97 > What can I try to improve performance ? In benchmarks I've done, XFS was helped significantly by the mkfs/mount options in the XFS FAQ. (look for the dbench question). http://oss.sgi.com/projects/xfs/faq.html mkfs -t xfs -l size=32768b -f /dev/device mount -t xfs -o logbufs=8,logbsize=32768 /dev/device /mountpoint| To: mcetra@navynet.it | | 2004.09.08-15:52.00
