Installation of mod_harbour as module or fastcgi handler

[chrisiwien]

A customer of mine wants to integrate harbour code for his ERP into an online shop - with mod_harbour or modharbour.exe as fastcgi service.

At the moment, we want to use a Windows Server 2019 installation. Our main goal is to circumvent to rewrite all the code in PHP.

Unfortunately, installation out of the box works only with Apache and mod_harbour on Windows Server 2019, but mod_harbour is very slow. On our testserver we get response time around 700ms just with a simple "Hello World" script.

Installing modharbour as fastcgi service has errors on Windows and Linux Debian (see below)
On IIS installing neither mod_harbour as an IIS module or as a fastcgi handler works.
Since mod_harbour as a module is slow, how can I setup mod_harbour as a fastcgi handler or as a proxy-fastcgi-Service in Windows Server 2019?

My Installation tries:

Windows Server 2019

As IIS module:
mod_harbour.dll
Browser error: "mod_harbour error:C:\Windows\TEMP\libharbour.1028.950 The module was not found."

With FastCGI:
modharbour.exe - call with double click:
Windows alert: "The code execution cannot proceed because ace64.dll was not found."
-> copy ace32.dll from "mod_harbour/ads/Program Files 64/Advantage 9.0/Server" to directory with modharbour.exe:
Windows alert: "The ordinal number 521 was not found in the DLL modharbour.exe" (but in the renamed "ace64.dll" there is an ordinal number 521)
modharbour.exe - registering as fastcgi handler in IIS is resulting in undefinied 500 errors (guess the problem is also the missing dependencies).

modharbour.exe: Inspection via software "Dependencies" (https://github.com/lucasg/Dependencies):
"C:\Windows\system32\WS2_32.dll module has missing imports"
"ace64.dll could not be found on disk"
"C:\Windows\system32\OLEAUT32.dll module has missing imports"


Debian 9 Stretch (for comparison Linux/Windows)

modharbour via Apache module mod_harbour.so:
Error: mod_harbour version Jul 14 2020, 14:33:26/tmp/libharbour.507655936.916993992: cannot open shared object file: No such file or directory, failed to load hb_apache()

I symlinked ln -sf ~/mod_harbour/linux/libharbour.so.3.2.0 libharbour.so.3.2.0 in different directories:
var/www/html
var/www
var/customers (with froxlor as admin tool)
var/curtomers/webs (with froxlor as admin tool)

No success, always the above error occurs.

Debian: modharbour via fcgi:
Following the steps described in readme.md in "mod_harbour/fastcgi/linux" results in a oviously missing libcurl.so-File.
The Apache error_log says: "/usr/bin/modharbour: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by /usr/bin/modharbour)"


Inspection of the dependencies of modharbour ("ldd modharbour") I get the following result:

./modharbour: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by ./modharbour)
linux-vdso.so.1 (0x00007fff01b85000)
libfcgi.so.0 => /usr/lib/libfcgi.so.0 (0x00007f6b7134c000)
libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f6b70746000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f6b704da000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f6b7003f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6b6fd3b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6b6fb1e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6b6f91a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6b6f712000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6b6f373000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6b71143000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f6b6f14d000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f6b6ef00000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f6b6ece3000)
libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 (0x00007f6b6eab6000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f6b6e8a8000)
libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x00007f6b6e63f000)
libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (0x00007f6b6e1d8000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f6b6df8d000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f6b6dcb3000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f6b6da80000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f6b6d87c000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f6b6d66d000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f6b6d41c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6b6d202000)
libunistring.so.0 => /usr/lib/x86_64-linux-gnu/libunistring.so.0 (0x00007f6b6ceeb000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f6b6cb52000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f6b6c91d000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f6b6c6e6000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f6b6c463000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f6b6c153000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f6b6bf47000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f6b6bd43000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f6b6bb2c000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f6b6b911000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f6b6b6ac000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007f6b6b478000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f6b6b265000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f6b6b051000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f6b6ae48000)


The files in /usr/lib/x86_64-linux-gnu are/
libcurl.so -> symlink to libcurl.so.4.4.0
libcurl.so.3 -> symlink to libcurl.so.4
libcurl.so.4 -> symlink to libcurl.so.4.4.0
libcurl.so.4.4.0

libcurl-gnutls.so.3 -> symlink to libcurl-gnutls.so.4
libcurl-gnutls.so.4 -> symlink to libcurl-gnutls.so.4.4.0
libcurl-gnutls.so.4.4.0

Perhaps someone can give me some hints solving this problems?

[Otto]

Hello,
Would you be so kind as to post your test file and tell me how you measure the response time?
Best regards,
Otto

[Antonio Linares]

Dear Christoph,

Please download and try this new mod_Harbour build for Microsoft IIS:
https://github.com/FiveTechSoft/mod_harbour/blob/master/IIS/bin/mod_harbour.dll
https://github.com/FiveTechSoft/mod_harbour/blob/master/IIS/bin/libharbour.dll

libharbour.dll must be copied in the same folder where mod_harbour.dll is
Installation process readme: https://github.com/FiveTechSoft/mod_harbour/blob/master/IIS/readme.md

I just tested it here and it is working fine

[Antonio Linares]

Regarding missing ace64.dll please download it from here:

https://devzone.advantagedatabase.com/dz/content.aspx?Key=20&Release=19&Product=5&Platform=14

[Antonio Linares]

Regarding the Linux issues that you describe, I advise you to properly build Harbour and mod_harbour on the Linux where you are going to use it:

* git clone from the repos

* install required packages

* build Harbour and then mod_harbour

[chrisiwien]

Dear Antonio, Dear Otto!

Thanky to you for your kind replies.

@Otto: the testfile outputs just a simple welcome message:
PROCEDURE Main()
? 'Some Text to return'
RETURN

The purpose of this Hello-World-Example is only to see if the Harbour-interpreter works basically without any errors. You know, my responsibility is the webserver configuration, not Harbour programming. I'm not at all experienced with Harbour.
Response Time: I got the response time via the chrom developer tools -> Network. The indicator is the TTFB (Time to first byte) value. This value tells me how long the server is busy with my request before it return it to my browser.

@Antonio: thank you for the new IIS build, i will try that out later and respond again.

@ace64.dll: I've downloaded the "aceapi_x86_64.exe", guess the ace64.dll is included in this package. So, is it necessary to install the whole Advantage Client Engine SDK? Or can I obtain the ace64.dll from this package in another way?

@Linux: uh, i will try that out also later, the Linux version is not my top priority.


Regards

Christoph

[Antonio Linares]

Testing mod_harbour on iMac late 2015 (Windows running natively using bootcamp):

* Windows IIS 64 bits running test.prg is around 300 ms
* Apache 64 bits on Windows 10 running test.prg is around 300 ms
* Apache 64 bits on Linux Ubuntu (WSL) on Windows 10 running test.prg is around 143 ms

* Apache 64 bits on Debian 64 bits running on https://www.modharbour.org/modharbour_samples/test.prg around 200 ms

Current mod_harbour has the technical limitation than on each request libharbour.dll gets copied to a temporary folder

test.prg is the mod_harbour samples folder. The use of HRB files speeds up very much those times

[chrisiwien]

"Current mod_harbour has the technical limitation than on each request libharbour.dll gets copied to a temporary folder"

Uh, that seems quite a huge limitation. "winsat disk" reveals that our testserver seems to be rather slow with disk read/write operations:

Disk Random 16.0 Read 64.34 MB/s 6.7
Disk Sequential 64.0 Read 93.63 MB/s 6.4
Disk Sequential 64.0 Write 90.37 MB/s 6.4
Average Read Time with Sequential Writes 0.551 ms 7.9
Latency: 95th Percentile 1.865 ms 7.8
Latency: Maximum 35.105 ms 7.9
Average Read Time with Random Writes 0.629 ms 8.6

What do you think about this values? Could this be the bottleneck?

Please, can you tell me more about my ace64.dll-question in my last post:
@ace64.dll: I've downloaded the "aceapi_x86_64.exe", guess the ace64.dll is included in this package. So, is it necessary to install the whole Advantage Client Engine SDK? Or can I obtain the ace64.dll from this package in another way?


Regards

Christoph

[Antonio Linares]

Christoph,

Are you using a SSD drive ?

ace64.dll can't be freely redistributed so I guess there is no other option except run the installer they provide and later grab what you may need
You only need it if you plan to use ADS. If not, then you have the install the mod_harbour that does not use ADS.

[chrisiwien]

Hey Antonio,

SSD: good question, nominal yes. Our server is a virtual machine, the ressources are not dedicated. I will dig into this further.

ace64.dll: ok, understood.


Regards

Christoph

[Antonio Linares]

We have implemented mod_harbour as a CGI (not fastCGI) too:

http://www.modharbour.org/cgi-bin/modharbour?test.prg

Around 100 ms

New folder in mod_harbour repo:
https://github.com/FiveTechSoft/mod_harbour/tree/master/cgi

[chrisiwien]

Hey Antonio!

I don't get the mod_harbour module installed right on ISS.

I copied mod_harbour.dll and libharbour.dll to C:/modharbour/ISS and followed the instruction on https://github.com/FiveTechSoft/mod_har ... /readme.md, also the Visual C++ runtime is installed.

Again, the error appears:
mod_harbour error:C:\Windows\TEMP\libharbour.848.826
The module was not found.

What I am doing wrong?

[Antonio Linares]

Please download and use this mod_harbour and libharbour.dll for IIS build:

https://github.com/FiveTechSoft/mod_harbour/blob/master/IIS/bin/mod_harbour.dll
https://github.com/FiveTechSoft/mod_harbour/blob/master/IIS/bin/libharbour.dll

mod_harbour.dll, libharbour.dll and libcrypto-1_1-x64.dll, libcurl-x64.dll and libssl-1_1-x64.dll must be in the same folder all of them:
https://github.com/FiveTechSoft/mod_harbour/tree/master/IIS/bin

I have just tested it and it is working fine, so it should work fine also for you

[chrisiwien]

Uh, i forgot to copy the other dll's, now mod_harbour with IIS works. On my LAN testserver it seems to be faster than the old apache version, fine, TTFB ~380ms. (old was ~500ms).

Next step I will try to setup the fastCGI-Version with IIS.

Then I will test that on the live-server.

Thanks so far!

[chrisiwien]

And with the new dll from https://devzone.advantagedatabase.com/d ... latform=14 fastCGI with IIS works and is fast as hell...~ 9ms.

Very nice!