Is Content Service's performance no problem compared with in-process API?

Question

I'll upgrade Tridion 2013 SP1 to SDL Web 8.5.

Then Broker API will be changed to RESTfull API (Java) from in-process API.

I'm concerned about Content Service's performance on SDL Web 8.5. On Tridion 2013 SP1, In-Process API is working on each Web site. On SDL Web 8.5, all requests to all Web sites generate request to Content Service and Content Service does all API call. So I'm afraid that Content Service will be bottleneck of performance.

Doesn't Content Service become bottleneck on SDL Web 8.5?

Should multiple Content Services be installed?

What kind of parameters should be set to Content Service to improve performance (for instance -Xmx and other parameters related to memory)?

Answer 1

Doesn't Content Service become bottleneck on SDL Web 8.5?

Yes and no. You're indeed in fact moving the processes, libraries and dependencies which fetch data from the Broker DB from the web app to a separate server or service. The effect of this is, that processes surrounding requests are spread across different JVMs, which in total bring a more scalable solution: you can use up all CPU and memory just to serve content from the database (cached or not) and you can use al CPU and memory of a web app server fully to render pages. If you had all this processing on one server, you'd choke it a lot quicker. And, as Bart already mentioned, it gives a lot easier deployment and dependency graph on your web app.

Further, looking at automated deployments and CI/CD practice, in this architecture it becomes easier to scale up the web apps without putting more pressure on the database if you use proper caching in the Content Service. If it's the case that the Content Services come under pressure, then you can scale those out as well, but you have to check database performance if you do that.

Looking at memory configuration that I've seen for CIS, I generally set as a baseline:

-Xms128m -Xmx4g

If you turn on caching however, then it becomes a matter of measuring your cache sizes under full load, for instance with VisualVM. I've seen instances where we configured a max heap size of 42 GB. It can also pay dividend to tune Garbage Collection, as is fully explained on the Oracle site.

Answer 2

This isn't just your concern, this topic was discussed a lot when the change in architecture was suggested.

Now while all (architecture) changes will have their pros and cons, once the decision was made to change the Content Delivery architecture from in-process to micro services, the cons of this change have all been mitigated. For example, a lot of caching is added on different layers (in CIS, in CIL etc.), and also the option of out-scaling the CIS (all of this should be available in the documentation, if you find something missing leave a comment in the docs please).

Another added benefit of this micro services architecture is the reduction of dependencies required for a web application. With the in-process API on a Java web application you needed to reference about 107 jars (including third party libraries), the CIL reduced that to something like 88 (still too much if you ask me, but a lot better already). For .NET the change is even bigger, since on 2013 you needed to have Java installed and all jars there, and now you only need the CIS dependencies, and no Java on a .NET web application anymore.

Answer 3

This is a great question.

We’ve had initial performance concerns (problems!) with the Content Service on a couple of projects that I’ve worked on. These have manifested in high CPU usage mainly. However, we have managed to mitigate these by:

1. Using a good caching strategy (Tridion object cache, CIL caching and caching in the Web app)

2. Making sure the latest CIS and CIL hotfixes are installed

3. Outscaling the number of Content Services (as you describe) behind a load balancer.

Hope this helps!