-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kiran,
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
>> catalina.properties 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBXVMAACgkQ9CaO5/Lv0PAblACeL0x/MUojaJYqAQf0GCcWO7Vp
l50Anjt5IOAuB/TxPmiE2rC19sM0Ylp9
=4Hcc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
