Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi,

I work for a company that runs a news site that has quite alot of users in average, and very high load from time to time (in the top 30 of the most popular sites for Sweden). We are soon starting a optimizing project to discuss and investigate the different options we have to make the site even faster and more scalable, and Terracotta is one alternative that I might bring up.

But after having read most of the documentation I'm starting to think that Terracotta might not be the right choice for us after all... The main problem as I see it is that we use a complex 3rd party CMS, and we don't have access to the source code (exept by decompiling). So the CMS is almost like a black box in a way. And this I think could cause problems when configuring Terracotta. How do I know what roots I should choose? And the instrumented classes?

Do any of you guys have any input about this? Does one need to have a intricate knowledge about how the CMS is built in order to cluster it using Terracotta?

Also.... I know about "Terracotta Sessions cluster with Apache Tomcat", but the clustering of sessions is the least interesting aspect in our case, since most of the site doens't use sessions much at all.

Regards
/Jimi

jimih wrote:

and we don't have access to the source code (exept by decompiling). So the CMS is almost like a black box in a way. And this I think could cause problems when configuring Terracotta. How do I know what roots I should choose? And the instrumented classes?

See below.

jimih wrote:

Do any of you guys have any input about this? Does one need to have a intricate knowledge about how the CMS is built in order to cluster it using Terracotta?

Yes and no. You need to know something about it in order to pick a root. From there, you might get away with simple instrumentation - but its unlikely.

To be successful, you need a good bit of knowledge usually.

What is the CMS?

Hi Taylor,

Well, of course it is not a *complete black box*, and some of our programmers have quite alot of knowledge about its internal parts, but no one has the full knowledge like one would have if it was written by us. The only time someone of us looks at the source code (by decompiling) is when there is a bug or strange behaivor that needs to be investigated.

The CMS in question is Polopoly, version 8 (www.polopoly.com). However they plan to start investigating a complete remake of the site next year, and it could mean switching CMS entirely, or upgrading to Polopoly 9 (and that is basically the same thing as switching to another CMS anyway). But I think that my question is more or less valid regardles of what 3rd party CMS we talk about.

/Jimi

In general, not knowing the app is a bad start when planning to cluster. The rules change if you just want Hibernate 2nd level caching or HTTP session clustering--we can pretty much abstract the app from you there.

Its your call. If you go fwd. Start with what you think the roots should be. Instrument all classes: *..*
And set autolock with write level locking

Use our Admin console more like a profiling tool to figure out how to shrink the instrumented classes and the lock scope.

Could take a week or so. And if you don't crawl all parts of your code via testing you could end up with incorrect config that you discover at runtime later.

--Ari