[Ovmsdev] V3 Server

Mark Webb-Johnson mark at webb-johnson.net
Wed May 17 16:48:29 HKT 2023


Chris,

I think long-term, MQTT (and the IOT way of doing things) is going to be easier and more flexible (even for single user case).

But for that, I/we need to get our mongoose library to support MQTT v5 topics properly, and then see if the data usage is acceptable. If so, then all that will be required would be a MQTT server (like mosquito) with no OVMS server required at all for basic functionality (although something simple would be required for things like historical data storage).

The problem I am hitting now is definitely HTTP API over SSL. With hundreds of users using that (some hitting the server with the same /api/status request every 10 seconds), the server is crawling.

The good news is that since running this new version, I haven’t seen a single 'ClientsTransmit mismatch’ - although my simple grep on ‘mismatch’ is showing a few 'Vehicle Alert #888: VMS/PEM key mismatch - Disarm vehicle with key fob before starting’ for roadster users ;-)

Regards, Mark

> On 17 May 2023, at 4:17 PM, Chris van der Meijden <chris at arachnon.de> wrote:
> 
> Hi Mark,
> 
> thanks for the new development and for your thoughts on V3 and V2.
> 
> I would like to add, that the V2 server for me is still a good server to use as a selfhostet, standalone server.
> 
> This, simple, functionallity should ideally be kept in future development from my perspective.
> 
> Regards
> 
> Chris
> 
> Am Mittwoch, dem 17.05.2023 um 13:07 +0800 schrieb Mark Webb-Johnson:
>> 
>> I have committed some small changes today that address nagging problems I’ve seen on the api.openvehicles.com <http://api.openvehicles.com/> server.
>> 
>> The most interesting of these shows in the logs as:
>> 
>>> 11:04:30.799832 +0800 info  OVMS::Server::ApiV2: #497 - - new connection from <redacted>:<redacted>
>>> 11:04:30.800143 +0800 info  OVMS::Server::Core: #497 - - ConnStart
>>> 11:04:32.147232 +0800 error OVMS::Server::ApiV2: #497 A <owner/vehicle> disconnected
>>> 11:04:32.149214 +0800 info  OVMS::Server::Core: #497 A <owner/vehicle> AppDisconnect
>>> 11:04:32.149614 +0800 info  OVMS::Server::Core: #497 - - ConnFinish
>>> 11:04:32.149924 +0800 info  OVMS::Server::ApiV2: #497 A <owner/vehicle> got proto #/A login
>>> 11:04:32.150859 +0800 info  OVMS::Server::Core: #497 - <owner/vehicle> AppConnect
>>> 11:04:45.071599 +0800 info  OVMS::Server::ApiV2: #501 C <owner/vehicle> got proto #0/C login
>>> 11:04:45.072874 +0800 info  OVMS::Server::Core: #501 C <owner/vehicle> CarConnect
>>> 11:04:45.073157 +0800 error OVMS::Server::Core: #497  <owner/vehicle> ClientsTransmit mismatch /
>> 
>> So at 11:04:30.799832 we got a new connection from an App. Then at 11:04:32.147232 it disconnected. Then at 11:04:32.149924 we got the login. Huh? The rest is the car loging in and trying to inform the messed up app connection.
>> 
>> I guess the login message was held in a push_read buffer within AnyEvent::Handle, but the disconnect error took priority and was delivered first. Fix I made for this is to shutdown reads when handling the disconnect, and another check to not login if the connection has been cleared half way through negotiation.
>> 
>> Anyway, seems better now, but api.openvehicles.com <http://api.openvehicles.com/> is still experiencing heavy load (due to sheer number of concurrent users we have now, combined with a large number of HTTP API users and cpu-intensive SSL connections). It seems that one single HTTPS API user is equivalent to about 50 API v2 users. I think the only way of easily scaling this further now is a switch to MQTT, and have been wondering if the API v2 server could just be a simple bi-directional translator to/from MQTT (which would give us a nice migration path and better support IOT).
>> 
>> Regards, Mark.
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230517/e05fe299/attachment-0001.htm>


More information about the OvmsDev mailing list