In asp.net application, how its possible to download all png,css JavaScript and other resources parallel.
Because i am monitoring using Fiddler and found that content is downloaded one after another.
That is actually more of a browser (client) behaviour in accordance to the specification in HTTP 1.1. The guideline is to limit simultaneous downloads to two per hostname.
http://www.yuiblog.com/blog/2007/04/11/performance-research-part-4/
While you may be able to alter your browser's settings to download more per hostname, that is only your machine and not that of others' in the Internet wilderness. One way to trick clients in downloading more simulatenously is to designate your web resources into different hostnames, like images stored in http://images.yoursite.com. But you may wanna to test this and balance it out, as per the article's suggestion.
You can try AJAX for that as usually there are 5 allowed server/client http connections you could theoretically use them all at once.
However I guess you will take little advantage of this, unless you have really big (or many) css and javascript files.
Not sure if this will work on images or other files.
Related
As I understand, typical navigation works like this:
The browser sends a request to the server
The server sends back an HTML file
The browser parses the HTML file and figures out which files it needs
The browser sends a separate request for each JS/CSS file
The server sends JS/CSS files back to the browser
Finally, the browser has everything to display the site
Are steps 3 and 4 really necessary?
Why don't we have a server-side list of all files required for the site?
This way the server can send all the files without waiting for the browser.
Here are my best attempts to explain such a design:
Explanation 1: HTML file is more important in the early stages because the browser builds a DOM tree first.
Okey. But we can have a prioritized server-side list of all files required for the site. This way the browser can build the DOM tree and download CSS concurrently.
Explanation 2: search engines don't want to download anything besides HTML.
Yes. But we can add Get-All-Files-Immediately HTTP header for that.
Explanation 3: this is a legacy. We don't want to break old sites.
Yes, we don't. But Get-All-Files-Immediately header will solve that too.
Explanation 4: this overhead is negligible.
Is it so?
Let's look at Dev Tools->Network for facebook.com: :
Steps 3 and 4 happen between points A and B. This seems like a good fraction of TTFP. Am I wrong?
I am very confused as I cannot find one single good reason for such a design. What am I missing?
There is a list of files that the browser needs, it's in the HTML.
It's possible to preemptively send things from server to browser if the server knows the browser will request it in the future via HTTP/2 Push.
This can indeed reduce the total latency. But it also comes with challenges. How does the server know for example that the client doesn't already have the file? Clients will often cache assets like CSS and images, so if a client hits the server again, push those assets again can be wasteful.
The reality is that for most people the first roundtrip to get the HTML is not enough of a problem for it to be worth fixing.
I have this intriguing problem on Azure Website. My website uses 4 script files and 3 style files, each minified. They are not so big, bigest has near 200 KBs. Website had already started. Azure's Always On option is turned on. When I call to WebApi for data it returns in <50ms.
And when app is reloaded it needs 250 ms just to get first byte from tiniest script, and others needs much more. Initial Html is loaded in 60 ms. Scripts/styles are cached so they are not downloaded, but the TTFB time is killing the performance. This repeats every single reload. App is not containing any sophisticated configuration so it should run much faster than it.
What can cause such problems?
Although your static files are cached, the browser still issues requests with if-modifies-since header (which results in a 304).
While it doesn't need to download the actual content, it still needs to wait the RTT + server think time to continue.
I would suggest two things:
Adding Cache-Control and Expire headers - will help avoid 304 in some cases (pretty much unless you hit F5)
Using a proper CDN - such as Incapsula or others, that will minimize the RTT + think time. It can also be used to easily control cache settings for various resources.
More good stuff here.
Good Luck!
From here:
As you saw earlier, IIS 7 caches the compressed versions of static
files. So, if a request arrives for a static file whose compressed
version is already in the cache, it doesn’t need to be compressed
again.
But what if there is no compressed version in the cache? Will IIS 7
then compress the file right away and put it in the cache? The answer
is yes, but only if the file is being requested frequently. By not
compressing files that are only requested infrequently, IIS 7 saves
CPU usage and cache space.
By default, a file is considered to be requested frequently if it is
requested two or more times per 10 seconds.
So, the reason your users are being served an uncompressed version of the javascript file is because it didn't meet the default threshold for being compressed; in other words, the javascript file was not requested 2 times within 10 seconds.
To control this, there is one attribute we must change on the <serverRuntime> element, which controls compression: frequentHitThreshold. In order for your file to be compressed when it is requested once, change your <serverRuntime> element to look like this:
<serverRuntime enabled="true" frequentHitThreshold="1" />
This will slightly impact your CPU performance if you have many javascript files that are being served and you have users quite often, but likely if you have users often enough to impact CPU from compressing these files, then they are already compressed and cached!
My guess would be Azures always on.
If it works anything like the one CloudFlare provides, it essentially proxies the request and tries to cache it.
Depending on the exact implementation of this cache on the side of Azure, it might wait for the scripts output to complete to cache it/validate the cache and then pass it on to the browser.
You might have a chance checking the caching configuration and disable always on for your scripts if possible.
The scripts and styles are static files and by default are compressed (you can check this with HTTP header "content-encoding": gzip) before being sent to client. So, the TTFB consists of network latency, browser HTTP channel scheduling and the static file compression time from server.
On the other hand, your Web API data is dynamic data and by default is not compressed, so possible its TTFB is less than the TTFB for static files.
However, you don't need to switch off static compressing, otherwise TTFB is minimized but content transferring time will be extended. Actually, you don't need to worry about TTFB, see more info: https://blog.cloudflare.com/ttfb-time-to-first-byte-considered-meaningles/
I finished with storing files on Azure Storage and serving them by Azure CDN. It provides high speed of response and costs nothing. I add them to blob every publish, in Pre-build event by Gulp.
well... there are 2 main problems with your site:
you are using AZURE - a high priced service with a poor performance.... don't ask me why people think that this is a good service
you are storing client files side-by-side with the server files.. while server files should be stored in a specific server, client files can practically can be served from... everywhere
so - please use a CDN (or any other server) for your client side files (mainly css and js, you may consider moving fonts and images as well)
I have a web site that reports about each non-expected server side error on my email.
Quite often (once each 1-2 weeks) somebody launches automated tools that bombard the web site with a ton of different URLs:
sometimes they (hackers?) think my site has inside phpmyadmin hosted and they try to access vulnerable (i believe) php-pages...
sometimes they are trying to access pages that are really absent but belongs to popular CMSs
last time they tried to inject wrong ViewState...
It is clearly not search engine spiders as 100% of requests that generated errors are requests to invalid pages.
Right now they didn't do too much harm, the only one is that I need to delete a ton of server error emails (200-300)... But at some point they could probably find something.
I'm really tired of that and looking for the solution that will block such 'spiders'.
Is there anything ready to use? Any tool, dlls, etc... Or I should implement something myself?
In the 2nd case: could you please recommend the approach to implement? Should I limit amount of requests from IP per second (let's say not more than 5 requests per second and not more then 20 per minute)?
P.S. Right now my web site is written using ASP.NET 4.0.
Such bots are not likely to find any vulnerabilities in your system, if you just keep the server and software updated. They are generally just looking for low hanging fruit, i.e. systems that are not updated to fix known vulnerabilities.
You could make a bot trap to minimise such traffic. As soon as someone tries to access one of those non-existant pages that you know of, you could stop all requests from that IP address with the same browser string, for a while.
There are a couple of things what you can consider...
You can use one of the available Web Application Firewalls. It usually has set of rules and analytic engine that determine suspicious activities and react accordingly. For example in you case it can automatically block attempts to scan you site as it recognize it as a attack pattern.
More simple (but not 100% solution) approach is check referer url (referer url description in wiki) and if request was originating not from one of you page you rejected it (you probably should create httpmodule for that purpose).
And of cause you want to be sure that you site address all known security issues from OWASP TOP 10 list (OWASP TOP 10). You can find very comprehensive description how to do it for asp.net here (owasp top 10 for .net book in pdf), i also recommend to read the blog of the author of the aforementioned book: http://www.troyhunt.com/
Theres nothing you can do (reliabily) to prevent vulernability scanning, the only thing to do really is to make sure you are on top of any vulnerabilities and prevent vulernability exploitation.
If youre site is only used by a select few and in constant locations you could maybe use an IP restriction
I would like know how browser executes/processes the request. I would like to know this because knowing how it works will help me understand how better web programming can be done which meets performance goals using browser features.
How browsers download CSS, JS and Image files?
Does it download one resource at a time or multiple?
How many parallel requests (connections) it can make?
What happens if request is getting executed on the server and user click on the stop button? Will the execution get complete and response will come back? Or on server site the request is suspended in half way?
How JS execution is handled by browser?
Please add helpful links/information if possible.
Thanks all,
Please consider splitting this up into multiple questions. Here is some relevant information:
A web browser, or any web client, who wants to retrieve an HTTP resource will construct a GET request. This contains information to route the request to the proper server, and information to tell the server which resource is being requested. A resource can be an HTML page, an image, a Javascript file, or anything else.
When the browser receives an HTML page, the page may have links to other resources (for instance, image tags). These instruct the browser to make further requests.
Multiple resources may be downloaded in parallel. This can happen if your browser is attempting to load multiple pages at once (like in different tabs), or if the browser has received an HTML page that points it to several resources (as in the last point). From a single hostname, the HTTP 1.1 spec says that at most two resources should be downloaded in parallel (though this is just a guideline and cannot stop a browser from attempting to do otherwise).
Javascript is interpreted by the browser, just like other scripting languages are interpreted by their respective engines.
In the usual way (e.g., http GET operation, etc.).
It's implementation-dependent, different browsers do it differently.
It's implementation-dependent; typically, though, no more than two at a time between the same two endpoints (e.g., that browser talking to the same server). May be more if retrieving from multiple servers. Other resources get queued and wait for a slot to open up. This limit is typically enforced by browsers, but may also be enforced by servers (so a browser with this limit lifted may still find that later requests sit waiting for a bit while the server queues them.).
It depends a lot on when they do that, what kind of server it is, etc.
In strict document order. The browser may download multiple script files simultaneously, but it will execute them in document order. This is very important. Further processing of the page may (probably will) get held up waiting for the script to get downloaded and run. (IE supports the defer attribute on script tags that lets you tell it that it can continue processing the page before it executes the script.)
Is HTTP partial GET a reliable mechanism? If it is, how come it seems like modern browsers still start from the beginning instead of resuming the download?
In my experience this feature is not ubiquitous across all web servers. Probably because it is not a widely used by web clients. Sort of like HTTP HEAD requests which may or may not be implemented. As always, YMMV depending on the clients and servers involved.
The download resumption mechanism is based on HTTP range request headers that specify what part of the content you want (see here). I have not messed with this much in the last few years, so you may be better served doing a little more Google research. Here is a link to a blog posting that talks about some the latest developments regarding this feature.
Whenever I download big files with wget, I might interrupt them and resume with -c. I don't remember ever getting a corrupted file. Safari allows you to resume (instead of restart) a stopped download, works fine there too.
Yes, when done properly (If-Match etag...), it is reliable.