I think you're overthinking this; your bottleneck here is probably going to be the computation-heavy SSL stuff, not the firewall; and why run a single-processor kernel and leave 1-or-more procs idle?
Obviously, testing the setups to get real-world numbers, as long as you're using a real-world workload, is the ultimate arbiter, but I'd be very surprised if a single-processor machine wins out as an SSL terminator. As for the rest of your post, I'm not too sure it really matters; although, IIRC, amd64 better supports W^X protection, as the i386 implementation is a bit of a workaround for an architecture that doesn't support it as well as others. - Bert On Mon, Mar 29, 2010 at 02:10:18PM +0000, trustlevel-...@yahoo.co.uk wrote: > I'm unsure about using i386 or amd64 for an apache/php ssl webserver with > relayd and pf running. I may test both as it shouldn't take too long, but I'd > certainly like to know what people think. This isn't for a system with a large > amount of memory. I imagine I'll need more systems and interfaces before > needing > 4G and I can switch quite easily and also move relayd to it's own > system(s) to scale up. There is external firewalls but they have to be quite > liberal on what they allow. > > > What I'm thinking: > > i386 has more bug searching time under it's belt and probably more active > users. > i386 is said to filter packets more quickly according to Henning, though that > is based on tests a while back and only for a pure firewall system. > Attacks may be more likely to target i386. > i386 has a few more packages, none of which I need to use > the compiler may be configured to optimise apache for i386 > > amd64 cpu stack is reversed and so possibly more secure, so if speed is > comparable i may as well use amd64. > If I ever have a need for lots of memory, amd64 will handle it. > > > What I'd like to know: > > 1./ are security related port upgrades such as php and sql almost as prompt on > amd64 as i386. > > 2./ Would you choose bsd.mp or bsd.sp with amd64 or i386. I realise there's no > substitute for real world tests and config checking, but I would appreciate > any input. > > KeV
