michaelneu / webxcel

🤔 A REST backend built with plain VBA Microsoft Excel macros. Yes. Macros.
https://dev.to/michaelneu/to-vba-and-beyond---building-a-restful-backend-using-plain-microsoft-excel-macros-76n
MIT License
438 stars 70 forks source link

Performance (how to lower the response time) #30

Open ndemou opened 1 year ago

ndemou commented 1 year ago

Hi, I was experimenting with the performance of this library and I noticed that I can drop the response time from ~500msec to ~15msec by making a simple change (which however is probably buggy for special cases). It may be a hack but if someone wants to get more juice from this library it may point to the best point of the code to look at.

Specifically in function ReceiveString() I changed Loop While Len(buffer) > 0 to Loop While Len(buffer) = 1024

More details

This is the code of the function (without the variable Dims)

Public Function ReceiveString() As String
    message = ""    
    Do
        buffer = Trim(ReceiveBytes(1024))
        If Len(buffer) > 0 Then
            message = message & buffer
        End If
    Loop While Len(buffer) > 0

As far as I can tell with Loop While Len(buffer) > 0 you always do an extra call to ReceiveBytes(1024) which it seems always times out after ~500msec if there are no more bytes from the client. This call is 99.9% of the time unneeded and that is why my tweak has the effect it has. I guess that 0.1% of the time my tweak will result in missing a part of the client request (specifically if the client sends 1024 bytes or 2048 bytes in two parts etc).

Is there any way we can make ReceiveBytes(1024) return fast if there are no bytes waiting?

ndemou commented 1 year ago

Following my observation that ReceiveBytes always takes 500msec when no data are waiting I had a bit more time to fiddle around and found an apparently safe tweak that can help to drop the minimum response time of a dummy echo server from 515 to 15msec. If the developer(s) have time and care about performance, I would love to hear if my assumption in bold below is correct.

The tweak is to change the value 500 in line timeout = 500 that appears in TcpClient.cls. In my case (working on a gigabit LAN that has a typical 0msec ping) I set it to 10 and it seems to work perfectly. On a link with 50msec RTT I would have set it to 60 (i.e. RTT in msec+10).

As far as I can tell this value is the maximum time in milliseconds that ReceiveBytes will wait for bytes to be received from a client.