I think you probably should switch to a different protocol, your tests are not really what I'd consider a typical use case for MQTT.
Anyway, I've added a more dynamic delay, not sure about useful settings, maybe you can set it to your needs (_ServerThread(), #PB_NetworkEvent_None handling).
MQTT Framework
Re: MQTT Framework
{Home}.:|:.{Dialog Design0R}.:|:.{Codes}.:|:.{History Viewer Online}.:|:.{Send a Beer}
Re: MQTT Framework
You are right. But like I said, I just want to explore the limits. Later, publishes are only every 200-500ms over a real network (with pingtimes 2-20ms), but then I know that it will still work even if the host is briefly 90% full for a short time..... tests are not really what I'd consider a typical use case for MQTT
Nice idea, your added a more dynamic delay, thank you.
But unfortunately always the highest delay level is executed because always Packets=0. (Placed Debug's in the Case #PB_NetworkEvent_None)
I don't know in which scenario there will be appear more packets .
The thought occurs to me that it's not about the broker-buffers or -lists (which are handled fast and ready), but simply the network buffer is filling up.
So, the publishing for "maybe minutes" after stopping _PublishViaServer() is maybe just fed from the (64K ?) network buffer.
Unfortunately you can't read the network buffer fill level, unless it's empty, of course.
Thanks overall, it's not a priority, I'm already very satisfied.
Re: MQTT Framework
You might win also some performance, when you disable the base64 encoding.
In MQTT_Common.pbi:
In MQTT_Common.pbi:
Code: Select all
#USE_BASE64_PAYLOAD = #False
{Home}.:|:.{Dialog Design0R}.:|:.{Codes}.:|:.{History Viewer Online}.:|:.{Send a Beer}
Re: MQTT Framework
Hi,
I was "out of order" for a few days, but now I tried a comparison regarding your suggestion.
I think I noticed about 20% better throughput if I complie the MQTT_Broker with #USE_BASE64_PAYLOAD = #False.
I cannot fully test it, because a problem occured:
Publishes from broker to clien appear to have the wrong encoding, looks a bit like the ASCII unicode problem from the old days.
Logwindow Broker publish: #USE_BASE64_PAYLOAD = #False
Manual testdata published > HOME/OUT/cnt=4
Manual testdata published > HOME/OUT/data={"CNT":4,"EPOCH":1716135317,"%1":"#R318D04610"}
Logwindow Client (doesn't matter #USE_BASE64_PAYLOAD = #True or #False)
Rcvd published Topic: 'HOME/OUT/cnt'->p (Q=0, D=0, R=0, M=0)
Rcvd published Topic: 'HOME/OUT/data'->P (Q=0, D=0, R=0 M=0)
Nearly the same applies when using MQTT-Explorer-0.4.0-beta1.exe
cnt = �
data = P����p'P�
But publishes from client to broker seem to be understood correctly, Logwindow Broker shows readable text.
This is my "helper" for manual broker-publishes, if important.:
I was "out of order" for a few days, but now I tried a comparison regarding your suggestion.
I think I noticed about 20% better throughput if I complie the MQTT_Broker with #USE_BASE64_PAYLOAD = #False.
I cannot fully test it, because a problem occured:
Publishes from broker to clien appear to have the wrong encoding, looks a bit like the ASCII unicode problem from the old days.
Logwindow Broker publish: #USE_BASE64_PAYLOAD = #False
Manual testdata published > HOME/OUT/cnt=4
Manual testdata published > HOME/OUT/data={"CNT":4,"EPOCH":1716135317,"%1":"#R318D04610"}
Logwindow Client (doesn't matter #USE_BASE64_PAYLOAD = #True or #False)
Rcvd published Topic: 'HOME/OUT/cnt'->p (Q=0, D=0, R=0, M=0)
Rcvd published Topic: 'HOME/OUT/data'->P (Q=0, D=0, R=0 M=0)
Nearly the same applies when using MQTT-Explorer-0.4.0-beta1.exe
cnt = �
data = P����p'P�
But publishes from client to broker seem to be understood correctly, Logwindow Broker shows readable text.
This is my "helper" for manual broker-publishes, if important.:
Code: Select all
Procedure.s BrokerPublish(Topic.s, DatStr.s) ; Only helper for broker-publishing
Protected *Payload, L ; Call : BrokerPublish("HOME/OUT/cnt", "123")
*Payload = UTF8(DatStr) : L = Len(DatStr)
MQTT_BROKER::_PublishViaServer(Topic, *Payload, L, 0, MQTT_Common::#PayloadType_Buffer)
FreeMemory(*Payload)
EndProcedure
Re: MQTT Framework
I think, there was a @ too much in the broker.pbi, could you please try the latest version?
btw.:
Your helper procedure is not neccessary, just use:
It will be changed to UTF8 anyway
btw.:
Your helper procedure is not neccessary, just use:
Code: Select all
Procedure.s BrokerPublish(Topic.s, DatStr.s)
MQTT_BROKER::_PublishViaServer(Topic, @DatStr, Len(DatStr), 0, MQTT_Common::#PayloadType_UnicodeString)
EndProcedure
{Home}.:|:.{Dialog Design0R}.:|:.{Codes}.:|:.{History Viewer Online}.:|:.{Send a Beer}
Re: MQTT Framework
Perfect, everything works fine now.
Then, I make my not so realistic MQTT speed tests, to scratch the limitations.
Setups:
- 4 Clients compiled .exe running (Two Tests with #USE_BASE64_PAYLOAD = #True or #False)
Logwinodw limited to 300 Lines to avoid speed loss with e.g. >1000 Lines
- 1 Broker running from PB6.04 (C-Compiler) (Two Tests with #USE_BASE64_PAYLOAD = #True or #False)
Has no logging-output during Test (publish all 7-10ms something short)
- Connected via localhost executed on one pc
Result: For me there is no more measurable difference in terms of BASE64_PAYLOAD true or false,
But that doesn't matter because it's twice as fast compared to Broker.pbi V1.13 in all variations of setups above.
In real that means:
After stopping the (far too many) broker publishes after a certain time, the clients continued receiving, for example 20 seconds,
now with V1.14 just only 10 seconds.
btw.:
My old BrokerPublish()-Procedure is inspired by your example_OnEvent_Button().
The new version is nicer and smaller (thanx), but without further speed improvement.
I'm glad that my annoyance at least uncovers small bugs

Then, I make my not so realistic MQTT speed tests, to scratch the limitations.
Setups:
- 4 Clients compiled .exe running (Two Tests with #USE_BASE64_PAYLOAD = #True or #False)
Logwinodw limited to 300 Lines to avoid speed loss with e.g. >1000 Lines
- 1 Broker running from PB6.04 (C-Compiler) (Two Tests with #USE_BASE64_PAYLOAD = #True or #False)
Has no logging-output during Test (publish all 7-10ms something short)
- Connected via localhost executed on one pc
Result: For me there is no more measurable difference in terms of BASE64_PAYLOAD true or false,
But that doesn't matter because it's twice as fast compared to Broker.pbi V1.13 in all variations of setups above.

In real that means:
After stopping the (far too many) broker publishes after a certain time, the clients continued receiving, for example 20 seconds,
now with V1.14 just only 10 seconds.
btw.:
My old BrokerPublish()-Procedure is inspired by your example_OnEvent_Button().
The new version is nicer and smaller (thanx), but without further speed improvement.
I'm glad that my annoyance at least uncovers small bugs
