On Wed, Mar 3, 2010 at 3:51 PM, Adam Thompson <[email protected]> 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 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
