I am showing images for flipkart and snapdeal products. They are been downloaded every time a user sends request. On a decent speed internet(not very high speed like 3G/4G), the loading takes way too much time, hence bad experience for user. However, the images which are on my server,even though they are 10 times in size, they get loaded very fast. Is there a way I can optimize these external images or any other way to enhance user experience
Take a look if images are routed through your servers or directly from client, also it depends on number of request from client if it is due to request then you can load images on focus.
as of i now flipKart, snapdeal all are using cdn for faster static files with image sprite model so something at your code blocking the request or routed through your server.
Related
I'm trying to use data from google analytics for an existing website to load test a new website. In our busiest month over an hour we had 8361 page requests. So should I get a list of all the urls for these page requests and feed these to jMeter, would that be a sensible approach? I'm hoping to compare the page response times against the existing website.
If you need to do this very quickly, say you have less than an hour for scripting, in that case you can do this way to compare that there are no major differences between 2 instances.
If you would like to go deeper:
8361 requests per hour == 2.3 requests per second so it doesn't make any sense to replicate this load pattern as I'm more than sure that your application will survive such an enormous load.
Performance testing is not only about hitting URLs from list and measuring response times, normally the main questions which need to be answered are:
how many concurrent users my application can support providing acceptable response times (at this point you may be also interested in requests/second)
what happens when the load exceeds the threshold, what types of errors start occurring and what is the impact.
does application recover when the load gets back to normal
what is the bottleneck (i.e. lack of RAM, slow DB queries, low network bandwidth on server/router, whatever)
So the options are in:
If you need "quick and dirty" solution you can use the list of URLs from Google Analytics with i.e. CSV Data Set Config or Access Log Sampler or parse your application logs to replay production traffic with JMeter
Better approach would be checking Google Analytics to identify which groups of users you have and their behavioral patterns, i.e. X % of not authenticated users are browsing the site, Y % of authenticated users are searching, Z % of users are doing checkout, etc. After it you need to properly simulate all these groups using separate JMeter Thread Groups and keep in mind cookies, headers, cache, think times, etc. Once you have this form of test gradually and proportionally increase the number of virtual users and monitor the correlation of increasing response time with the number of virtual users until you hit any form of bottleneck.
The "sensible approach" would be to know the profile, the pattern of your load.
For that, it's excellent you're already have these data.
Yes, you can feed it as is, but that would be the quick & dirty approach - while get the data analysed, patterns distilled out of it and applied to your test plan seems smarter.
I have a Django server. The server loads a webpage with almost all static content but a few numbers must load from the database.
I'm thinking about performance/price; I can host my Django server on a fast server and render the page using Django templates. or I can host the server on a slower machine and make a static page that loads the few numbers using ajax and host the page cheaply somewhere else like github.io.
The latter choice will have most of the page load real quick and real cheap.
I was wondering what are the trade-offs ?
Whichever server you decide to hire, you should always think of reducing the server load - no matter how fast your server is. By reducing server load I mean only make your server do what is really required at the moment.
Let's learn something from the big players like Facebook, for instance
You log into your account and you see that you've got 5 notifications and 3 new messages plus a couple of photos and highly interesting statuses of your friends. Cool! You now click on the notifications icon to find out if that hot girl (forgive me if you're a girl :D) has added you to her friends list or not. As you click a big white <div> pops up AND you see nothing but a loading gif! The notifications do appear, but after a couple of seconds. Try doing it with a slow internet connection, and you get to adore the beauty of the loading gif for a lot more time.
So, what do you make of it?
Facebook only made it's server count the number of notifications and new messages, and displayed those numbers to you. Thus reducing server load. It only displayed the notifications to you when you wanted to see them. And to load the notifications, all it took was a minimal AJAX call in which only around 10 KB of data was transferred!
Facebook does it all the time and everywhere. Consider this: Robert Downey Jr. posts a photo of himself on his Facebook page. A little while later, you see that it has got 10k+ comments. You decide to read them and click the comments button. An attractive loading gif pops up again for a little while and is soon replaced by comments. But hey, only 10 comments were loaded. What the ... Oh wait! That's how Facebook reduces its server load - read those 10 comments first, if you want to read more, send a request again.
Twitter does it too - the infinite scroll.
Icing on the cake
This approach benefits you in two ways:
It reduces server load - less chances of crashing a website.
It decreases your website's page-load time since you'll be passing less data i.e. the data required at that moment. Thus making your website faster. (Yes, it can outrun Flash, too!)
Food for thought
If you've got some cool technologies around such as AJAX, why not use it? Your server is not a donkey, for God's sake!
P.S. By Facebook and Twitter, I mean the engineers behind them.
Well It would depend on the following:
A. Whether you want to Display that number on Page load itself or when user clicks to see it* ?
If you want to show the the numbers at the time of Page load Itself than it is preferable to get them at time of Template response itself.
Why do you would want your Site Visitors to wait till those numbers populate (if the intention is to display them) ?
If it is to be displayed on User's click only then Ajax should be preferred
B. How much Time is this Query going to take and Can the query be optimized to minimal time ?
If the Query you are making takes a Lot of time than first effort should be made to optimize that query to be as fast as possible,
If the query can give result in minimal time than it is futile to do another Request to Server via Ajax.
But if you know the Query will take a lot of Time than Ajax is fine.
I hope you can help
I have a image server that generates images on the fly.
I'm using varnish to cache generated images.
I need to record how many requests (per image) varnish receives as well as if it was a hit or miss (pass gets marked as miss). Currently, I'm writing access logs with hit/miss to file, I then using crontab process this access-log file and write the data to my db...
What I would like to do instead is:
Have Varnish make a request to my backend notifying it of a cache hit (and if possible the response size (bytes)).
My backend could then save this data...
Is this at all possible and if so how?
In-case anybody is interested:
2 varnish instances each with 1 (java+tomcat) backend.
Service manipulates and generates each image specific to the requirements made in the request...
Below are per day:
Over 35 million page views where each page has at least 3 images in it.
Varnish gets around 3+ million requests for images (images are also cached by the browser).
Varnish has a 87% hit rate
Response times for a hit are a few micro seconds
Response times for a miss are 50ms to 1000ms depending on the size of the image (both source and output)
The best way of doing this is to have a helper process that tails varnishlog output and
does the HTTP calls when needed.
You can do this by logging the necessary data with std.log() in vcl_deliver, so the
helper process gets all the data it needs. Use obj.hits > 0 to check if this was a cache hit.
If you really really need to do it inline (and slowing down all your cache hits badly), you
can use libvmod-curl:
https://github.com/varnish/libvmod-curl
If you are going to send a request to a stats server from within your vcl I would try to incorporate some type of aggregate request, where you send it every 100 (or whatever) requests instead of every single incoming request.
Like the other answer, I would recommend using varnishncsa (or varnishlog) with a process that tails the log file. There could be some delay in that method but if that is acceptable then I would consider post processing the varnish log when logrotated runs. This way you have a full day's worth of data and you can churn through it, producing whatever report you need.
I'm working on a little search engine, where I'm trying to find out how to cache query results.
These results are simple JSON text, retrieved using an ajax request.
Storing results in memory is not an option, I can see two options remaining:
Use a nosql database to retrieve cached results.
Store results on a CDN and redirect the http request (307 - Temporary Redirect) in case the result was already cached.
However, I don't have much experience with CDN, and wonder if using it for a huge amount of temporary small text files is a good practice.
Is it a good practice to use redirection on an ajax request?
Is a CDN an appropriate solution to cache small text files?
Short answer: no.
Long: Usually, you use a CDN for large static files that you want the CDN to mirror all around the world so it's close to a user when she requests them. When you have data that changes a lot, it would always take a while to propagate the changes to all nodes of the CDN, in the meantime users get inconsistent results (this may or may not matter to you).
Also, to avoid higher latency I wouldn't use an HTTP redirect (where you tell the client to make a second request to somewhere else) but rather figure out whether to get the data from the cache or the engine on your end (e.g. using a caching proxy or a load balancer) and then serve it directly to the client.
As far as a performance issue, the server is performing fine. With the exception of the http response wait times. This will become more of an issue as we grow our line of online services. All things being equal, I’m confused how this new server is it not loading pages as quickly as an older server running multiple websites, logging, etc…
Here is a screen shot from http://www.gtmetrix.com the online testing tool I’ve been using. These results are consistent regardless of time of day, The numbers here don’t make sense. The new site page is 75% smaller, yet its total time to live is only 26ms faster. In the below image the left side is NEW SERVER, the right side is OLD SERVER
The left portion of the timeline is the Handshaking portion. So, you can see, the new server, is about the same speed. The purple middle section, that represents wait time. It’s about 4 times the delay in milliseconds as OLD SERVER. The Grayish section on the right represents the actual time to download the file. You will also notice that the new server is significantly faster at downloading the response, this is most likely due to the 75% decrease in the response size.
You can see the complete results for the new server here. http://gtmetrix.com/reports/204.193.113.47/Kl614UCf
Here’s a table of the differences that I’m aware of, let me know if you see one that could be the culprit. I forgot to add this to the table, but the old server, is in production, right now serving requests, when www.gtmetrix is hitting it. In contrast, to my New server, which is just me connecting and generating requests.
My current hypothesis, is that the slowness is caused some combination of the server being virtualized, incorrect IIS settings, or the difference between 32bit and 64bit OSes
OK...
The server in in Sarasota(?), the test agent is in Vancouver so roughly 4,356KM apart (as the crow flies) so the best round trip time you could hope for is around 45ms.
Given it won't be a direct route and things like routers etc. will that add latency then the 155ms round-trip you seem to be getting is pretty reasonable.
Looking at the request for the HTML page the 344ms to complete it a pretty good time - basically 114ms to set up the connection, 115ms to receive the first bytes from server and then 155ms to get the complete response.
Unless you get decrease the roundtrip time then this time isn't going to improve much - have you tried testing from gtmetrix's Dallas server as a comparison?
If it is a slow server response then something like PAL (http://pal.codeplex.com/) is worth using as a first look to see what's happening on the server but I'd also look how quickly the SQL server is responding to the queries that are used on the test page.
A couple of things you want to look at later in the waterfall...
For the two files that are hosted from ajax.aspnetcdn.net it takes longer to resolve their DNS name than it does to download them so you may want to consider hosing them yourself
For the text based content e.g. HTML, CSS, JS etc. what level of gzip compression are you applying and are the compressed files being cached on the server? (the server times for them look a bit long)
Looking at the complete results, it seems the lower bound for the wait times would be 115ms. Not a single request is faster, most are around 125ms, and judging from the requested resources, there's a lot of static resources as well, so serving the response should not involve a lot of CPU. Even though responses are as small as 123 bytes, there's still this delay.
So it looks like a general issue, possibly not even related to IIS. Here some ideas how I'd try to debug this.
How long does a ping roundtrip take? (i.e. Is it a general network issue, routing etc.?)
How long do HTTP requests take when done from the server box (e.g. to localhost)? (If they all take more than ~100ms, start profiling inside the server box)