Spray JSON Marshalling Performance

[Elisabeth Anderson]

We've been using Spray for a while now and have a few services running but I've been running some profiling as we'd like to see if we can maximise performance. I've long been concerned that our pattern is to build objects, then store them in our cache as a JSON string, then return these from the cache by unmarshalling the JSON string to case classes then preparing the response and rendering JSON as the HTTP response body. It felt, intuitively, that excessive marshalling/unmarshalling is probably a bad thing although the performance testing I've been running with YourKit/Gatling suggests that our code spends most of its time with the Parboiled parserunner. Though our pipeline can be quite complex if we don't have the object in our cache: 

user makes request

service checks cache

service makes upstream call for JSON data 

service unmarshalls JSON data and maps this to native case classes

service marshalls native case classes to JSON string

service renders native case classes to JSON string in HTTP response

Or if we do have the object:

user makes request

service checks cache

service unmarshalls JSON string from cache to native case classes

service renders native case classes to JSON string in HTTP response

So even a request to the cache gets a string and turns it into objects then back into a string...could this be short-cut?

Obviously different apps will vary but our API dialect is JSON so I'm wondering if there was any optimisation we could do. I did consider building the JSON and inserting it into the cache outside of an HTTP request cycle and then just return the string from the cache direct as the body of an HTTP request. The only wrinkle is that we unmarshall the JSON string to do things like add single items to collections etc. It makes sense—logically—to unmarshall three strings to three objects, add them to a collection then marshall this collection to JSON. Makes sense logically, in terms of code, but not necessarily in terms of performance.

It's a bit of an open question really. We'd like to boost our req/sec but should this be done simply by adding more resources to scale out rather than tweak code?

Also, is there a compelling reason to migrate to Akka from Spray for this purpose?

Thanks,

Beth

[Elisabeth Anderson]

Although there has been no reply to this, I thought it'd be good to reply as to my findings. In fact we're getting around 150 req/sec for the service which is well within the performance that is required. In fact it's really good indeed!

During profiling of the service as it's running you can tell that the app spends a great proportion of its time within the JSON parsing subsystem but in fact it's really quite performant so it's not an issue. It is the most 'expensive' area but in fact it doesn't really add much to the overall at all.

TL;DR JSON parsing is relatively expensive but in practice doesn't add slow performance to any great degree.

[Johannes Rudolph]

Hi Beth,

thanks for sharing your findings. Have you tried updating to a more
recent spray-json version? The latest version is 1.3.2, since 1.3.0
spray-json doesn't use parboiled any more and has a very fast
optimized json parser instead.

Regarding your pipeline, I think it sounds fine if it is fast enough
for you. As an alternative idea you could think about another cache
that only keeps the final JSON data that doesn't need to be changed
any more (don't know if this really applies to your case), or, as
another alternative trying a json library that can do those updates on
the fly. The question is then whether you really want to specify the
updates in terms of json updates instead of updates on the domain
model objects.

HTH,
Johannes

> --
> You received this message because you are subscribed to the Google Groups
> "spray.io User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to spray-user+...@googlegroups.com.
> Visit this group at https://groups.google.com/group/spray-user.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/spray-user/e167f53d-7624-47a1-bbe3-854bf346b999%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net