-----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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org