Performance and serialisation libraries

[Ari Maniatis]

I'm thinking of using this library, and it appears to have all the features I'd want. I'm a little concerned about the performance graph here: https://github.com/magro/memcached-session-manager/wiki/Performance

Obviously the choice of serialisation library has a big effect, and other reports show protocol-buffers as being one of the fastest out there. Has anyone tried hooking that up? Is it likely to be a big job?

But the other thing hidden in that graph is the performance of Wicket itself with a stateful page. What are we looking at here? The performance impact of MSM plus serialiser and memcache backend, or mostly the performance of Wicket on pages with sessions and state?

For example, if I instead went down the path of Tomcat BackupManager or DeltaManager instead of MSM, would those graphs look very different? The session still needs to be serialised and sent over the network; but to another tomcat instead of to memcache. Does that make a big difference?

Finally, were all those stats collected with session backup in async or sync mode? If we are happy to lose a few seconds of data, async seems like it could eliminate almost 100% of any performance issue. Is that guess right?

Cheers
Ari

[Martin Grotzke]

Hi Ari,

On 04/22/2016 06:45 AM, Ari Maniatis wrote:
> I'm thinking of using this library, and it appears to have all the
> features I'd want. I'm a little concerned about the performance graph
> here: https://github.com/magro/memcached-session-manager/wiki/Performance

It's 5+ years ago that I created/ran this benchmark (exported from
https://code.google.com/archive/p/memcached-session-manager/wikis/Performance.wiki
to the page you referenced). Unfortunately I don't remember on which
code base and msm configuration it was based (and the page doesn't point
to a git commit), but I'd say it was some version of
https://github.com/magro/msm-sample-webapp/tree/master/src/main/java/de/javakaffee/msm/bench.

> Obviously the choice of serialisation library has a big effect, and
> other reports show protocol-buffers as being one of the fastest out
> there. Has anyone tried hooking that up? Is it likely to be a big job?

We're providing kryo serialization, which is one of the fastest
non-schema based serializers, see
https://github.com/eishay/jvm-serializers/wiki (and also
https://github.com/magro/memcached-session-manager/wiki/SerializationStrategyBenchmark).

Please note that this test was running on localhost - in a realistic
distributed setup network latency of course would be higher, in which
degree depends on your setup/infrastructure.

Integrating protobuf should be possible; I'd expect that it takes
between 3 and 10 days of work (as a rough guess) :-)
If you want to have a closer look at this you'd start with implementing
a TranscoderFactory
(https://github.com/magro/memcached-session-manager/blob/master/core/src/main/java/de/javakaffee/web/msm/TranscoderFactory.java)
and SessionAttributesTranscoder.

> But the other thing hidden in that graph is the performance of Wicket
> itself with a stateful page. What are we looking at here? The
> performance impact of MSM plus serialiser and memcache backend, or
> mostly the performance of Wicket on pages with sessions and state?

Because ab (https://httpd.apache.org/docs/2.4/programs/ab.html) was used
for measurement we are looking from the client side: network latency (ab
- tomcat, but because on localhost this should be minimal), wicket's
page rendering, general request handling. Not sure if
sessionBackupAsync="false" or "true" was used, for "false" serializing
the session and sending the result to memcached would also be contained
in the measurement.
Because the used serialization strategy has a visible impact I'd guess
that async=false was used.

> For example, if I instead went down the path of Tomcat BackupManager or
> DeltaManager instead of MSM, would those graphs look very different? The
> session still needs to be serialised and sent over the network; but to
> another tomcat instead of to memcache. Does that make a big difference?

I don't know.

>
> Finally, were all those stats collected with session backup in async or
> sync mode?

As said above, I'm not sure, guessing async=false.

Perhaps https://github.com/magro/msm-sample-webapp/ is still usable,
then you could run your own test.

> If we are happy to lose a few seconds of data, async seems
> like it could eliminate almost 100% of any performance issue. Is that
> guess right?

For sticky session I'd agree, for non-sticky sessions I'd highly
recommend async=false.

Cheers,
Martin


>
> Cheers
> Ari
>
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "memcached-session-manager" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to memcached-session-...@googlegroups.com
> <mailto:memcached-session-...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

--
inoio gmbh - http://inoio.de
Schulterblatt 36, 20357 Hamburg
Amtsgericht Hamburg, HRB 123031
Geschäftsführer: Dennis Brakhane, Martin Grotzke, Ole Langbehn