> > 1. Don't use Windows for this, it demands far more resources than this > size needs, needs a lot of Unix emulation glue and is excessively expensive. > If it has to be hosted on a Windows machine, use the Microsoft virtual > machine technology to run a Linux VM. > > Where do you get this knowledge from? Typically, OTRS is deployed on > mod_perl, Perl itself performs very comparably on Windows vs Linux, just as > Apache; the same goes for our 'default' database which is MySQL.
I'm not just focusing on speed; I'm looking at the following: 1. Apache, Perl and MYSQL are foreigners on Windows. The typical Windows admin who went through the Windows server admin mills do not know how to install, debug, tune or manage them. They do not appear in the Windows management tooling, and their logs and performance data collection have limited integration with the system in ways that the "mill graduates" understand. 2. The recommended server configuration for Windows Server 2008 is a minimum of 2G RAM without applications installed. OTRS employs fairly substantial in-memory processing, and does not ship optimized for low memory machines. See item 1. 3. The cost of a Windows Server license (without any of the corporate deals) is close to 4 times the cost of an equivalent enterprise Linux license with an annual support contract (and does not include support). 4. The volume of support questions we see on this mailing list for people who are trying to run OTRS on Windows is roughly double to triple that of the Linux platforms. > In my > experience, especially with these low ticket volumes, a comparable specced > machine as your mentioned Linux box but running Windows will do just fine. > We typically prefer Linux, but if your environment is not HUGE and if your > team only has Windows skills, Windows is just fine. Will it run on Windows on the same iron? Sure. Is it efficient? Not particularly. The OTRS code -- quite rightly -- doesn't try to optimize itself to run with maximum efficiently within the Windows process model, and it can't without taking into account the fundamental difference in design approach between the two systems - which would lead to a very different code base for the Linux and Windows worlds. It (OTRS) tends to assume that memory is cheap, and dedicated, and that I/O is also dedicated (ie, it doesn't matter if you do a lot of it, assumptions that fail in a virtual machine environment, or any environment where compute resources are shared by multiple systems). > Of course, if you have benchmarks to show that OTRS or Perl or MySQL or... > on Windows is SO MUCH slower than on Linux, I'd be interested to see > these! Actually, I'm in the process of doing just that (on a number of different platforms, including Power and mainframe). I'll be happy to share them when I'm done -- couple of weeks. It's not a question of speed, really -- it's the memory footprint, the I/O behavior, the license expense, and the overall resource consumption before you even get to the application that leads me to recommend against Windows for small implementations. Windows seldom plays nice in a virtual environment (which is more common with small shops renting virtual machines in colo facilities). Then you do the math about licenses, and the Linux version looks better and better. Then you do skills ROI (number of people with Windows vs Linux skills) -- which is no longer a foregone conclusion as a plus for Windows. > Again, as I said, I think a small VM with 1GB Windows would also absolutely > work just fine if you have a limited number of agents. Agreed, with the caveat you mentioned. It'll work, but the testing so far indicates it'll work better on the same resources with the Linux version. _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
