I am working on a complex web app where I'm tasked with improving the TTI performance of the home page across various build configuration variations - specifically looking at JavaScript performance.
It's not trivial to switch between variants and I can only access it over a VPN using the full staging environment.
To decrease the feedback loop, I would like to download a static clone of this web app so I can work on it from my local machine without interference.
Using Chrome's "save as" function to save the website does not work as it doesn't pull dynamically loaded javascript assets and doesn't mock the HTTP responses.
Is there an easy way to download a website in a way that lets you supply the assets, mock any http requests and essentially "replay" the page in isolation?
I had considered manually stubbing the backend by writing a proxy service that lazily caches the back end requests, offering replayability.
Related
I'm trying out HTTP/2 and would like to know if there's any best practices for making a web application take advantages of the new protocol in both:
Server side and
Client side
And... where (and when?) should I start? What are the least effort changes to take effort of HTTP/2
Update:
Assumption : Users are already using browser that support HTTP/2.
Update 2:
Some good resources on this topic:
https://http2.github.io/faq/
https://www.nginx.com/blog/7-tips-for-faster-http2-performance/
https://www.smashingmagazine.com/2016/02/getting-ready-for-http2/
You don't need any changes to your apps to deploy HTTP/2: most things will work out of the box.
That said, here are a few tips that apply mostly if you are starting from scratch:
Start developing your application using HTTPS. You don't want to have problems with your URLs when you deploy your application because fetching some resources over http:// (e.g. Google fonts or any other CDN resources) does not work anymore. It takes five minutes with some tools (just google "Five minutes to HTTPS development URLs").
Consider if you want to host some resources that you would normally link to a public CDN in your own server. The main performance reason with HTTP/2 for linking to some assets in a CDN, if you are not hosting your entire site on that CDN, is that those resources may be already in the user's cache. If they are not, opening a new connection takes in average half a second.
Don't set up bundling. Set up instead HTTP/2 Push. And then go and grab your favourite module manager. Give a try also to web components and PolymerJS. They are simply awesome when you are not concerned about bundling and round-trips.
If you are using a server that uses machine learning for configuring HTTP/2 Push automatically (e.g, ShimmerCat), then a third tip is to keep the structure of your web pages predictable.
I'm told that we need to do some performance testing on one of our web-applications, so I'm trying to get some JMeter stuff to work, which as far as I know would simulate the HTTP GETS and POSTS. However, one of my colleagues is telling me that if I use it, it'd only accomplish FE testing. But, if I do this, it still is able to create items in the database and interact with the logic, so I figured it should be sufficient for performance testing of the back-end. Her reasoning is that "if it goes through http pages, we can’t tell which affects the performance".
So am I totally wrong? I'm confused.
The whole idea of the load testing thing is to simulate real-life users actions and behavior as close to reality as possible.
In JMeter terms that assumes presence and appropriate configuration of the following test elements:
HTTP Cookie Manager - to represent browser cookies and deal with cookie-based authentication
HTTP Header Manager - to represent browser headers like User-Agent, Accept-Encoding, Accept-Language, Content-Type, etc.
HTTP Cache Manager - browsers download embedded resources like scripts, styles, images, etc. but do it only once, on subsequent requests aforementioned entities are being returned from cache. To simulate this behavior you need to have HTTP Cache Manager
HTTP Request Samplers need to be configured to fetch embedded resources from the web pages and use a separate thread pool for this. See How to make JMeter behave more like a real browser guide for more details on how to configure realistic behavior.
So given JMeter test is good designed and implemented it is quite enough to test backend as well. If during load test you figure out that bottleneck is i.e. database, you may need to load-test the database separately, JMeter is capable of doing this as well, however I'm a strong believer that load testing should be done against environment as close to production as possible and should target the whole system rather than individual components.
For my new web project I am considering to abadon server-side processing of web pages in favor of just using static HTML5 pages. All dynamic content of the page will be loaded using ajax from a REST service. No need for php, jsp, jsf.
I came across this post and it seems I am not the only one.
What are the advantages and disadvantages using this approach?
I can imagine there are more client-server requests since many REST calls have to be made in order to gather all the information needed to display the web page.
I believe that we have much more PROS than CONS. One of the good ideias to give HTML pages trought a WEB app server, like apache, nginx, or ISS, is that you can apply more security and control to the container that is delivered.
BUT, HOWEVER
Use static content, like JS, CSS, and HTML5 to consume only services, is the next goal in software development. When you start to divide things like, API and UX, you can test then separatly, you can develop at same time, service and interface, and you have much more speed and quality to development.
When we look at a web page, and the weight that the DOM have, and how much cost for the app server to give all that container to the user, and sometimes less then 10% of this is JSON from a service, we need to start to rethink the architecture of our web app.
I have been developing apps like this since one year and a half now, all the projects, and be sure, we re not to come back to the past. Its very important to work oriented to services, and how to consume this services.
If you use for example, Amazon S3 to host your HTML,JS, CSS, IMAGES, files, you dont need a app server, only the REST api to consume and give the content to the user. Costless and very,very faster.
I want to test the performance of my website. I have hosted it on godaddy and I want to see how it performance when 100s of users are trying to access it.
Is their a way to do the above? Is their a script that can be developed to send multiple page request?
Thanks
Consider trying Jmeter or siege.
Apache Bench is commonly used for doing load testing (which is pretty much what you are describing). There are also a bunch of services that will do it for you (some free, most with varying costs).
You could simply script curl or whet to beat on it in parallel but just throwing load at it isn't terribly useful if you don't also track how the site performs under the load (which is where the other tools come in).
One thing to watch out for is if you test just the base page/application or if you use a real browser engine to test the full page (including images and static resources).
I´ve recently started using JMeter to create load tests for my web applications. I really like the tool, and after watching some videos it was really easy to get started with creating tests.
There´s however one thing that I´m not clear about.
Reading on the JMeter homepage, there´s a "Best practice" section. Among other things, it says:
The most important thing to do is filter out all requests you aren't interested in. For instance, there's no point in recording image requests (JMeter can be instructed to download all images on a page - see HTTP Request ). These will just clutter your test plan.
I´ve seen this on other pages aswell, saying that you shouldn´t include requests for images or any other static resources in your tests. However I´ve still not been able to find a single page which gives a good explanation as to WHY you shoudn´t include static resources.
Sure, JMeter isn´t a browser, but requests for static resources would no doubt affect performance of your application? Can someone please give me a good explanation :-)
It all depends on what you are trying to test.
In general, there are two types of performance test I do with JMeter: specific tests, where I look at things that I'm worried about, and "safety net" tests, where I measure the entire application to make sure it does indeed work the way I expect it to.
Specific tests nearly always deal with the dynamic aspects of the web application - the server-side code (.aspx, .php, .jsp etc.). This is where most applications have their bottlenecks - the effort to run a server-side script is many, many times higher than the effort to retrieve a CSS file from disk and serve it up to the browser without any additional processing. If I'm testing the server-side scripts, I don't want to also load the assets - because they clutter up the tests, and consume bandwidth at the test client end. I don't want my tests to fail because my JMeter server is downloading a 5MB video file on each thread and consuming all the bandwidth, when what I'm actually trying to do is see how many logins per second the server can support.
There's very little point in testing your webserver's ability to serve static files - Microsoft, the Apache team, whoever, have already done a brilliant job at that; unless you have a very specific concern, there are better ways to spend your testing budget.
Safety net tests put the whole thing together to prove that it all really does work the way I expect it. Usually, I run these on a production(like) environment, so I have a CDN, production-grade hardware, and the "live" application config. I usually employ a cloud-based testing service for this, so I can see performance from different locations, and generate enough load to stress production-grade kit. You could use JMeter for this (and there are a couple of JMeter Cloud services I've used in the past). It's expensive, it may require downtime, and you should only do it as a safety net.
When you want to do a proper performance test (especially a stress test), where you need to produce your application's response time as a function of number of users/threads in time, you need to include all static resources, just as jMeter Proxy saved them when you recorded your test.
To take browser cache into account you can either use HTTP Cache Manager or Once Only controller, so that each thread only downloads static stuff once, with their first request.
HTTP Cache Manager is the recommended way to go and much easier to set up, simply include it in your test, as the first child of a thread group.
Once Only controller is regularly used when you need to log-in users only on their first request.
BTW parametrization of non-static HTTP Requests is recommended, you won't e.g. search for the same product name or e.g. buy the same book every time, that's usually the starting point which can give you a general idea of performance efficiency of you app.
Hope this helps...
Unless your app is used by casual visitors who only look at one page and then go, there is a good chance that the static resources are being downloaded once, and then served from the browser cache.
Moreover, although static resources affect the bandwidth and the overall response time for the user, they should have a small impact on the server load, and they might not be the kind of thing that you want to measure.
I guess you need to try mimicking what actual, real users would do with the application.