memcached for Windows (Win32 and Win64)

[Jefty Negapatan]

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]

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]

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]

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

Build/Tests/Artifacts: https://ci.appveyor.com/project/jefty/memcached-windows

Alternative Downloads: https://bintray.com/jefty/generic/memcached-windows/_latestVersion

Regards,

Jefty

[dormando]

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]

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.3) similar 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]

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]

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.3) similar 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/memcached/d2279962-eed0-4174-abb0-95fd4716ca63%40googlegroups.com.

[Jefty Negapatan]

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

[Jefty Negapatan]

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

Result: https://github.com/jefyt/memcached-windows/actions/runs/85659023

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