The first test is always slow. The second test shows the speed benefits of Cloudflare. Why is that and does this mean users will have to load the website twice?
"speed benefits of Cloudflare" could be referring to a variety of unique features that Cloudflare offers (such as image compression, lazy loading javascript, etc.). For this answer, I am assuming that you are referring to its CDN/caching capabilities.
Essentially, being a CDN means that a client needs to request one of your site's resources from each of the CDN edge nodes to prime the cache at that node from the origin server.
GTmetrix is similar to a human website visitor in the sense that if it is the first to request a resource within its cache timeout from a CDN edge node, the request will have to go all the way back to the origin server rather than responding from the closer edge node. The second time that resource is requested from the edge node, however, the resource will be cached and will be served much quicker due to the reduced network latency.
I'd recommend reading up a bit more on how CDNs work if you are not already familiar with that. You will probably want to tweak your caching headers so that resources that are relatively static are rarely purged from the edge nodes which will reduce requests with this "first-timer penalty".
Related
I'd like to implement a fast, smooth search. Searched items are not that many: ~100 max. Each item holds the amount of data a facebook event would hold. They will all show up on initial load (maybe an infite scroll). Data won't change frequently. No more than 100 concurrent users.
What's the best caching strategy for search results, given above conditions?
What's the most scalable strategy?
Stack
Frontend: Nuxt (VueJS) + InstantSearch (no Algolia!)
Backend: Spring boot
Dockerized
Possible solutions
Extra caching service on the backend (e.g. reddis, memcached) + make UI go to sever on each search operation. This would basically spam the backend on each keystroke
Load all items into local storage (e.g. Vuex) and search there directly. This will increase the app's memory footprint and may turn out messy overtime.
A combination of the two?
A cache layer definitely doesn't hurt. The user amount shouldn't be an issue. Even the smallest ec2-instance on aws could handle that easily.
You could try and add a tiny bit of delay in the textbox so not every keystroke fires a search but maybe give a leeway of ~50ms? Gotta try and see how it feels when typing in the searchbar.
For 100 items Vuex can be quite fast too, as long as you don't load static assets like images directly into Vuex. ~100 items in JSON data isn't a lot - but it doesn't scale as well if your app suddenly has 10000 items.
Best scenario in my opinion:
Redis cache because a lot of the requests will be very similar or even identical. You'd just need to find a sweet spot on how long the cache is valid
Load balance your backend and frontend i.e. create more instances of your docker-image on demand to handle potential spikes in requests if CPU-usage goes above a certain threshold
If your backend does more than just search, outsource that search to a dedicated instance so it doesn't interfere with the "regular requests"
Very important: Create indices in your database for faster search results, avoid full scans whereever you can!
Maybe think about going serverless if your app doesn't have traffic 24/7
Edit: - have the api, cache and database close by eachother so communication between the instances don't have to travel far.
My project uses the Presets plugin with the flag onlyAllowPresets=true.
The reason for this is to close a potential vulnerability where a script might request an image thousands of times, resizing with 1px increment or something like that.
My question is: Is this a real vulnerability? Or does ImageResizer have some kind of protection built-in?
I kind of want to set the onlyAllowPresets to false, because it's a pain in the butt to deal with all the presets in such a large project.
I only know of one instance where this kind of attack was performed. If you're that valuable of a target, I'd suggest using a firewall (or CloudFlare) that offers DDOS protection.
An attack that targets cache-misses can certainly eat a lot of CPU, but it doesn't cause paging and destroy your disk queue length (bitmaps are locked to physical ram in the default pipeline). Cached images are still typically served with a reasonable response time, so impact is usually limited.
That said, run a test, fake an attack, and see what happens under your network/storage/cpu conditions. We're always looking to improve attack handling, so feedback from more environments is great.
Most applications or CMSes will have multiple endpoints that are storage or CPU-intensive (often a wildcard search). Not to say that this is good - it's not - but the most cost-effective layer to handle this often at the firewall or CDN. And today, most CMSes include some (often poor) form of dynamic image processing, so remember to test or disable that as well.
Request signing
If your image URLs are originating from server-side code, then there's a clean solution: sign the urls before spitting them out, and validate during the Config.Current.Pipeline.Rewrite event. We'd planned to have a plugin for this shipping in v4, but it was delayed - and we've only had ~3 requests for the functionality in the last 5 years.
The sketch for signing would be:
Sort querystring by key
Concatenate path and pairs
HMACSHA256 the result with a secret key
Append to end of querystring.
For verification:
Parse the query,
Remove the hmac
Sort query and concatenate path as before
HMACSHA256 the result and compare to the value we removed.
Raise an exception if it's wrong.
Our planned implementation would permit for 'whitelisted' variations - certain values that a signature would permit to be modified by the client - say for breakpoint-based width values. This would be done by replacing targeted key/value pairs with a serialized whitelist policy prior to signature. For validation, pairs targeted by a policy would be removed prior to signature verification, and policy enforcement would happen if the signature was otherwise a match.
Perhaps you could add more detail about your workflow and what is possible?
If I have four identical servers hosted on AWS EC2, divided into two groups and the each group is located in different AWS regions. There is one ELB in front of each group. I configured two weighted alias records (not latency based) point to the ELB of each group in the AWS Route53.
Each server has a simple apache2 server installed which display a simple page with different words to distinguish from each other. I started a browser client (made by Selenium library) frequently reloading page with the URL which is the domain name of these servers (pause for 1 seconds) but I found that that the browser (firefox) always return pages from servers in one group instead of returning pages from both group in 50% times as how Weighted Round Robin works.
I also found that if I pause for a relatively longer time, pages from the other group do get returned but as long as I refresh the page frequently. It never changes. Request always hits one group not the other.
I also wrote a simple Java program to keep querying the domain name from AWS Route 53 and the address I got back does change between two group, but the browser seems stuck in the connection with the group it first connected (as long as I frequently refresh)
I suspect it is the problem of TCP connection still alive, but I am not sure. BTW, I have already disabled browser cache and I am using Mac OS X 10.9. (This does happen on Ubuntu as well)
Any ideas will be really appreciated. This issue is really important to my works the deadline of which is approaching. Many many thanks in advance.
Unfortunately, that's normal.
Many, perhaps most, browsers cache the dns response they get from the OS, and the timing of this cache is unrelated to the DNS TTL -- it's at the discretion of the browser developers.
For Firefox, the time by default appears to be 60 seconds, so, not likely to be directly related to keepalives, though there's certainly some potential for that, too... albeit for a shorter time interval, in some cases, since many servers will tear down an idle kept-alive connection before 60 seconds, since a connection idle for so long is a potentially expensive waste of a resource.
Firefox: http://kb.mozillazine.org/Network.dnsCacheExpiration
For a discussion of the issue and observations made of the behavior of different browsers, see also: http://dyn.com/blog/web-browser-dns-caching-bad-thing/
I've noticed that when a client accesses a web page, the requests for that page can potentially utilize several apache child processes, consequently reserving each of those processes for KeepAliveTimeout length (in this case 5).
Is this supposed to happen? Or should a client only be reusing the initial child process, assuming further requests happen before the initial reservation times out (Which they do).
While acceding a web page containing external resources (images, CSS, .js), most of the usual browsers use more than one concurrent connections, parallelizing requests in order to get resources faster.
It could be avoided if servers (and browsers) were correctly implementing HTTP pipelining, which unfortunately is pretty rare.
Hey there guys, I am a recent grad, and looking at a couple jobs I am applying for I see that I need to know things like runtime complexity (straight forward enough), caching (memcached!), and load balancing issues
 (no idea on this!!)
So, what kind of load balancing issues and solutions should I try to learn about, or at least be vaguely familiar with for .net or java jobs ?
Googling around gives me things like network load balancing, but wouldn't that usually not be adminstrated by a software developer?
One thing I can think of is session management. By default, whenever you get a session ID, that session ID points to some in-memory data on the server. However, when you use load-balacing, there are multiple servers. What happens when data is stored in the session on machine 1, but for the next request the user is redirected to machine 2? His session data would be lost.
So, you'll have to make sure that either the user gets back to the same machine for every concurrent request ('sticky connection') or you do not use in-proc session state, but out-of-proc session state, where session data is stored in, for example, a database.
There is a concept of load distribution where requests are sprayed across a number of servers (usually with session affinity). Here there is no feedback on how busy any particular server may be, we just rely on statistical sharing of the load. You could view the WebSphere Http plugin in WAS ND as doing this. It actually works pretty well even for substantial web sites
Load balancing tries to be cleverer than that. Where some feedback on the relative load of the servers determines where new requests go. (even then session affinity tends to be treated as higher priority than balancing load). The WebSphere On Demand Router that was originally delivered in XD does this. If you read this article you will see the kind of algorithms used.
You can achieve balancing with network spraying devices, they could consult "agents" running in the servers which give feedback to the sprayer to give a basis for decisions where request should go. Hence even this Hardware-based approach can have a Software element. See Dynamic Feedback Protocol
network combinatorics, max- flow min-cut theorems and their use