If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Unanswered: bringing down a BLOB

I have some voice files. They can be any where from .5Mb to a few Mb. I am thinking of keeping them in a BLOB in a table on the remote SQL server so I can download them to a few different servers when needed. I am worried about transfer times and CPU usage. I only plan to transfer these voice files a few times per day, but I have certain other traffic that is more important and must take precedence. Is there any way to set the "priority" of this data? I am using cheap linksys routers. Do I need to take care of this from the router side or is there a way to take care of this from the SQL server side?

Re: bringing down a BLOB

Originally posted by wooliewillie
RE: I have some voice files. They can be any where from .5Mb to a few Mb. I am thinking of keeping them in a BLOB in a table on the remote SQL server so I can download them to a few different servers when needed. I am worried about transfer times and CPU usage. I only plan to transfer these voice files a few times per day, but I have certain other traffic that is more important and must take precedence. Is there any way to set the "priority" of this data? I am using cheap linksys routers. Do I need to take care of this from the router side or is there a way to take care of this from the SQL server side?

Q1 Is there any way to set the "priority" of this data?
A1 Yes, but the answer is not as easy as one might hope. Generally, implementing QOS can be an effective way to control prioritization of network traffic. However, to work as intended for your situation QOS needs to implemented it into application(s) (and your network infrastructure) at various levels. MS supports QOS via QOS API calls; this route will involve some development effort, however. I cannot comment on your hardware support of QOS.
It might be easier to simply schedule your transfers for times when traffic is usually low, or you could monitor traffic via some software agent and interactivly have that agent fire off lower priority transfers (based on traffic criteria you design).

I should have mentioned that I only have control over the client. The SQL Server machine is at a hosted site and thus I have no control over its routers. I am thinking now to either 1) make zones, where at night I would transfer the voice files to all of the servers in the zone so no transfer need be done during the day. The only problem with this is that if someone logs off and then logs on within a single day (very likely) they may get a different server (randomly) and thus no voice file untiol the next day.
2) instead of saving the voice file in a blob on the sql server, offering to transfer it back to the user's PC when they log off the system, and next time they log on, ask if they want to upload it. This way I get arround this important issue. And also don't use a BLOB.
3) make sure they support routers that support quality of service, get the same routers at my sites, code to turn on the QOS bit during a transfer via some API. (this will take lots of investigation).

Re: bringing down a BLOB

Originally posted by wooliewillie
RE: 2) instead of saving the voice file in a blob on the sql server, offering to transfer it back to the user's PC when they log off the system, and next time they log on, ask if they want to upload it. This way I get arround this important issue. And also don't use a BLOB.
3) make sure they support routers that support quality of service, get the same routers at my sites, code to turn on the QOS bit during a transfer via some API. (this will take lots of investigation).

I am leaning towards #2 at this time. Does it sound reasonable?

Q1 Does it sound reasonable?
A1 If it meets your needs, yes. 3) would likely take significant effort.

There is actually one more possibility. How about if I get a external hard-drive system that attaches via ethernet so any of the servers can access the file. Of course, I will most likely need two NIC cards in each PC; one for the internet and one for the harddrive. Otherwise I will still be clogging the pipes with a really big file.

Originally posted by wooliewillie
RE: There is actually one more possibility. How about if I get a external hard-drive system that attaches via ethernet so any of the servers can access the file. Of course, I will most likely need two NIC cards in each PC; one for the internet and one for the harddrive. Otherwise I will still be clogging the pipes with a really big file.

S1 Essentially that sounds like creating a private 'utility' network. It can work quite well for things like backup dump access to local NAS storage, large audio files, etc.; as long as you pay proper attention to possible issues (especially routing and looping). I have seen cases where ill considered implementations have created lots of network performance degradation (massive looping problems, excessive chatter, and what not).