Re: slow responsiveness of Cygwin install of ledgersmb 1.2.20

[Adam Thompson <..hidden..>]

On 2010-Mar-03 11:07, Todd B wrote:
> Does anyone have much experience using ledgersmb in a Cygwin
> environment?  I have managed to get 1.2.20 installed, but it is
> painfully slow.  It takes maybe 5 to 10 seconds from HTTP request to
> response.  I'm testing on the loopback interface so network traffic can
> be ruled out and apache serves up static pages very quickly.  All
> requests made through ledgersmb's interface seem to spike cpu usage
> until it finally responding.  If anyone has been through this before,
> please let me know.  Maybe one of the devs could shed some light.

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.

Cygwin has fairly severe performance limitations in a couple of areas.

The first and worst is exec() performance.  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.

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.)

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.

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.

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.

I think, although I haven't verified, that all the needed Perl modules 
are available for ActivePerl; if not, you might be able to use 
VanillaPerl instead.  (Anyone know for sure?  I don't...)

There's nothing in the CGI setup that Apache for Win32/Win64 can't handle.

There's nothing in the database that PostgreSQL for Win32/Win64 can't 
handle.

I have no idea if the TeX distributions for Windows interact nicely with 
LSMB, and I don't know enough about how LSMB invokes LaTeX to comment 
intelligently.  TeX under Windows is not known for great performance 
anyway.  (In fact, it's probably safe to say that TeX is not known for 
great performance, period!  Who cares about the bandwidth of their word 
processor, anyway? :-)

For maximum performance, run Windows-native apps under Windows.  That 
sounds fairly straightforward, but... what sort of issues are you 
dealing with that prevent this?

--
Thank you,
-Adam Thompson
 <..hidden..>
 (204) 291-7950