Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Fundamental JSP scalability question

 
Sebastian Redl
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

In implementing a large project using JSP we've come across several obstacles. Their nature led me to consider the fundamental design decisions behind JSP, as well as its intended use cases.

I'd like to post the conclusions I've reached and see what other people think of the matter.


The project we implemented is mostly half-static data: textual content managed through a CMS by non-technical users. The content changes, but very rarely. The servers are expected to be under very heavy load.
The basic decision therefore was to use a CMS that publishes its contents into concrete files, which are then served by the front-end. The idea is that this reduces the database load, because content is only re-published when it is changed, instead of queried on every single page access.

However, since there is some dynamic data in each page (an overview of the latest news, for example), the published pages are in turn dynamic.
The choice for the technology for these front-end dynamic pages fell on JSP, for reasons neither known to me, nor under my control. My guess is that JSP's reputation for scalability was the main deciding factor.

This turned out, in my opinion, to be a mistake. JSP may scale well under load, but, as it turns out, it doesn't scale well under the number of JSP pages. With JSP pages published based on templates into many separate files, each one of these files was compiled into a separate class, leading to a very, very large number of classes. (Under Tomcat running on a Sun JVM, not only does every JSP become a class, but there are tag support classes and method accessors, too.)

Not at all surprisingly, the system eats up the permanent generation heap for breakfast. Not only does the class code get loaded into PermGen, but if I'm not mistaken, all string literals in the code end up there, too. With the content in the JSP page and the JSP page compiled into a class, this means we have the entire web page in PermGen.

This doesn't scale. At all. On the test system alone, with considerably fewer pages than what's expected for the production system, memory consumption is already measured in tens of megabytes. On the production server, we will get into more trouble.


This problem is pretty much inherent in the system. Because Java doesn't unload classes (at least not that I've noticed or heard of) unless the class loader is destroyed (e.g. on webapp reload), every class ever loaded stays in memory forever. Since the JSP specification requires that JSP pages are turned into classes, every JSP page accessed stays in memory forever. Eventually, all JSP pages will have to find space in the server's main memory.

Combine this with a number and size of JSP pages that grows linearly with the amount of content in the site, and you'll soon hit the limits of the hardware (or even software, on 32-bit systems).

This has led me to the following conclusion:

JSP was never meant to serve content in the pages.

The idea behind JSP is pretty much this: servlet loads data from storage, servlet puts data in beans, JSP provides template and fills data in. Any other method is not really supported. 0-tier models are chaos itself and cannot possibly be supported by any system, because the model is unsupportable. But static content publishing is possible with other systems, such as PHP. It is not viable with JSP due to the scaling problems I described.

JSPs are strictly meant to provide a static template. Even large sites would not be expected to have more than, say, a hundred at most, and on average fairly small ones at that. A thousand, even two thousand pages, each one on average containing 2-3 kilobytes of pure content, are not in the plan.

Which means that eventually, we might have to drastically change what we do. Either publish to a dynamically interpreted system like PHP or publish all content dynamically.



Do you agree or disagree with my conclusions? Have you experienced similar problems? Do you know a way out of the dilemma?
[ June 11, 2007: Message edited by: Bear Bibeault ]
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65542
110
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Disagree. Our financial site, with thousands of simultaneous users, serves a wep app composed from many thousands of pages, some bigger some smaller.

I think your issue is more about server management and configuration than coding in JSP.
[ June 11, 2007: Message edited by: Bear Bibeault ]
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think there are always going to be trade offs.

Lets consider one of the alternatives; PHP.

Because each PHP script gets compiled/interpreted when it's called, there is really no upper limit (except for disk size) to the number or size of scripts that can be put into an app. The downside is that each of these has to be read (file i/o is exponentially slower than memory reads) with every hit.
With a small number of users, this might not be noticeable but what happens when you have thousands of users generating hits; each one requiring a disk read and a full compilation/interpretation of each page + included pages with each hit?

Your PermGen space can be increased.
If, your app interns a steady stream of changing literals, then it may be the case that any limit -- no matter how high -- will eventually be hit.
In this situation then there may indeed be a case for changing your architecture or possibly the technology you use.

Does your content management system actually create new JSPs?
 
Sebastian Redl
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ben: I heard the PHP interpreter caches its bytecode, but that's neither here nor there.

Yes, the CMS publishes new JSP pages. The servlet container then picks them up and compiles them. (And of course, this need to keep the recompilation check enabled is a potential source of performance problems, though not one we've run into so far.)

Bear: Do you have any specific suggestions for the configuration? Techniques to reduce the size of each page? Simply put, we're in danger of running out of memory, and I don't mean just PermGen. That can be increased, but only as long as there is physical memory to support it.

Also: is it unusual for a servlet container to have 50% or more of its heap in PermGen?
[ June 14, 2007: Message edited by: Sebastian Redl ]
 
No more fooling around. Read this tiny ad:
the new thread boost feature brings a LOT of attention to your favorite threads
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!