Hi David,

On MySQL performance on Windows would be not that much different from
Linux, the same for mod_perl and Apache. I have a significant amount of
code in the OTRS codebase and Perl itself is typically pretty OS agnostic,
there are very few places where we even have specific code for different
platforms.

If you have recommendations or benchmarks I would really be interested to
see where we could optimize, but I would be amazed if there would be lots.

On your remark about the large amount of support requests for Windows
users: a large part of people trying out our product first download the
Windows installer to evaluate the product. This means you can expect to see
more  mails from Windows users on the list. And also from our Subscription
customers between 30 and 40 percent is using Windows.

As stated before, I think the most important reason to choose the OS for
deployment of OTRS would be that of available skills. If your IT department
has Linux skills available, this would be the choice, but if you have only
MCSE people, Windows, maybe using IIS or Apache would be the obvious choice.

You commented on the fact that OTRS assumes IO is fast and cheap. This is
true, for instance our caching mechanism uses a disk based cache by
default. We have been making deployments based on Memcached (which is
available as a Feature Add-On), this uses a memory based cache. But this is
typically most useful for bigger deployments, if you use small VPSes both
memory and IO is not readily available. I think the optimal solution would
vary from case to case.

What would you think could be improved here? I really like the fact that
OTRS now does lots of caching ans hits the database much less than in the
2.4 era.

--
Mike
Op 24 sep. 2012 21:18 schreef "David Boyes" <dbo...@sinenomine.net> het
volgende:

> > > 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
>
_______________________________________________
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

Reply via email to