tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Where do I store Images in tomcat structure so that I can retrive it properly in all browsers
Date Mon, 17 Sep 2012 16:50:08 GMT
Hash: SHA1


On 9/13/12 8:24 PM, Kiran Badi wrote:
> On 9/13/2012 8:13 AM, Christopher Schultz wrote:
>> Large sites will use a single URL that ends up resolving the
>> images from some kind of data source. That data source might be a
>> disk (e.g. you could forward to the DefaultServlet) or a database
>> (relational or otherwise) where you would write your own servlet
>> to retrieve the data yourself.
>> I would use a servlet that gets the image identifier from the
>> request parameters or "path info" and then continues from there.
>> As Konstantin points out, using Tomcat's "aliases" feature means
>> that these requests may have to perform a linear search through
>> all the aliases to find the requested resource. If you write a
>> custom servlet, it will likely perform much better than that.
> this is what I am doing it right now and maybe bit different from
> what large sites do.I can see the point and can write filter which
> will scan the request url and point it to respective images
> directory and then serve it.
> I store the images in the respective directory, for example for
> category A with subcategory sc, I store in C://A/sc and then write
> images names to the database.
> and via jsp
> I get this in this format,
> img src ="A/test/{Imagename}" with image name coming from the
> database.
> Below is way it looks in requests.
> URL    Method    Result    Type    Received    Taken    Initiator 
> Wait‎‎    Start‎‎    Request‎‎    Response‎‎    Cache read‎‎ Gap‎‎

> /our/UploadedImages/sc/cl1.jpg    GET    200    image/jpeg
> 40.73 KB    0.54 s    <img>    219    0    405    141    0    967 
> /our/UploadedImages/sc/cl2.jpg    GET    200    image/jpeg
> 45.33 KB    327 ms    <img>    219    0    249    78    0    1186 
> /our/UploadedImages/sc/cl3.jpg    GET    200    image/jpeg
> 26.39 KB    405 ms    <img>    219    0    140    265    0    1108 
> /our/UploadedImages/sc/cl4.jpg    GET    200    image/jpeg
> 40.73 KB    0.51 s    <img>    219    0    281    234    0    998 
> /our/UploadedImages/sc/cl5.jpg    GET    200    image/jpeg
> 23.43 KB    0.51 s    <img>    219    0    405    110    0
> However I am not getting if I am writing the single servlet which 
> resolves the images uri, how will it help in improving performance
> ? If Images are in different directories, isn't tomcat needs to
> scan that directory and resolve it?

I'll explain below.

> Initially I had a single directory,but though it would be nightmare
> in case of maintenance, so thought of refactoring it now.
>> 3. Having 200 aliases means that Tomcat would have to try 200 
>> different prefixes for each resource lookup. Maybe it would not
>> be noticeable (compared to the other time spent in delivering a 
>> response), but it still seems like a waste of time.
> Why should it do resource lookup when I am telling it to look at
> the exact directory by giving it the exact name of the file ? In
> fact while storing also I am giving it the exact directory path to
> where it needs to store ?

Tomcat keeps a list of aliases that you configure. I haven't looked at
the lookup algorithm but a reasonable implementation would be to store
all the aliases in a big unsorted list and scan them linearly each
time. If you configure 200 aliases, Tomcat will have to scan, on
average, 50% of them to find the alias being used if a match is going
to be found (it's worse when you know a match won't be found, because
Tomcat has to scan all 200 aliases and not find a match). Since
"aliases" are applied to all URLs, that means that even requests for
non-images will require Tomcat to scan this list. (I'm not sure how
the precedence works with url-mapped servlets, etc... it's possible
that Tomcat will route requests to servlets that have a mapping that
that aliases will not come into play).

By "scan" I really mean prefix-match: you have to take the incoming
URL and see if *any* of the aliases match. There is no good way to
optimize that operation because it's a prefix match of paths.

If you instead implemented your own "aliases" feature using a servlet,
you could do it in a smarter way because you understand your own URL
space: you might always know that /images/X will translate directly
into /file/place/on/the/disk/X and you don't have to do a prefix
match. You could do something like this:

// configured once
Map<String,File> dirMapping = ...;
String imageURIPrefix = "/images/";

// For each request:
String uri = request.getRequestURI();
String imageDirStr = uri.substring(0, uri.indexOf('/'));
File dir = dirMapping.get(imageDirStr);

Now you know where your file should be, and there wasn't any linear
lookup: it was all done using hashes.

> Do you believe my understanding the way aliases works is incorrect
> ?

I'm not sure what your understanding of aliases is.

>> [Konstantin Kolonko said:] 2. It is possible to define a system
>> property (via -D in the options list at startup, or via
>> file) and reference it as ${propname}.
> This approach will require me to refactor my existing code,so I
> will think of using this in my next module.

Probably not: the suggestion was to use, say, ${imagePrefix} in your
context's aliases setup to simplify the re-location of your image root
on disk.

> There are couple of things I am planning to get it dynamically ,but
> again somewhat scared if I can ever write thread safe
> servlets/classes which can serve multiple concurrent requests.

There's really only one rule for servlet programming:

Don't use class-level data that changes.

There are other considerations, of course, but a servlet is not a
sacred beast. There's only one way to learn how to do it properly:
fall on your face a few times. :)

> Currently I have close to 50% of code which is reused.But I need to
> deal with this sooner the better else I am going to have war file
> which will be atleast 40mb in size with unmanageable number of 
> jsp/servlets/beans.
> Thanks Chris and Konstantio for replies.Currently I am on
> 7.027/7.011 and maybe after some days, I will upgrade to 7.030 or
> still better have one more TC for testing purpose.

7.0.30 has some significant memory optimizations. You might want to
upgrade sooner rather than later.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


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

View raw message