OK. NO TCO OR ROI HERE. WE LIED.
Posted on December 22nd, 2006 by Peter | Permalink

Today, at 11:22AM local time we recorded the 10.000th ORF order. That’s the best Christmas present I can imagine. Thank you for putting your trust in us.

We are leaving now for a Christmas party and I will be back in January only, so I wish you Happy Holidays! See you in 2007.

Posted on December 21st, 2006 by Peter | Permalink

15 orders left till the 10,000th ORF share-it! order.

Amazing. I mean, wow. When we started developing ORF Standard Edition back in 2002 (and selling that time for $25), we did not even dream of ORF growing into a software that filters more than 300.000.000 emails daily and protects ten thousands of mailboxes, in 86 countries all around the world, used by one-person businesses and 50,000+ employee giants and even ISPs. I just do not know what to say. With a little luck, we will record the 10,000th order tomorrow and even though this number has virtually nothing to do with the actual number of licenses sold, this is a great feeling, great responsibility and I still do not know what to say :)

As of writing this, an SMA order from Belgium and another from Benin was recorded and also an ORF EE order came in from Italy, so actually there are only 12 left. Edit: 1 left and champagne is cooling. Anyone, please? And… 5 digits! :)
Wow!

By the way, if you are the 10.000th, you will be fully refunded for your order :)

Posted on December 7th, 2006 by Peter | Permalink

ORF PowerLog preprocessing works with large amounts of unsorted data and does this on “idle” priority (that means, PowerLog preprocessing will run only if your CPUs has nothing better to do). It is not entirely surprising that it is slow, but if your server deals with 1.000.000 emails a day, your daily PowerLog files are 500Mb large and preprocessing of a single PowerLog file takes some 19 hours, I guess you do not find solace in this. Neither did we, so optimizations were made and now ORF processes the 500Mb and 1.000.000 emails PowerLog .OPG file about 75 times faster, in about 15 minutes instead of 19 hours (measured on our test system). The improved preprocessing will be available in the next version.

Posted on December 7th, 2006 by gkarakas | Permalink

You might have experienced a 30 minutes downtime of our web site yesterday, the story follows.

While doing some software maintenance on our colocation server using RDP I took a look at the raid array just to realise that one of the disks was failed. And it was failed for two weeks already. It is a 3ware raid card, and of course it has a feature that alerts you via email if anything goes wrong – I just forgot to set it up when installed the server.

So I grabbed an identical hard disk – we did have some spare -, scheduled a visit at the colocation site at 22:00 CET, went in, replaced the hard drive, went home. The time I spend there was about 30 minutes, which could has been shorter if I can go to the server but it is not possible. I can only go to the visitor room and the technical staff brings the server there – no matter if it has hot-swappable disks.

The current config is RAID5, but I am worried about the possible data loss which can occur if 1. two disks fail at the same time, or 2. one other disk fails during array rebuild. The first option is quite possible, given that usually the disks that are built in a server are manufactured together, with almost identical serial numbers. So in the future we will opt for RAID 6, which seems to be a good choice. The cost of a gigabyte is ever decreasing, and there are 500G or even 750G drives already – one can easily put a number of terabytes into a server, which seemed unreachable even a few years ago.

After restarting the server, the actual rebuild took about 6 hours to complete. I had to fight some other problems as well – one was that the NNTP server did not start, required some indexing. This is a known problem – at least for us-, that thing usually fails about once a month.