[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slow responsiveness of Cygwin install of ledgersmb 1.2.20
- Subject: Re: slow responsiveness of Cygwin install of ledgersmb 1.2.20
- From: Adam Thompson <..hidden..>
- Date: Wed, 03 Mar 2010 17:51:31 -0600
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
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
Apache, Perl, and running CGIs in general are all impacted by these
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
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?