velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Riek <>
Subject Re: Performance of Separate Instance vs Singleton ?
Date Tue, 12 Nov 2002 04:00:01 GMT

Thanks for the confirmation and speedy reply, Geir. Set my mind at ease.
 "Geir Magnusson Jr." <> wrote:

On Monday, November 11, 2002, at 10:26 PM, Stephen Riek wrote:

> I may be misunderstanding the Velocity architecture. When
> used as a singleton in a website where almost all pages/requests
> use Velocity templates, would the Velocity engine then become
> the limiting factor or bottleneck since there may be many
> simultaneous requests but only one Velocity Engine to handle
> them ?

No - it just means that any usages of Velocity w/in the same JVM will 
share the same instance, which really boils down to the same 
configuration and resources (such as cached templates...). [This 
doesn't apply when using Velocity in a servlet 2.2+ container where the 
velocity jar is in each webapp, and there is more than one webapp, but 
this is a fine point...]

> The Separate Instance docs state that "New in version 1.2, the
> separate instance allows you to create, configure and use as
> many instances of Velocity as you wish in the same JVM (or web
> application.) " This means that I could create, say, 10 Velocity
> engines, but how do I direct the servlets to share these in
> much the same was as a database connection pool will be shared
> between several threads ?

No need. The reason why you would do this is to keep those 
webapps/servlets from using the same set of cached templates, or if you 
wanted each to have a different configuration.

There are places where access is synchronized to resources, but 
compared to the cost of processing requests or rendering, the overhead 
of such serialization should be negligeable.

Geir Magnusson Jr 203-355-2219(w)
Adeptra, Inc. 203-247-1713(m)

To unsubscribe, e-mail: 
For additional commands, e-mail: 

Get a bigger mailbox -- choose a size that fits your needs.

  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message