Re: memcached for Windows (Win32 and Win64)

[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*. C*ygwin 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

-- 

--- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/1451fef7-e823-4b78-9800-bf7376164dd7%40googlegroups.com.

Re: memcached for Windows (Win32 and Win64)

[Martin Grigorov]

Hi,

Thanks for sharing this!

On Wed, Apr 8, 2020 at 10:56 PM Jefty Negapatan  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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/memcached/d2279962-eed0-4174-abb0-95fd4716ca63%40googlegroups.com
> 
> .
>

-- 

--- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/CAMomwMo5aDJkfmRmLm6T8kNdK3vxRhUTST7S5Q0wa%2B3UdKQ8UA%40mail.gmail.com.

Re: memcached for Windows (Win32 and Win64)

[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

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/d2279962-eed0-4174-abb0-95fd4716ca63%40googlegroups.com.

Re: memcached for Windows (Win32 and Win64)

[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 

Re: memcached for Windows (Win32 and Win64)

[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)
   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 

Re: memcached for Windows (Win32 and Win64)

[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)
   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 

Re: memcached for Windows (Win32 and Win64)

[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

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/88650775-f54f-4f26-b4d7-5ea371b11e6b%40googlegroups.com.

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

-- 

--- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/bc36a3a7-5b89-42d8-b434-28b2fa8393c0%40googlegroups.com.