> I can accept faster in certain cases but if you say HUGELY faster, I
would like to see some numbers.
Ok, first a specific case that actually came up at my work in the last
week.....
We've got a middleware messaging application we developed we'll call a
'republisher'. it recieves a stream of 'event' messages from a upstream
server, and forwards them to a number of downstream servers that have
registered ('subscribed') with it. it queues for each downstream
subscriber so if they are down, it will hold event messages for it. not
all servers want all 'topics', so we only send each server the specific
event types its interested in. it writes the incoming event stream to
a number of subscriber queue files as well as a series of journal files
to track all this state. there is a queue for each incoming 'topic', its
entries aren't cleared til the last subscriber on that topic has
confirmed delivery.
{before someone screams my-favorite-MQ-server, let me just say, we HAD a
commercial messaging system doing this, and our production operations
staff is fed up with realtime problems that involve multinational vendor
finger pointing, so we have developed our own to replace it}
On a typical dual xeon linux server running CentOS 4.4, with a simple
direct connect disk, this republisher can easily handle 1000
messages/second using simple write(). However, if this process is
busy humming away under the production workload of 60-80 messages/sec,
and the power is pulled or the server crashes (this happened exactly
once so far at a Thailand manufacturing facility, due to operator
error), it lost 2000+ manufacturing events that the downstream servers
couldn't easily recover, this was data in Linux's disk cache that hadn't
yet been commited to disk. So, the obvious solution is to call fsync()
on the various files after each 'event' has been processed, to insure
its an atomic operation.
However, if this republisher does an fsync() after each event, it slows
to like 50/second on a direct connect disk. If its run on a similar
server with RAID controller that has battery-protected writeback cache
enabled, it can easily do 700-800/second. We need 100+/second and
prefer 200/second to have margins for catchup after data interruptions.
now, everything I've described above is a rather unusual application...
so let me present a far more common scenarios...
Relational DB Management Servers, like Oracle, or PostgreSQL. when
the RDBMS does a 'commit' at transaction END;, the server HAS to fsync
its buffers to disk to maintain data integrity. With a writeback
cache disk controller, the controller can acknowlege the writes as soon
as the data is in its cache, then it can write that data to disk at its
leisure. With software RAID, the server has to wait until ALL
drives of the RAID slice have seeked, and completed the physical writes
to the disk. In a write intensive database, where most of the read
data is cached to memory, this is a HUGE performance hit.