Re: slow responsiveness of Cygwin install of ledgersmb 1.2.20

[Chris Travers <..hidden..>]

On Wed, Mar 3, 2010 at 3:51 PM, Adam Thompson <..hidden..> wrote:

> Not an LSMB dev, but I've used Cygwin extensively in the past.  What
> you're describing sounds about right, if you're using Apache, Perl and
> Postgres all under Cygwin.

First, congrats on getting it to run via Cygwin.
>
> Cygwin has fairly severe performance limitations in a couple of areas.
>
> The first and worst is exec() performance.

We don't exec(), and partly because exec() on Windows is fundamentally
broken (when I say broken I mean it has I/O issues that go beyond
performance issues, though these might not occur on Cygwin).  Also
exec() sucks on mod_perl so that's another reason not to....

> Adding support to LSMB for
> mod_perl or FastCGI would help quite a bit in this exact scenario.  I
> recall Chris Travers previously stating that it would be nice if v2.0
> more-or-less runs under mod_perl... so you'll be waiting a bit for that
> improvement.


I believe some enterprising people have made SQL-Ledger run on
mod_perl without blowing up but it was a lot of work.  Presumably the
same could be used for LedgerSMB.  However, it would be far better if
we can make it run gracefully (which means replacing the code we
inherited).
>
> The second is process startup time.  At startup, cygwin.dll is loaded
> and, effectively, all of GLIBC is loaded and initialized.  Every time.
> (This might have changed by now, I know the Cygwin team has been making
> steady improvements in this area for years.)

I believe Windows SUA is better in this area, btw.  (SUA and Cygwin
are very different products and aren't really comparable-- Cygwin
tries to run POSIX code as a Win32 app, while SUA tries to replace the
Win32 subsystem with a POSIX one).  Cygwin is far more user-friendly,
and usually requires less porting...  However, SUA sometimes feels
more UNIXy (having used both products extensively).  Of course that
requires Windows Server these days....

(Noting of course that the old Services for UNIX has been improved as
the Subsystem for UNIX Applications.)

>
> Both of these problems are due to the underlying OS, by the way -
> they're not Cygwin's fault.  Those brave souls have done an amazing job
> of mitigating the problems.  Cygwin performance in these areas is
> actually substantially BETTER than Microsoft's own Services For UNIX
> product.

In some cases.  Also you can possibly link to non-Cygwin DLL's which
you can't under SFU.
>
> Apache, Perl, and running CGIs in general are all impacted by these
> problems.
>
> The third is filesystem performance.  There are some techniques that can
> be used (raw devices, for example) to get windows-native performance on
> a disk, but they're not generally applicable.  Postgres compiled under
> Cygwin (most databases, in fact) gets hammered by this.  The problem
> isn't bulk performance, so much as traversing directories and opening
> files.  Cygwin has to define and implement a complete set of
> NTFS-to-POSIX translations, some of which are computationally expensive.
>  Perl, finding and loading the dozens of use'd modules at startup, is
> noticeably affected by this.

True.  Hence I think Cygwin is great for some things and have some
customers running it (not for LSMB).  However, it isn't what I would
recommend for LSMB.  Instead, I would recommend VanillaPerl or
StrawberryPerl, Apache, etc. as built as Win32 binaries.  This
eliminates a lot of the mismatches between Win32 and POSIX.

For some reason I believe ActivePerl dies with our code, but
VanillaPerl works and performs rather well.

The other issue with Windows however is printing from the web server.
Please read our FAQ as to registry hacks required to make this work.
>
> There are several other bottlenecks, but I think you've ruled them all
> out in your testing.  I would expect latency under Cygwin to be
> approximately double what it would be under either native win32 or
> native UNIX/Linux environment.  The delays you're talking about seem a
> bit longer than I would have expected.
>
> The bigger question, though, would be why is Cygwin necessary?  Apache
> for Windows works quite well as a native application.  ActivePerl for
> Windows works extremely well as a native application.  PostgreSQL for
> Windows works extremely well as a native application.

We don't support ActivePerl.  Use VanillaPerl instead.  (VanillaPerl
is a minimal port of Perl via MinGW.)

But on the whole you are right.  It's FAR better to use native Win32
applications.

Best Wishes,
Chris Travers