I have a website(www.mydomain.com) which has admin panel(admin.mydomain.com). All images I uploaded through admin panel are stored in sub-domain(admin.subdomain/Content/Images/image1.jpg).
Now I need to load these images in my website, for that I have option to assign image's url as src = "admin.subdomain/Content/Images/image1.jpg".
My question is, will it cause performance problem to load images through url rather than giving Image path, if not then I'll go with it, if yes then how to overcome this.
There are two things that will affect performance:
Sending out the a full domain to the browser will be sending more bytes. It's the difference between /images/whatever.jpg and http://admin.somedomain.com/images/whatever.jpg. However, this is such a tiny difference, you would need to be running at massive scale to notice any difference on your bandwidth, and certainly a client wouldn't see any difference.
Browsers will only open a limited number of connections to the same domain. This means if you host Javascript files, images, CSS etc. on the same server, the browser will queue up those requests. So hosting your images on another domain allows the browser to download them at the same time, making the whole process faster. That's why many sites will use a CDN to host their resources. For example, take a look at this site. Even the logo is hosted on cdn.sstatic.net
Related
We have a need to re-size large images to a smaller size before they go down to the end user. (End users are global and can be on slow connections.) The main server, a portal server(plumtree), generates the image link for the user's browser and the browser then requests the image from a different server (Aqualogic).
Unfortunately the AL server doesn't always have the smaller copy of the file, because the re-size process has been manual in the past and hasn't happened with regularity.
To remove the manual step from the need, I created a simple HttpHandler web site on yet a 3rd server which takes the requested image, goes to the AquaLogic server with a WebRequest and downloads the full size image, re-sizes it on the fly and then sends the result down to the requesting user's browser.
Now my boss is asking me what the impact on the 3rd server (which is our production web server cluster) will be. He wants metrics on processing load and bandwidth usage. How can I measure this? CAN I measure this?
Bandwidth usage should be simple to approximate if you keep track of the size of the original image and the size of the resized image.
There are profiling tools available that can help you determine the processing load such as ANTS.
I'm working on a stock-standard, ASP.NET MVC 3 web application (hosted on IIS 7). The site allows users to upload photos, among other things.
The upload process is as follows:
User makes use of widget (currently plupload) to select files from their PC.
AJAX call happens to my server, with image in HTTP POST (Request.Files)
Server resizes photo N amount of times
Each resized photo is uploaded to Amazon S3
At the moment, the above is implemented with a "fire and forget" technique using .NET 4.0's TPL.
I would like to make the above more flexible and robust. For example, if the image processing fails (it's using GDI, so it's likely), or S3 is down (which happens), i or the user won't know about it.
I'm thinking about hosting a WCF service as a Windows Service, which polls a folder for images.
My main website would simply FTP the image to the "watched" folder, then the service would take care of the image processing and the uploading.
The user doesn't need to be notified "immediately" that the photo is done. In other words, right now we show a "your image is being processed and will be available shortly" message.
To sum up, the service needs to:
Resize images
Upload images to S3
Read/write to database
Ability to "retry" failed images
Any advice? Is FileSystemWatcher a good option?
In my current project we implemented a similar middleware service responsible for data processing using FileSystemWatcher with relative success. Some things to remember about:
Be sure to implement some sort of queueing for core processing. Starting 100 image conversion processes at the same time is not a good idea. Consider using a ThreadPool.
FileSystemWatcher will give notifications as soon as the file gets created, at which point it may still be write-only locked - you will have to perform periodic checks to determine the right moment to start processing. Probably using a main loop and a queue.
Keep track of finely grained status changes (like file_created, file_processing, file_processed, file_uploading etc). You might really need them for debugging.
Hope this helps and good luck.
is there any easy way to show images in asp.net page from a ftp server?
If your password is secure then follow below steps :-
You really should create an FTP account that only has access to the folder with the images on your FTP server. Do that as soon as possible.
For a better overall solution, either synchronize the images to your webserver, or write an HTTP handler that will fetch the image server-side and streams the bytes to the client as if the image was on your server. Have a look at System.Net.FtpWebRequest for the second solution.
If you have write access to disk on the web server, you could implement both parts of the solution. So if an image is fetched the first time, write it to disk before sending it to the client. The next time it's requested, simply redirect the request to the image on disk (or dynamically change the URL of the tag for that product). This way, you build a cache of the images on your web server as time passes. Of course, you need to be able to invalidate the cache in case an image is updated.
<img src="ftp://..."/>
I see a ton of questions about uploading multiple files, but none about uploading a single file to multiple servers, so here goes...
I have an ASP.NET app that will be running on two load balanced servers, and I would like to allow users to upload files and have them end up on both servers. What is the cleanest way to do this? I am using IIS 6 btw.
Some ideas that come to mind are:
1) Use a virtual directory that points to some shared location that both servers can access. Will there be any access issues if the application runs at Network Service? I'm assuming the application will need to run as a user account that exists on the shared location machine. How should the permissions be set for this?
2) It would be nice if I could via jQuery post the request to both of my servers, referencing them by their port numbers. Even though the servers are on the same domain, this violates the same origin policy, right?
Is there another solution I'm overlooking? How do other sites do this?
I think you want to consider this problem more carefully - having a pair (or more) of servers means that some of them will be offline some of the time (at least for occasional reboots).
Uploads when not all of the servers are online won't be able to be sent to all servers immediately, so you'd need either an intermediate server (which would be a point of failure unless it was highly available itself) or a queuing system to "remember" which files were where, and to transfer them when the relevant servers were restored.
Also, you'll want a backup system, and some way to add newly provisioned servers to your cluster. You will also want a way to monitor these files are the same in case they get out of sync. Your architecture needs a lot of careful thought. I don't have the answers :)
The cleanest approach is forwarding the files server-side, really. If you force two uploads via JavaScript, not only will you have to worry about working around XSS safeguards, but you'll also force the user to use their very limited upstream bandwidth twice for each file.
You shouldn't be exposing that kind of detail to the client anyway. The browser doesn't need to know where the file ends up, just who to send it to. If you keep that logic server-side, not only do you keep the details hidden (and thus less prone to errors and exploits), but you'll also get more control over the process. You can create a gateway service later that handles a multitude of back end storages and you can handle failing servers better. You can queue failed uploads and retry. All these come at a very low cost if you do them on the server side, but are a pain to be made to work reliably on the client side.
Keep back end logic to your back end. Load balancing should be hidden from the user, so there's no need to tell them where they are sending their files exactly. Make it optional, if you want, but hide the action from them. Just swallow the file on the gateway server (which can be either of the load balancing servers -- in fact, it should probably be load balanced, too, so it should work with either of them in place) and send it to the other servers from there. The transfer from server to server will probably be faster too.
Your best bet is definitely a NAS, if one is available -- a shared file system that is not specifically associated with any machine. Then you can focus on making the NAS highly available via a clustered frontend.
If that's not an option, you can use a virtual directory on each machine that points to one folder on one of the machines, but then you lose redundancy.
I'm faced with this same challenge at my work. My app is small but needs to be highly available, but there's no NAS in sight. So in each machine's web.config I place a list of all the UNC paths that the uploaded file should be stored. After uploading to a temp folder, I copy the file to each machine one by one. It's not perfect -- a machine could go down, in which case when it came up it might not have all the files (and the copy would be slowed by the hunt for the missing machine) -- but in my situation uploads are so infrequent that it's not worth improvement.
As others have mentioned, Javascript is right out. Upload once.
I have seen this problem solved with a NAS, using credentials for the app pool that can read/write files to that NAS. Make sure your NAS is setup for high availability to prevent single point of failure ie:hot swap w/ raid, multiple array controllers, power supplies..etc
You could also put folder monitoring software on the severs that keep certain directories in sync. I don't recommend this solution.
I am scratching my head about this. My scenario are that I need to upload a file to the company server machine(to a folder on c:) from our hosting one(totally different server). I don't know how I should do this. Any of you got tips or code on how this is done.
Thanks Guys
I would set up an FTP server (like the one in IIS or a third-party server) on the Company Server. If security is an issue then you'll want to set up SFTP (secure FTP) rather than vanilla FTP since FTP is not a natively secure transfer protocol. Then create a service on the Hosting Server to pick up the file(s) as they come in and ship them to the company server using C#/.NET's FTP control. Honestly, it should be pretty straightforward.
Update: Reading your question, I am under the strong impression that you will NOT have a web site running on the company server. That is, you do not need a file upload control in your web app (or already know how to implement one given that the control is right in the web page toolbox). Your question, as I understand it, is how to get a file from the web server over to the company server.
Update 2: Added a note about security. Note that this is less of a concern if the servers are on the same subdomain and won't be routed outside of the company network and/or if the data is not sensitive. I didn't think of this at first because I am working a project like this now but our data is not, in any way, sensitive.
Darren Johnstone's File Upload control is as good a solution as you will find anywhere. It has the ability to handle large files without impacting the ASP.NET server memory, and can display file upload progress without requiring a Flash or Silverlight dependency.
http://darrenjohnstone.net/2008/07/15/aspnet-file-upload-module-version-2-beta-1/
There isnt enough info to tell your whole hosting scenario but I have a few suggestions that might get you started in the right direction:
Is your external server owned by another company or group and you cant modify it? If not you might consider hosting the process on the same machine, either in process or as a separate service on the machine. If it cannot be modified, you might consider hosting the service on the destination machine, that way its in the same place as the files need to show up at.
Do the files need to stay in sync with the process? I.e. do they need to be uploaded, moved and verified as a single operation? If not then a separate process is probably the best way to go. The separate process will give you some flexibility, but remember it will be a separate process and a separate set of code to manage and work with
How big is the file(s) that are being uploaded? Do they vary by upload? are the plain files, binaries (zips, executables, etc)? If the files are small you have more options than if they are large. If they are small enough, you can even relay them in line.
Depending on the answers to the above some of these might work for you:
Use MSMQ. This will work for simple messages under about 3MB without too much hassle. Its ideal for messages that can be directly worked with (such as XML).
Use direct HTTP(s) relaying. On the host machine open a HTTP(s) connetion to the destination machine and transfer the file. Again this will work better for smaller files (i.e. only a few KB since it will be done in-line)
If you have access to the host machine, deploy a separate process on the machine which builds or collects the files and uses any of the listed methods to send them to the destination machine.
You can use SCP, FTP (of any form SFTP, etc) on either the host machine (if you have access) or the target machine to host the incoming files and use a batch process to move the files. This will have a lot of issues to address, such as file size, keeping submissions in sync, and timing. I would consider this as a last resort, depending on the situation.
Again depending on message size, you could also use a layer of abstraction such as a DB to act as the intermediate layer between the two machines. This will work as long as the two machines can see the DB (or other storage location) and both act on it. SQL Server Service Broker could be used for this purpose (and most other DB products offer similar products).
You can look at other products like WSO2 ESB or NServiceBus to facilitate messaging between the two apps and do it inline.
Hopefully that will give you some starting points to look into.