以下为转载国外网站关于 Memcache windows下的编译文章
Tuesday, March 30, 2010
Building Memcached on Windows
I like to be able to compile my software on multiple platforms with different compilers, because it force me to write that complies to standards (if not you'll most likely have a spaghetti of #ifdefs all over your code). One of the bonuses you get from using multiple compilers is that you'll get "more eyes" looking at your code, and they may warn you on different things. Supporting multiple platforms will also make it easier to ensure that you don't have 'hidden bombs' in your code (byte order, alignment, assumptions that you can dereference a NIL pointer etc)...
Building software that runs on different flavors of Unix/Linux isn't that hard, but adding support for Microsoft Windows offers some challenges. Among the challenges are:
- Microsoft Windows doesn't provide the headerfiles found on most Unix-like systems (unistd.h etc).
- Sockets is implemented in a separate "subsystem" on windows.
- Win32 provides another threads/mutex implementation than what most software written for Unix-like systems use (pthreads).
- Microsoft doesn't supply a C99 compiler. One would think that it would be safe to assume that one could use a C standard that is more than 10 years old....
I am really glad to announce that we just pushed a number of changesets to memcached to allow you to build memcached on windows "just as easy" as you would on your favorite Unix/Linux system. This means that as of today users using Microsoft Windows is no longer stuck with an ancient version!
`The first thing you need to do in order to build memcached on Windows is to install the "fullversion" of msysgit. In addition to installing git, it also installs a compiler capable of building a 32 bit version of memcached.
So let's go ahead and build the dependencies we need to get our 32bit memcached version up and running!
The first thing up is libevent. You should download the latest 2.x release available (there is a bug in all versions up to (and including) 2.0.4, so unless there is a new one out there you can grab a development version I pushed to libevent-2.0.4-alpha-dev.tar.gz), and install it with the following commands (from within your msysgit-shell). Please note that I'm using /tmp because I've had problems using my "home directory" because of spaces in the directory name (or at least I guess that's the reason ;-) ):
$ cd /tmp $ tar xfz libevent-2.0.4-alpha-dev.tar.gz $ cd libevent-2.0.4-alpha-dev $ ./configure --prefix=/usr/local $ make all (this will fail with an error, but don't care about that.. it's is in the example code) $ make install (this will fail with an error, but don't care about that.. it's just an example)
It's time to start build memcached!!! Let's check out the source code and build it!
$ git clone git://github.com/trondn/memcached.git $ git checkout -t origin/engine $ make -f win32/Makefile.mingw
You should now be able to start memcached with the following command:
$ ./memcached.exe -E ./libs/default_engine.so
Go ahead and telnet to port 11211 and issue the "stats" command to verify that it works!
You don't need to install msysgit on the systems where you want to run memcached, but you do need to include pthreadGC2.dll from the msysgit distribution. That means that if you want to run memcached on another machine you need to copy the following files: memcached.exe .libs/default_engine.so and /mingw/bin/pthreadGC2.dll (Just place them in the same directory on the machine you want to run memcached on :-)
But wait, the world is 64 bit by now. Lets build a 64 bit binary instead
The msysgit we installed previously isn't capable of building a 64-bit binary, so we need to install a new compiler. Download the a bundle from http://sourceforge.net/projects/mingw-w64/files/ (I used mingw-w64-bin_i686-mingw_20100129.zip ). You can "install" it by running the following commands in our msysgit shell:
$ mkdir /mingw64 $ cd /mingw64 $ unzip /mingw-w64-bin_i686-minw_20100129.zip $ export PATH=/mingw64/bin:/usr/local/bin:$PATH
So let's start compiling libevent:
$ cd /tmp $ tar xfz libevent-2.0.4-alpha-dev.tar.gz $ cd libevent-2.0.4-alpha-dev $ ./configure --prefix=/usr/local --host=x86_64-w64-mingw32 --build=i686-pc-mingw32 $ make all $ make install
The compiler we just downloaded didn't come with a 64-bit version of pthreads, so we have to download and build that ourself. I've pushed a package to my machine at: pthreads-w64-2-8-0-release.tar.gz
$ cd /tmp $ tar xfz pthreads-w64-2-8-0-release.tar.gz $ cd pthreads-w64-2-8-0-release $ make clean GC CC=x86_64-w64-mingw32-gcc $ cp pthread.h semaphore.h sched.h /usr/local/include $ cp libpthreadGC2.a /usr/local/lib/libpthread.a $ cp pthreadGC2.dll /usr/local/lib $ cp pthreadGC2.dll /usr/local/bin
And finally memcached with:
$ git clone git://github.com/trondn/memcached.git $ git checkout -t origin/engine $ make -f win32/Makefile.mingw CC=x86_64-w64-mingw32-gcc
So how does it perform?
I'm pretty sure a lot of the "Linux fanboys" are ready to jump in and tell how much faster the Linux version is. I have to admit that I was a bit skeptical in the beginning if the layers we added to get "Unix compatibility" had any performance impact. The only way to know for sure is to run a benchmark to measure the performance.
I ran a small benchmark where I had my client create 512 connections to the server, and then randomly choosing a connection and perform a get or a set operation on one of the 100 000 items I had stored in the server. I ran 500 000 operation (33% of the operations are set operations), and calculated the average time. I can dual-boot one of my machines into Windows 7 and Red Hat Enterprise Linux, so my results shows the "out of the box"-numbers between Windows 7 and Red Hat Enterprise Linux running on the same hardware. I used my OpenSolaris box to drive the test (connected to the same switch). Posting numbers is always "dangerous", because people put too much into the absolute numbers. The intention with my graphs is to show that the version running on Microsoft Windows is pretty much "on par" with the Linux version.
11 kommentarer:
Nice, compiled ok on XP.
March 30, 2010 7:46 PMSlight snag was /tmp was mapped to a path with spaces which causes libevent to not install some of its headers.
Great job!!!
April 22, 2010 9:06 PMBuuuuut..... the version from trondn/memcached.git is 1.3.3 and the last official version is 1.4.5 (http://www.memcached.org)....
Using totalcommander I notice several differences between versions.
And if I try to use the official repository instead of trondn's repository, the code wont compile.
Also, the result exe wont work as a windows service or as a deamon either. This port does the trick but uses version 1.2.1 (Dec 23, 2006)...
Never the less, the version 1.3.3 seems to work ok. Here is the compiled result from my Intel x86:
http://fox.originsoftware.com.ar/memcached-1.3.3.zip
Cheers,
Lucas
Sorry, the memcached implementation of 1.2.1 that I was referring is:
April 22, 2010 9:09 PMhttp://jehiah.cz/projects/memcached-win32/
I just found http://northscale.com/.
April 22, 2010 10:20 PMThey have a free implementation of 1.4.4!!!
Cheers.
Lucas
broken?! why?!
June 24, 2010 3:13 AMfatal error: sys/utsname.h: No such file or directory
compilation terminated.
make: *** [.libs/memcached.o] Error 1
This works very well and I can wrap the exe around a windows service for easy management.
October 19, 2010 8:26 PMWhat changes would be needed to be able to build the latest versions of memcached on Windows ? (1.4.5). As Irancez said.. it fails. I'm guessing it needs changes to the Makefile.mingw
We're currently working on cleaning up the next release.. I'll try to build a new 1.4.5 release that works on windows and push it somewhere... what do you folks want? a 64 bit binary?
October 19, 2010 9:51 PM32 i 64 bit binary if it will be possible would be nice.
November 1, 2010 7:34 PMBut because PHP is still 32bit maybe 32 bit will be enough.
Microsoft Windows doesn't provide the headerfiles found on most Unix-like systems because Microsoft Windows, pre-built binaries are available in the form of a Microsoft installer file (.msi ).
November 11, 2010 6:28 AMmicrosoft windows support
@Trond Norbye
January 24, 2011 3:06 PMThanks for the article. Will try.
"what do you folks want? a 64 bit binary?"
binaries for 32 and 64 bits :)
My windows machine just died, so I need to reinstall it before I can do anything else...
January 24, 2011 3:52 PM