memcached for Windows (Win32 and Win64)

155 views
Skip to first unread message

Jefty Negapatan

unread,
Mar 24, 2020, 6:26:13 PM3/24/20
to memcached
Hello Memcached community!

Just wanna share that I've ported the latest memcached (1.6.2) to Windows. Based on my search if I'm not mistaken, the last native Windows build (not via Cygwin/WSL) is already outdated (1.4.5).

Unsupported/Disabled options/features (may support in the future):
  1. sasl (Upstream support since v1.4.3)
  2. extstore (Upstream support since v1.5.4)
  3. tls (Upstream support since v1.5.13)
  4. -u/user (Can use Windows runas command or Windows explorer's Run as different user context menu)
  5. -s/unix-socket (Windows does not currently support Unix domain socket)
  6. -k/lock-memory (Windows does not currently support locking of all paged memory)
  7. -r/coredumps (mingw-w64 currently doesn't support postmortem but gdb debugging without coredump is possible)
  8. seccomp (Linux-specific)

Testing:
  1. memcached's testapp is also ported to easily verify that the port is working as expected (all 57 tests are OK)
  2. make test will only execute testapp.exe and sizes.exe but not the Perl-based test suite (at least currently)
  3. mc-crusher test is also performed (although not really for hours/days).
  4. Maximum connection limit concurrency testing is also performed using libMemcached's memcslap.
  5. NOTE: Since Perl-based test suite is not executed, test is lacking on some areas. Use at your own risk!

Since the ideal target is to be merged upstream although not really a priority and just depends on the maintainer, the codes are carefully written (and of course tested!) not to cause major merge conflicts with the base code. You can confirm this with the diffs. Building with changes for non-Windows target is just like building the original codes as changes are all protected with preprocessor macros (e.g. DISABLE_UNIX_SOCKET) and build env. Main logic is same as the official except for the necessary Windows-specific changes mostly implemented in separate files (see mingw folder). https://github.com/jefyt/memcached-windows#implementation-notes-for-devs contains the summary of changes.

Just refer to https://github.com/jefyt/memcached-windows (mingw branch) for more details (e.g. building, binaries, notes).

If you know anyone asking for Windows binaries or just interested to try/test/take a look, you can refer to this port.

Thanks!

Regards,
Jefty

Jefty Negapatan

unread,
Mar 27, 2020, 5:25:05 PM3/27/20
to memcached
Hello Memcached community!

Just an update:

Unsupported/Disabled options/features (may support in the future):
  1. tls (Upstream support since v1.5.13) Now supported! Built and tested with latest OpenSSL (1.1.1d).
Just like cURL and Google Chrome for Windows, TLS library is statically linked.
Statically-linked exe size: 327KB -> 3,008KB

Regards,
Jefty

Jefty Negapatan

unread,
Mar 31, 2020, 3:35:47 PM3/31/20
to memcached

Hello Memcached community!


Just an update (v1.6.3):


Unsupported/Disabled options/features (may support in the future):

tls (Upstream support since v1.5.13) Now supported! Built and tested with latest OpenSSL (1.1.1d). Built and tested with latest BoringSSL (chromium-stable). BoringSSL reduced the statically-linked executable size by ~34% (Win64 2.94MB -> 1.94MB). BoringSSL already rejects peer renegotiations by default so the unsupported OpenSSL-only SSL_in_before API used in memcached is no longer necessary. I just disabled it using OPENSSL_IS_BORINGSSL macro.

Testing:

NOTE: Since Perl-based test suite is not executed, test is lacking on some areas. Use at your own risk! Perl-based test suite is now ported and it was able to detect issues and I already fixed! Majority of the test suite change is only disabling the unsupported unix socket connection but no changes in test cases/scenarios. All tests PASSED! This will now give Windows users the confidence to use the native Windows port.

GitHub Release: https://github.com/jefyt/memcached-windows/releases/tag/1.6.3_mingw

Build/Test/Artifacts: https://ci.appveyor.com/project/jefty/memcached-windows/builds/31859470

Again, the unsupported options/features (may support in the future):

    1. sasl (Upstream support since v1.4.3)
    2. extstore (Upstream support since v1.5.4)
    1. -u/user (Can use Windows runas command or Windows explorer's Run as different user context menu)
    2. -s/unix-socket
    1. -k/lock-memory
    2. -r/coredumps
    3. seccomp


    Regards,
    Jefty

    Jefty Negapatan

    unread,
    Apr 4, 2020, 7:43:46 AM4/4/20
    to memcached
    Hello Memcached community!

    Just an update:

    Again, the unsupported options/features (may support in the future):

    1. sasl (Upstream support since v1.4.3)
    1. extstore (Upstream support since v1.5.4) Now supported! All tests passed!
    2. -u/user (Better use Windows runas command, Windows explorer's Run as different user context menu, or other Windows built-in tools)
    3. -s/unix-socket
    4. -k/lock-memory
    5. -r/coredumps
    6. seccomp

    Regards,
    Jefty

    dormando

    unread,
    Apr 4, 2020, 6:14:36 PM4/4/20
    to memcached
    Hey,

    Thanks for this! I haven't had time yet to look closely. I'll throw out a
    few sentences to maybe start a convo:

    I think this is the third or fourth windows port. Usually they come out,
    run for a few versions, then the maintainer gets distracted and it stops.

    Often the patches are huge/unwieldy or simply replace code so it won't run
    on anything _but_ windows.

    In that spirit, do you have any interest in finding what code can be
    upstreamed to either minimize the size of the fork to something managable
    longer term, or at least fiddle in that direction?

    My thought would be (though again I haven't at all looked at what
    you've done) is to break down the changes into small chunks to be
    individually reviewed and upstreamed so that the fork simply shrinks with
    time. There should be some changes that're easier than others to upstream.

    thanks,
    -Dormando

    On Sat, 4 Apr 2020, Jefty Negapatan wrote:

    > Hello Memcached community!
    > Just an update:
    >
    > Again, the unsupported options/features (may support in the future):
    >
    > 1. sasl (Upstream support since v1.4.3)
    > 2. extstore (Upstream support since v1.5.4) Now supported! All tests passed!
    > 3. -u/user (Better use Windows runas command, Windows explorer's Run as different user context
    > menu, or other Windows built-in tools)
    > 4. -s/unix-socket
    > 5. -k/lock-memory
    > 6. -r/coredumps
    > 7. seccomp
    >
    > Build/Tests/Artifacts: https://ci.appveyor.com/project/jefty/memcached-windows
    >
    > Alternative Downloads: https://bintray.com/jefty/generic/memcached-windows/_latestVersion
    >
    > Regards,
    > Jefty
    >
    > On Tuesday, March 31, 2020 at 9:35:47 PM UTC+2, Jefty Negapatan wrote:
    >
    > Hello Memcached community!
    >
    >
    > Just an update (v1.6.3):
    >
    >
    > Unsupported/Disabled options/features (may support in the future):
    >
    > tls (Upstream support since v1.5.13) Now supported! Built and tested with latest OpenSSL
    > (1.1.1d). Built and tested with latest BoringSSL (chromium-stable). BoringSSL reduced
    > the statically-linked executable size by ~34% (Win64 2.94MB -> 1.94MB). BoringSSL
    > already rejects peer renegotiations by default so the unsupported OpenSSL-only
    > SSL_in_before API used in memcached is no longer necessary. I just disabled it using
    > OPENSSL_IS_BORINGSSL macro.
    >
    > Testing:
    >
    > NOTE: Since Perl-based test suite is not executed, test is lacking on some areas. Use at
    > your own risk! Perl-based test suite is now ported and it was able to detect issues and
    > I already fixed! Majority of the test suite change is only disabling the unsupported
    > unix socket connection but no changes in test cases/scenarios. All tests PASSED! This
    > will now give Windows users the confidence to use the native Windows port.
    >
    > GitHub Release: https://github.com/jefyt/memcached-windows/releases/tag/1.6.3_mingw
    >
    > Build/Test/Artifacts:
    > https://ci.appveyor.com/project/jefty/memcached-windows/builds/31859470
    >
    > Again, the unsupported options/features (may support in the future):
    >
    > 1. sasl (Upstream support since v1.4.3)
    > 2. extstore (Upstream support since v1.5.4)
    > 3. -u/user (Can use Windows runas command or Windows explorer's Run as different user
    > context menu)
    > 4. -s/unix-socket
    > 5. -k/lock-memory
    > 6. -r/coredumps
    > 7. seccomp
    >
    >
    > Regards,
    > Jefty
    >
    > On Friday, March 27, 2020 at 10:25:05 PM UTC+1, Jefty Negapatan wrote:
    > Hello Memcached community!
    > Just an update:
    >
    > Unsupported/Disabled options/features (may support in the future):
    > 1. tls (Upstream support since v1.5.13) Now supported! Built and tested with latest
    > OpenSSL (1.1.1d).
    > Just like cURL and Google Chrome for Windows, TLS library is statically linked.
    > Statically-linked exe size: 327KB -> 3,008KB
    >
    > Regards,
    > Jefty
    >
    > On Tuesday, March 24, 2020 at 11:26:13 PM UTC+1, Jefty Negapatan wrote:
    > Hello Memcached community!
    >
    > Just wanna share that I've ported the latest memcached (1.6.2) to Windows. Based
    > on my search if I'm not mistaken, the last native Windows build (not via
    > Cygwin/WSL) is already outdated (1.4.5).
    >
    > Unsupported/Disabled options/features (may support in the future):
    > 1. sasl (Upstream support since v1.4.3)
    > 2. extstore (Upstream support since v1.5.4)
    > 3. tls (Upstream support since v1.5.13)
    > 4. -u/user (Can use Windows runas command or Windows explorer's Run as different
    > user context menu)
    > 5. -s/unix-socket (Windows does not currently support Unix domain socket)
    > 6. -k/lock-memory (Windows does not currently support locking of all paged
    > memory)
    > 7. -r/coredumps (mingw-w64 currently doesn't support postmortem but gdb debugging
    > without coredump is possible)
    > 8. seccomp (Linux-specific)
    >
    > Testing:
    > 1. memcached's testapp is also ported to easily verify that the port is working
    > as expected (all 57 tests are OK)
    > 2. make test will only execute testapp.exe and sizes.exe but not the Perl-based
    > test suite (at least currently)
    > 3. mc-crusher test is also performed (although not really for hours/days).
    > 4. Maximum connection limit concurrency testing is also performed using
    > libMemcached's memcslap.
    > 5. NOTE: Since Perl-based test suite is not executed, test is lacking on some
    > areas. Use at your own risk!
    >
    > Since the ideal target is to be merged upstream although not really a priority and
    > just depends on the maintainer, the codes are carefully written (and of course
    > tested!) not to cause major merge conflicts with the base code. You can confirm
    > this with the diffs. Building with changes for non-Windows target is just like
    > building the original codes as changes are all protected with preprocessor macros
    > (e.g. DISABLE_UNIX_SOCKET) and build env. Main logic is same as the official
    > except for the necessary Windows-specific changes mostly implemented in separate
    > files (see mingw folder).
    > https://github.com/jefyt/memcached-windows#implementation-notes-for-devs contains
    > the summary of changes.
    >
    > Just refer to https://github.com/jefyt/memcached-windows (mingw branch) for more
    > details (e.g. building, binaries, notes).
    >
    > If you know anyone asking for Windows binaries or just interested to try/test/take
    > a look, you can refer to this port.
    >
    > Thanks!
    >
    > Regards,
    > Jefty
    >
    > --
    >
    > ---
    > You received this message because you are subscribed to the Google Groups "memcached" group.
    > To unsubscribe from this group and stop receiving emails from it, send an email to
    > memcached+...@googlegroups.com.
    > To view this discussion on the web visithttps://groups.google.com/d/msgid/memcached/32ae9fed-3165-4ce4-b5d2-7e5c2f7ecae8%40googlegroups.com
    > .
    >
    >

    Jefty Negapatan

    unread,
    Apr 5, 2020, 6:47:04 AM4/5/20
    to memcached
    Hi Dormando,

    Thanks for at least for considering this new port.

    Often the patches are huge/unwieldy or simply replace code so it won't run 
    on anything _but_ windows.
    --> I understand your concern. This is the reason why I have these basic requirements for this port:
    1. Codes (new and modified) MUST be guarded with prep macros/build env (e.g. DISABLE_UNIX_SOCKET, _WIN32, mingw32). Building for non-Windows target MUST just be same as the upstream as if no codes were added/modified.
    2. Codes MUST build with latest GCC with Mingw-w64 both on Windows and *nix build hosts. CI build is using debian:testing docker to take advantage of the latest GCC (currently 9.3similar to cURL
    3. Runtime dependencies SHOULD only be the Windows system libraries similar to cURL where all dependencies are statically linked for Windows. As you know Windows package management is not similar to *nix where you can just easily install deps (libevent, OpenSSL). So far, this is satisfied and the remaining unsupported feature is SASL.
    4. And of course, it MUST passed the tests.

    In that spirit, do you have any interest in finding what code can be 
    upstreamed to either minimize the size of the fork to something managable 
    longer term, or at least fiddle in that direction? My thought would be (though again I haven't at all looked at what 
    you've done) is to break down the changes into small chunks to be 
    individually reviewed and upstreamed so that the fork simply shrinks with 
    time. There should be some changes that're easier than others to upstream. 
    --> I can do this. I'll just break down the changes into small chunks and request for review.

    Thanks!

    Regards,
    Jefty

    Jefty Negapatan

    unread,
    Apr 8, 2020, 3:56:52 PM4/8/20
    to memcached
    Hello Memcached community!

    Just wanna share that I've created Why native? wiki that contains basic comparison of the native port with the Cygwin alternative. Please take note of the test environment. Results will likely differ depending on environment.
    Summary:
    1. Standby CPU usage of native is < 0.01% while Cygwin > 0.50%
    2. While testing, CPU usage of native is < 25% while Cygwin > 35%
    3. Cygwin's CPU time (rusage) total is >70% more than native
    4. Native's throughput and speed are at least 7% better
    5. Cygwin's latency is at least 10% more than native
    6. Native's created threads stays at 10 (same upstream) while Cygwin created 18 before test and added 2 after test (20 total).

    Again, this is just basic comparison executed with default args on a basic Windows laptop with an Ubuntu running on its VirtualBox.

    Regards,
    Jefty

    Martin Grigorov

    unread,
    Apr 8, 2020, 4:38:57 PM4/8/20
    to memc...@googlegroups.com
    Hi,

    Thanks for sharing this!

    On Wed, Apr 8, 2020 at 10:56 PM Jefty Negapatan <jeft...@gmail.com> wrote:
    Hello Memcached community!

    Just wanna share that I've created Why native? wiki that contains basic comparison of the native port with the Cygwin alternative. Please take note of the test environment. Results will likely differ depending on environment.
    Summary:
    1. Standby CPU usage of native is < 0.01% while Cygwin > 0.50%
    2. While testing, CPU usage of native is < 25% while Cygwin > 35%
    3. Cygwin's CPU time (rusage) total is >70% more than native
    4. Native's throughput and speed are at least 7% better
    5. Cygwin's latency is at least 10% more than native

    How do you measure the latency and throughput ?

    Regards,
    Martin
     
    1. Native's created threads stays at 10 (same upstream) while Cygwin created 18 before test and added 2 after test (20 total).

    Again, this is just basic comparison executed with default args on a basic Windows laptop with an Ubuntu running on its VirtualBox.

    Regards,
    Jefty

    On Sunday, April 5, 2020 at 12:47:04 PM UTC+2, Jefty Negapatan wrote:
    Hi Dormando,

    Thanks for at least for considering this new port.

    Often the patches are huge/unwieldy or simply replace code so it won't run 
    on anything _but_ windows.
    --> I understand your concern. This is the reason why I have these basic requirements for this port:
    1. Codes (new and modified) MUST be guarded with prep macros/build env (e.g. DISABLE_UNIX_SOCKET, _WIN32, mingw32). Building for non-Windows target MUST just be same as the upstream as if no codes were added/modified.
    2. Codes MUST build with latest GCC with Mingw-w64 both on Windows and *nix build hosts. CI build is using debian:testing docker to take advantage of the latest GCC (currently 9.3similar to cURL
    3. Runtime dependencies SHOULD only be the Windows system libraries similar to cURL where all dependencies are statically linked for Windows. As you know Windows package management is not similar to *nix where you can just easily install deps (libevent, OpenSSL). So far, this is satisfied and the remaining unsupported feature is SASL.
    4. And of course, it MUST passed the tests.

    In that spirit, do you have any interest in finding what code can be 
    upstreamed to either minimize the size of the fork to something managable 
    longer term, or at least fiddle in that direction? My thought would be (though again I haven't at all looked at what 
    you've done) is to break down the changes into small chunks to be 
    individually reviewed and upstreamed so that the fork simply shrinks with 
    time. There should be some changes that're easier than others to upstream. 
    --> I can do this. I'll just break down the changes into small chunks and request for review.

    Thanks!

    Regards,
    Jefty

    --

    ---
    You received this message because you are subscribed to the Google Groups "memcached" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to memcached+...@googlegroups.com.

    Jefty Negapatan

    unread,
    Apr 8, 2020, 4:57:27 PM4/8/20
    to memcached
    Hi Martin,

    Although I've used mc-crusher for some tests, for this basic comparison I've used memtier_benchmark because I only want its summary. I've also described the args I've used in Why native? wiki. For the CPU (aside from STAT rusage*) and RAM usage, I used the Sysinternals Process Explorer.

    See the attached files for reference.

    Rgards,
    Jefty
    memtier_benchmark_summary.xlsx
    process_info_test_end.png
    process_info_test_ongoing_cygwin.png
    process_info_test_ongoing_mingw.png
    process_info_test_start.png

    Jefty Negapatan

    unread,
    Apr 23, 2020, 11:32:39 AM4/23/20
    to memcached
    Hello,

    Just an update regarding the benchmark. I performed the benchmark on a GitHub Windows Server 2019 runner environment.
    Server: 1,500 conn limit, default options
    Client: 10 threads x 100 clients x 20,000 requests x 3 runs (total 3,000 connections), 1:10 set:get ratio
    Test Duration: 3 hours

    Summary:

    MinGW TCP vs Cygwin TCP Impact
    Type Ops/sec Latency KB/sec rusage
    Sets   78.09% 73.42% 78.09% 103.06%
    Gets   78.09% 71.03% 78.08%

    MinGW TCP vs MinGW TLS Impact
    Type Ops/sec Latency KB/sec rusage
    Sets   63.01% 57.04% 63.01% 76.62%
    Gets   63.01% 58.71% 64.56%

    Unfortunately, the benchmark tool wasn't able to generate speed summary for Cygwin TLS due to many dropped connections (419 less than expected). It also took almost 2 hours to execute the Cygwin TLS test compared to MinGW's 25 mins. Cygwin TLS' rusage  is 368.99% more than MinGW TLS.

    Additional info, I've created Runtime and Crash Analysis wiki that describes how to debug/analyze memcached-windows in case of issues (e.g. crash, hangup). Of course there are many strategies but I just described common/simpler ones.

    Regards, 
    Jefty

    Reply all
    Reply to author
    Forward
    0 new messages