This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RPC over Proxy setup

Hi M-Files team and community,

We are using RPC over Proxy setup as described here: www.m-files.com/.../rpc_over_http.html.
We were able to enable access over proxy and over https.

Even though I have a quite solid internet speed (49 MBps Download, 12 Mbps Upload), when I try connection over M-Files client I get only 1,68 MBPs Download and 1,39 MBps Upload. Is such degradation expected when connection is setup over proxy?

We have test environment in Azure. Of course, this for sure cause latency. What would be realistic degradation in network throughput when using RPC over HTTPs instead of LPC protocol?

Thanks.

Dejan
  • LPC is local, so that'll be pretty instantaneous. Any remote connection will be incomparable, honestly.

    You're using RPC over HTTPS to what machine? Your Azure test instance? Is this in the M-Files cloud or in your own infrastructure?

    There's obviously an overhead of using RPC over HTTPS but that impact seems far (far!) too much to be blamed on just the protocol.

    Regards,

    Craig.
  • Have just run a comparison between RPC over HTTPS via a proxy and simple TCP/IP (port 2266 directly to the server). The server is on premise, 1000 Mbps network, latency 1 - 2 ms. Proxy is on the same hardware as M-Files server but on different virtual servers (Hyper-V).
    Results for download and upload:
    TCP/IP 45-60 MB/s 24-41 MB/s
    HTPPS 41-61 MB/s 8-39 MB/s

    Results vary considerably if you run repeated tests with short intervals, in particular the first test on HTTPS showed much lower upload speed than any of the following tests. That might be due to some part of the system being in sleep mode when the first test was initiated. All of the following tests were pretty much in the same range as TCP/IP. In general it is my impression that you may get an average impact around 2 - 4 MB/s from HTTPS over RPC via a proxy. Anything beyond that would have to do with network connections.
  • Thank you for answers.

    @CraigHawker: Our own Azure instance.

    @bright-ideas.dk: even though I have used my local client for quite some time (so all modules should be awake), I am still not reaching anything close to my network throughput. My continuous tests in short intervals make maximal throughput of 4 MBps.

    Our plan is also to host it on premise in future so hope that we will be able to utilize that throughput.

    So, it must be latency to Azure or we missed something in our configuration but than I would assume it would not work at all!?
    We have basically Proxy and MFiles on same virtual server in Azure. We are using 443 port for web page and 4466 for desktop client.

    Thanks
  • Hi,

    There's lots of potential issues here depending on exactly what's configured, where, and with what resources. I think it's probably something that you would need to discuss with your reseller or M-Files support to get some "hands on" diagnostics.

    Regards,

    Craig.
  • A quick test on a client setup in Azure that I have access to. Server specifications are not quite on level with my own server. Internet connection is 200/200 Mbps, delay around 20 ms. M-Files measures download around 15 MB/s, upload around 4 MB/s
    Seems quite a bit of slow response origins from Azure and probably from our attempt to save on "horsepower" on the server out there.
  • Our experience with RPC over HTTPS matches bright-ideas.dk's experience, only slightly slower when accessing via proxy as opposed to direct, with a similar architecture.