Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

OpenBSD or FreeBSD for a Perl web app Production platform?

by Anonymous Monk
on Sep 21, 2006 at 12:36 UTC ( #574115=perlmeditation: print w/replies, xml ) Need Help??

I have narrowed my choice for a *nix Production platform for Perl web apps to OpenBSD and FreeBSD.

Please help me choose by sharing your thoughts and experiences on OpenBSD and/or FreeBSD as a production platform for Perl (especially mod_perl) web applications, please!

I'm especially interested in your thoughts and experiences regarding security, ability to scale up to handling high volumes of web traffic, and ease/dificulty of system admin. of OpenBSD and FreeBSD Production servers.

And how do you like doing development on these platforms (if you do Perl development on them)?

I (and I'm sure many other Monks) would very much like to know how these two operating systems compare in these vital regards for Production servers.

Thank you very, very much my fellow Monks!

  • Comment on OpenBSD or FreeBSD for a Perl web app Production platform?

Replies are listed 'Best First'.
Re: OpenBSD or FreeBSD for a Perl web app Production platform?
by include (Novice) on Sep 21, 2006 at 13:12 UTC
    Well, I have more than 6 years in implementing almost everything under FreeBSD. Right now I am working in a Portuguese Interprise where our programming language of choice is Perl and as I said, almost all projects are running under FreeBSD. It is Fast, it is secure and reliable. FreeBSD with it's Ports collection with over 14000 applications ready to install, is one of the Unix based Operating System with more Perl modules ported thanks to many maintainers as Tobez. You have also other technologies as Jails to segment your project in development and production areas in a secure and isolated mode. Finaly, FreeBSD is very well documentated as you can see here, and our comunity is very nice to join in. Well, is not the best operating system on hearth, but is there one ? Regards and good luck Francisco
      :) runs FreeBSD
Re: OpenBSD or FreeBSD for a Perl web app Production platform?
by samizdat (Vicar) on Sep 21, 2006 at 18:52 UTC
    It is well known around here that I'm a FreeBSD bigot^H^H^H^H^Haficionado. I've also built a web services company on the strength of FreeBSD. In a nutshell, FreeBSD works, works well, and is constantly being updated.

    As idsfa noted, there are times when it's not the leader in one area or another, but I can say, from 9 years of experience, including knowing quite a few of the developers personally, that FreeBSD is a really rocking choice for any sort of server application. I don't think there's another OS that handles single-processor task loading and switching as well on this planet, and that's what 99% of us run for our servers. I have heard that Solaris is still ahead in multiprocessing, but it is deficient in many other areas including ported utilities.

    My experience is that OpenBSD doesn't have enough of a team to do more than concentrate on a few areas (OpenSSH and pf come to mind as recent examples). They do very well in those areas they tackle, and we all benefit from their work, but the OS as a whole is inconsistently improved.

    The various Linux derivatives have one big advantage, and that's commercial support, but that's only an advantage if you care about desktop apps. My servers don't care about the latest FLASH player or game video driver. ;-) They are at a distinct disadvantage when it comes to heavily loaded Internet servers. Even with the latest round of fixes they've done based on the Coverity reports, there are still numerous design flaws and tradeoffs in their scheduling and virtual memory subsystems. Unless you are adamant about quotas and journaling filesystems, FreeBSD is a better choice than any other system.

    It's also very easy to tune. It is important that a complex web system reside on a performance-tuned system, and tuning FreeBSD, MySQL and Apache is a science that's really useful to learn.

    Finally, FreeBSD mostly stays true to the original BSD 4.4/SunOS 4.1 syntax, directory conventions, and utility parameters. Where they don't, it's flat-out better. The new bootup rc strategies are coming together very nicely, and they're being consistently implemented. Likewise the sysctl tuning variables are very easy to use although the documentation does not keep up well enough.

    As for mod_perl, with the ports collection, it "just works". I have mod_perl set up with HTML::Embperl and Apache, and I'm just sitting here sipping cream and meowing happily. :D

    Don Wilde
    "There's more than one level to any answer."
      Wow. That's impressive. Thanks for sharing that! Especially the specifics of your FreeBSD setup. It helps in deciding what to try first.

      You mentioned heavily loaded servers...are you talking about the number and type of services running on them, or how heavy the traffic is? Or maybe their load averages?

      Your server setup sounds sweet! How much of an onslaught are your FreeBSD servers able to stand up to (might need to mention hardware specs of the server to make it meaningful, I guess)? By onslaught, I'm thinking of something like getting slammed with a "Slashdotting" or digg-type peak of server request all at once.

      Thanks again! FreeBSD sure sounds n--i--c--e to my geeky heart...

        Actually, none of it's that impressive. That's the point. Properly tuned FreeBSD servers with spawning daemon services (such as Apache) are very capable. We separate out the MySQL and mail systems to dedicated machines (we do a lot of HTML e-mailing), and the MySQL is replicated with failover across the Internet. Likewise, the web subsystems are duplicated in several locations. We have homebrewed dynamic DNS management, which serves us well except for IE users whose crappy browsers don't obey no-cache pragmas.

        What do they do well? Everything. We've had DDoS attacks, we've had load spikes, and we've had packet drops from upstream. FreeBSD has served well, with the only problems coming from admin errors, like leaving an anonymous FTP machine NFS'd to a live webserver or typing 'shutdown -h now' in the wrong terminal window.

        Our machines are all Dell 1{678}50's and 850's with single or dual P3's and 1 - 2 GB of main memory. The 1x50's are all SCSI-3 with partitions and swap spread out over three disks, and the 850's are simple P3 ATA-disk machines.

        We use a couple of the cheap boxes for live HDD data backups, but other than that and the system duplication, we just replace the systems with the latest low-end Dell hardware on a fairly regular basis. What we have been particular about is getting a good solid bandwidth provider. We're in One Wilshire in LA for our primary node, right next to Google and the other big guys. ( Clean 'Net, clean power, and good monitoring and emergency service.

        Don Wilde
        "There's more than one level to any answer."
Re: OpenBSD or FreeBSD for a Perl web app Production platform?
by radiantmatrix (Parson) on Sep 21, 2006 at 15:27 UTC

    Well, I suppose it depends on what exactly you need. If security is the primary concern, I'd opt for OpenBSD, since its out-of-the-box config is, IMO, the most secure of any free OS.

    Of course, FreeBSD is excellent as well, and in the hands of a competent admin is every bit as secure (IMO) as OpenBSD. It also seems as though the FreeBSD crew manages to have a more up-to-date (though probably less-thoroughly-tested) repository of software and libraries.

    All in all, I would tend to recommend FreeBSD except in certain niche environments.

    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
Re: OpenBSD or FreeBSD for a Perl web app Production platform?
by cog (Parson) on Sep 21, 2006 at 13:48 UTC
    I can tell you that I'm working at the same company include is working at and that yes, I am very pleased with FreeBSD :-) Everything always works :-)

    Of course, it does help to have a FreeBSD guru * with us to make sure everything's properly installed.

    One thing's for sure: once include install a machine, we never have to call him back to fix anything, and that's just great.

    * - include refuses the title, but I insist on giving it to him since he knows so much more than I do about BSD systems

Re: OpenBSD or FreeBSD for a Perl web app Production platform?
by idsfa (Vicar) on Sep 21, 2006 at 15:17 UTC

    Benchmarks speak louder than anecdotes. The article is a couple of years old, but clearly shows the differences in scalability for several OSes, including the two *BSDs you are looking at. The code is provided, so you can re-run the tests on current versions if you wish.

    For the lazy, OpenBSD did not scale well to high volumes of web traffic.

    The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. — Cyrus H. Gordon
      Well, for sure I don't want to start a flame war on "This is better than that". That benchmark is a fact for 2003 when FreeBSD was in it's 5.X "complicated version". Now we are in 2006 :) and FreeBSD is almost releasing it's 6.2-RELEASE. Please stay updated and tunned :)
Re: OpenBSD or FreeBSD for a Perl web app Production platform?
by graff (Chancellor) on Sep 22, 2006 at 00:30 UTC
    I don't have any experience on OpenBSD, so I have no clue how it might differ from FreeBSD. Based on my experience with Perl on FreeBSD, I'd have to say there are things that can go wrong too easily.

    What heppened to us on more than one occasion was that there would be a "normal, routine" update or patch or release upgrade of the OS, and suddenly a lot of perl scripts would stop working, because the version of /usr/bin/perl had suddenly changed (unannounced to the perl programmers), this somehow involved a change of "standard" paths in @INC (because /usr/lib/perl5 is organized by version, even inside site_perl), and a lot of non-core modules were suddenly not being found.

    When these "transitions" happened, there would be momentary panic, then all manner of diverse, inconsistent corrective measures (TMTOWTDI showing its dark, monstrous side), and an enduring sense that the perl environment as a whole was dreadfully fragile.

    (Problems were sometimes amplified when various hosts on the local network -- servers and workstations sharing the same nfs volumes where someone might run the same script in a shell on any machine -- would somehow end up with different perl versions and different module inventories. But that's more a matter of sysadmin behavior, not anything intrinsic to the choice of OS.)

    Maybe it was just pilot error on the part of the guys who were playing sysadmins when the troubles happened, or maybe our group as a whole was just missing a something fundamental about managing Perl in a non-simple FreeBSD network, or maybe it really is something that's hard to get right. I wish I knew.

    It's also entirely possible (maybe even likely) that none of this would be relevant or at all likely in your situation.

      I agree with you, graff, that this does happen.

      I am always p-o'd by things that are in site_perl/5.8.6/blah instead of site_perl/blah, but that's an application of the philosophy of upgrading that does its best NOT to overwrite configurations. That has been The Berkeley Way from Day 1, but is it only FreeBSD ports that do this? The same philosophy applies to unpacking directories when porting, so that apache-1.3.36 is not overwritten by 1.3.37, for example. One could argue that modules are runtimes and therefore should be in common directories, but they're also source, and thus -- by the philosophy -- should not.

      Yes, you do have to sweep the module directories up to the generic before going into production or do a manual port upgrade of each module, and, no, that's not mentioned except in The manpage of Hard Knocks. I'd rate the power of the ports collection and portupgrade system as far and away better than any other installation system on any *NIX, but it doesn't pretend to protect admins against the need to understand what's happening with each and every package used in production.

      Of course, that's why the new boxes I mentioned get upgrades and testing before they go live. We never upgrade production boxes on the fly; some of ours are still running 4.10. I can't say we have never been bitten, and certainly I'm waaaay far short of the all-knowing guru I've made it sound like I am/we have, but that's why you build and test off-line.

      FreeBSD is not meant to be the idiot's way to riches, but it sure _is_ the poor geek's toolbox for Internet success.

      Don Wilde
      "There's more than one level to any answer."

      This is why I install my own perl in /usr/local/perl-x.x.x. I have code that I use here at work to use CPAN and install all the modules we need. Then I have a link /usr/local/perl which points to the production version. I like this setup since I can install a new version of perl and modules, have users test using the self contained install. When testing is done, I point /usr/local/perl to the new version directory. I let the ports that need perl install it and let portupgrade handle the updates.

        Heheh... Yeah, playing with "#!/usr/bin/perl" vs. "#!/usr/local/bin/perl" is something we've done in the past as well -- but that was a case of maintaining both a really ancient "system default" installation for solaris (that was /usr/local/bin/perl -> perl4) along side a not-too-ancient perl5 (/usr/bin/perl -> perl5.3).

        It makes life tolerable, but there are still traps for the unwary -- e.g. when scripts are copied in from other places that don't happen to share this subtle distinction in perl paths. Just another of those gritty details that users of perl scripts need to stumble over now and then...

        We could also opt for "#!/usr/bin/env perl" as the shebag line, and control the relative ordering of /usr/local/bin and /usr/bin in PATH. But that's not exactly a comfortable solution either; it just passes the discomfort to the user's shell environment instead of the script maintainer's choice for the shebang line, which is probably a really bad idea.

Re: OpenBSD or FreeBSD for a Perl web app Production platform?
by Anonymous Monk on Sep 26, 2006 at 17:57 UTC
    Many interesting posts here. Thanks for sharing. To me, it's the total "stack" that counts, since everything from the OS to the database to the net setup (such as DDOS protection and handling), to the actual Perl code that runs behind your web pages all comes together in an implementation that defines how well a web app does or doesn't perform in the real world.

    These kinds of post in this thread, sharing real world experiences and implementation details of the "stack" components (OS, database, etc.) people find work well, make us all better Perl Monks, IMO.

    Right now, I'm reading up on DDOS defenses. Interesting stuff (feel free to offer suggestions and links).

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://574115]
Approved by chargrill
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2022-05-26 11:53 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (93 votes). Check out past polls.