qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: Minimizing the Proton Engine/Messenger RAM Footprint for embedded devices
Date Fri, 25 Apr 2014 18:18:00 GMT
Hello and welcome to the list.

See inline for further comments...

On Fri, Apr 25, 2014 at 11:55 AM, dcjohns41 <david.johnson3@honeywell.com>wrote:

> Hello Proton Experts,
> I am new to this mailing list and use of the Proton system, so please do
> not
> get offended if I say something naïve.

No worries. Please don't be shy. ;-)

> My team is attempting to use the Proton-C Engine/Messenger package on a
> small footprint embedded device. We are attempting to send sensor
> information and receive data to/from the MS Azure Service Bus
> infrastructure.  We are attempting to use the QPid Proton 0.6 release.  The
> system is using C code on an ARM-xxx processor.
> Our configuration has very limited RAM and have been attempting to reduce
> the run-time requirement to fit in <50Kb or so.  Our data needs are not
> very
> big and normally would fit in <1024 bytes of payload.
> We have trimmed the Proton input/output buffers down from 16KB to smaller
> values.  Have attempted to disable logging and anything else we could to
> get
> the footprint smaller.  At the moment we have the RAM consumption near
> 43Kbytes.  However, once we start attempting to make socket connections, we
> see additional RAM allocations that push over the 50KB limit.
> My first question is- has this been done on other systems where the RAM is
> very limited?  If yes, is that example available for us to review?

I know it's been used on some embedded platforms, but I'm afraid I don't
have any details. I'm guessing either the footprint requirements were not
as small as yours or whatever tuning was required didn't make it back to
the codebase.

> Is it feasible to limit some of the functions/options in the library to at
> least get basic functionality of AMQP 1.0 to Azure/Service Bus running?
>  Our
> expectation is that we need to have at least one transmit link and one
> receive link to pre-defined topics on the Service Bus side.

There's probably a bunch of different things we could try, but to be honest
we haven't really taken a serious look at memory utilization. I'd start by
instrumenting malloc/free so we can identify where the memory usage is
coming from. I'd actually like to get that kind of instrumentation into the
Proton codebase so if you are inclined to do this I'd love to see the
patch. If not I hope to get around to it soon, but its always difficult to
predict how much time I will have.

> Ultimately we need to have AMQPS (via TLS).  But in the short term we are
> just attempting to get basic communication running.

The builtin TLS support relies on openssl, so there may be limits to what
we can do in terms of memory utilization there. Of course you always have
the option of not using the builtin TLS layer and supplying your own, but
again I'd say first thing would probably be to instrument and see how close
we are to your goal.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message