[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: slow responsiveness of Cygwin install of ledgersmb 1.2.20

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
 (204) 291-7950