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.
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 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 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (2)
-
Chris van der Meijden -
Mark Webb-Johnson