May 11, 2002 at 11:03 am
Ok, great! Thankx
quote:
In that case it really would be up to you. Sorry no help there but this runs into how much trouble is it to do the DB store or should you just use pointers. In that case I would go with FileSystem personally as is quite a bit easier to implement and your concerns are just that how easy is it to do."Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 11, 2002 at 12:36 pm
Agreed that you suffer an increase in network traffic. But for an internal link its easy to add more, a 1g card or two tends to eliminate the bottleneck. If you're looking at scale out seems like having the images in db means you can rely on replication rather than having to deploy the images to each web server. In no case would I recommend putting IIS and SQL on the same box!
Andy
May 11, 2002 at 1:02 pm
Is this only to avoid CPU Overload. Or are there any other reason for such an advice from you?
quote:
In no case would I recommend putting IIS and SQL on the same box!Andy
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 11, 2002 at 2:35 pm
Just load in general. In any but the smallest of operations you want to give SQL exclusive use of a server, that way it can use basically all the memory, not contend with other processes for disk access, etc.
Andy
May 11, 2002 at 7:14 pm
Andy does hit some great extra points there especially if you have multiple IIS and/or SQL server serving the data. Ultimately still boils done to the most convient way to ensure that you are able to server your data as quickly and accutrately as possible. As for multiple IIS servers you could create a replicated directory to store them that way they get moved to the other servers when you change the main one.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 12, 2002 at 8:49 pm
There's no reason why a DB hosted image source can not be fast and efficient.
The problem re ASP mime type is a nonsense also, since if you are returning an image and text.
The text could be embedded in the first result (if it happens to be what's already being handed back), with an embedded URL to the image.
When the browser gets the result, it will see that it then needs to go and fetch the image, which by itself, will be the jpg/bmp MIME type.
If you are worried about performance, you can front end your IIS server with a caching web server, such as Microsoft ISA server, which will, according to the TTL information, hang on to an image, and serve the same image up from local cache, rather than going back to IIS, which would then fetch from the DB.
Clear as Mud?
May 12, 2002 at 10:03 pm
I didn't notice there was a second page to this discussion until after I replied, and I now see that pbelb pretty much said it, but here's a reply w/ semi-example:
----------------
I don't think you have to set it twice in one page, but in two pages. One is HTML including code something like: <img src="/bin/imgsrvr.asp?id=i/img123.gif"> and the other is imgsrvr.asp, which takes a URL variable, hits a database for the image file, sets its content type as image/gif or whatever and then serves the image.
This is untested by me, but it seems sound.
(I added the "i/img" and ".gif" so that the browser would hopefully take that as the filename in case of a right-click > Save as.... The ASP would dump that stuff before getting the binary for image 123.)
-john.
quote:
How do you set contenttype for one response object? It can be sent only once. If you are able to do it twice on the same page, pls let me know how did you manage to do it.If you do have a ready example, pls send.
Edited by - duelin_markers on 05/12/2002 10:08:49 PM
May 12, 2002 at 10:13 pm
I have tried changing the contentype. But it does not change once set. I changed it first to image/gif and then when i want to write html text next to image i changed it to text/html. but then was unable to do so. and the problem is also that when u set the content type of that page as image/gif, you cannot have any kind of extra html text on that page. You need to have that page as a pure ASP page, not even a blank line in html is permitted.
quote:
I didn't notice there was a second page to this discussion until after I replied, and I now see that pbelb pretty much said it, but here's a reply w/ semi-example:----------------
I don't think you have to set it twice in one page, but in two pages. One is HTML including code something like: <img src="/bin/imgsrvr.asp?id=i/img123.gif"> and the other is imgsrvr.asp, which takes a URL variable, hits a database for the image file, sets its content type as image/gif or whatever and then serves the image.
This is untested by me, but it seems sound.
(I added the "i/img" and ".gif" so that the browser would hopefully take that as the filename in case of a right-click > Save as.... The ASP would dump that stuff before getting the binary for image 123.)
-john.
quote:
How do you set contenttype for one response object? It can be sent only once. If you are able to do it twice on the same page, pls let me know how did you manage to do it.If you do have a ready example, pls send.
Edited by - duelin_markers on 05/12/2002 10:08:49 PM
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 12, 2002 at 10:21 pm
You're sounding like a broken record.
A single response can only have a single MIME type.
Therefore, you need 2 distinct responses.
The first response would be the text response, which includes an image URL link to the actual image.
In this way, when the browser sees the URL for the image, it will then make a 2nd request, entirely distinct from the 'outer'/first request, to haul back the image.
2 requests, 2 different MIME types.
The 1st response has the URL which the browser follows to get the image.
May 12, 2002 at 10:45 pm
this is what i'm hearing something new! Is it possible to create new response objects in ASP
quote:
You're sounding like a broken record.A single response can only have a single MIME type.
Therefore, you need 2 distinct responses.
The first response would be the text response, which includes an image URL link to the actual image.
In this way, when the browser sees the URL for the image, it will then make a 2nd request, entirely distinct from the 'outer'/first request, to haul back the image.
2 requests, 2 different MIME types.
The 1st response has the URL which the browser follows to get the image.
Paras Shah
Evision Technologies
Mumbai, India
Paras Shah
Evision Technologies
Mumbai, India
May 13, 2002 at 7:23 am
Ok, it seems you're not quite 'getting' it, so here's another approach to the description:
when a user browses to your top level url, here is the sequence of events:
Browser sends request -> asp.
asp replies (mime=text) with a page containing text description + an image html tag (not the image itself, but a URL telling the browser where to find the image) -> browser.
Browser now examines response it's gotten back and displays it. At this time, the browser has not yet got the image itself, but knows what URL to get it from, via the image tag values.
The browser, having completed the initial display, has most likely generated a list of items which it then needs to make additional requests for (ie: to fetch the image).
The browser now works it's way through that list of secondary requests it must make (some browsers can initiate multiple such additional requests simultaneously). At this time, the browser sends a request to the server (the URL for the top level page could be quite different than that of the image).
When the image response comes back, the browser must now organise for the image to be rendered according to whatever image type and display size has been given it (some browsers will scale by default, others only when instructed/required to), and for the image to be displayed on screen.
Does this help?
Another view:
If you go to any site which is heavy on graphic content, say http://www.cnn.com, if you use your mouse and position the pointer over each image, you will find that each of them has a unique URL. I like internet explorer, and it shows such URLs in the bottom status area. This is where the image came from, and it was fetched by the browser from that location as a distinct request, one per image. The page you see was not delivered to the browser as a single response, but many responses. If you look at the source for the top level page, you'll find it's often a collection of references to other pages - some containing graphics, others not, but almost never will the top level page be a simple graphic. The browser makes many, many requests on complicated pages, to fetch all of the response elements which make up the page you see. It all happens rather quickly if you have good connectivity with the server, but rest assured, that's what's happening.
May 13, 2002 at 12:56 pm
quote:
It all happens rather quickly if you have good connectivity with the server, but rest assured, that's what's happening.
Maybe the simplest way to think about this and realize what's happening is to think about a really slow connection and a page with a lot of images. What you see happening is the main page with text is displayed initially, and then each of the images is requested in a successive round of requests and loaded. That's why you notice the delay and yet can read the text while waiting for the image, because it's done in rounds, not all as one shot.
BTW, my preference is to store images at the OS because, to me, it is conceptually simpler and I don't have to worry about uploading images to the SQL Server or any hassle in updating them. I also don't have to worry about this "page within a page" method.
May 13, 2002 at 3:26 pm
Without a doubt, as a DBA or a developer, storing the images in the same DB as the rest of the data is the best way to handle it.
Developer point-of-view: if I store the images on the filesystem, I have to write extra software to clean up the file system in case the DB and the file system get out of synch; if the images are stored in the DB I can set up relational integrity to ensure that the files do not get out of syncg with the other data
DBA Point-of-view: if I have to administer a DB that contains pointers to the file system and the DB gets out of synch with the files, who is responsible? Everyone blames the DBA so if everything is in the DB, the DBA can ensure that there are reliable backups of the DB and "files" that are synchronized and, more importantly, can recover both to a specific point-in-time.
The only case I can see against this is lack of network bandwidth but this can be handled by proper cache settings on the web or application server (this is especially easy with VS.NET).
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog
May 13, 2002 at 5:14 pm
OK, my point of view is this:
You should only ever query the database for truely dynamic data, otherwise you are wasting roundtrips and degrade performance. By 'truely dynamic' I mean something that will be different depending upon the parameters you pass. Eg If your image files were graphs and were built on the fly. If you just want to serve the same image every time a page is called, then querying the DB is inefficient. This leads to using the file system, but why not store the images in the database for ease of management and have a trigger to write the images to the filesytem if it gets updated. That way you get the best of both worlds! I like the caching suggetion above, I believe that advanced caching is one of the advantages of ASP.NET, although I don't know enough yet about this yet to go into any detail.
May 14, 2002 at 5:54 pm
I need to store files upto 6MB, there will be mostly inserts and reads and maybe some updates (very few though). I have the choice of either using the file system or the text field in the database.
If I create a single table with just an index and a text field to store text files upto 6MB. I will be purging or archiving this table so I don't expect more than 500,000 records ever in this table. If bandwidth between the IIS and SQL SERVER is not a concern, are there benchmarks to say what approach is faster.
Something that has not perhaps been addressed in this discussion is: Will inserting text rows in the database become slower when we go in the hundred thousand range. Would there be defragmentation perhaps because of the way SQL Server stores data internally. Would inserts maybe take longer than storing on the file server but maybe the SELECTS will be a little faster. Would even the 'SELECTS' become a little slower if there is defragmentation.
Looking forward to hearing on these issues.
Viewing 15 posts - 16 through 30 (of 30 total)
You must be logged in to reply to this topic. Login to reply