I'm not new in load testing. My job is to create a load testing with jmeter. I did not bother with tread number, clients, memory consumption ,etc. For jmeter load testing i used 3 client , each of them run 1000 threads (30% CPU was used), results were expected all the time. No problems were detected on SUT or clients.
I'm put before new challenge. Now i have to execute web performance testing on browsers.I don't know if i create a correct picture about performance testing.
I want to measure, first byte, load time on web page, java script, Ajax, etc,...
Web automation tests are written in selenium. Selenium is not mentioned for web load testing.
Lets say to simulate 1.000 users clicking ob browser, this means a lot of VM, collecting results from browsers(DOM counters), SUT is managed by PS script to take data from perf. counters. I see a problem a lot of VM means also financial budget which i do not have.
I'm in doubt if the upper approach is correct or should change my approach.
One of these tools is Visual Studio Ultimate edition. But i still need a lot of VM to simulate 1,000 users - browsers.
On the internet i read a documents, descriptions, top tools.
How do you do changeling web page performance testing on you company.
Any help about web page performance will be appreciated.
Thanks,
Dani
Well-behaved JMeter script must look exactly like real browser does from the server's perspective, just make sure you properly handle the next few bits:
Embedded resources via "Advanced" tab of the HTTP Request Defaults
Cache via HTTP Cache Manager
Cookies via HTTP Cookie Manager
Headers via HTTP Header Manager
AJAX requests via Parallel Controller
See How to make JMeter behave more like a real browser article for more details.
Assuming all above you should be able to mimic the load on HTTP protocol level. If you need to measure rendering or JS execution speed additionally you can add another Thread Group with 1 (or several threads) and use WebDriver Sampler which provides JMeter integration with Selenium. Additionally you can collect some extended stats using i.e. Navigation Timing API via WDS.browser.executeScript() method allowing execution of arbitrary JavaScript code.
Related
Im newbie to jmeter and Im stuck in a situation. Altough scenario is simple but like i said Im newbie to Jmeter.
I have to request a webpage.
In response I will receive an HTML file which will contain a java script code.
I have confirm some string present in that javascript code
I know I can do this with the help of seleium webdriver and I already done it so far but I need to run this test multiple times.
and as far as JMeter goes it discard any scrip present in response. So please help me out
JMeter will not run Javascript. That doesn't mean that it will ignore it.
Add a Response Assertion to your HTTP Request Sampler (right click on it, Add -> Assertions -> Response Assertion). This will let you add Strings and Assert that that String exists in the Response (NB: unlike, for instance, C++, an assertion here won't stop your test, it will only make that Sampler an error).
To use the Response Assertion, switch the Radio Button to Contains and click Add at the bottom center. In the new box that shows up in the center, add the "some string present in that javascript code."
First of all in your HTTP request sampler, you should select an option, 'Retrieve all embedded resources', after this jmeter will retrieve all resources like css,js,graphics etc.
Also you might want to take a look at http://jmeter-plugins.org/
This library contains some really cool plugins for jmeter testing.
You should look for some kind of Post Processors and add that to your test script. These can be used to extract some particular resources from retrieved data.
Also, one unrelated advice because you are new, Do not add Many/Any Listeners to your jmeter test plan.
From JMeter Project Main Page
JMeter is not a browser
JMeter is not a browser. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does (it's possible to view the response as HTML etc., but the timings are not included in any samples, and only one sample in one thread is ever viewed at a time).
JMeter acts on protocol level, of your JavaScript is doing something local - you can duplicate the logic using JSR223 Test Elements
If JavaScript is used to send a request - you can mimic the request using JMeter, JMeter doesn't execute JavaScript but it is able to record and replay JavaScript-driven requests with HTTP(S) Test Script Recorder and HTTP Request samplers
If you're trying to load test an application which is AJAX-based and you need to simulate the requests from real browser (i.e. asynchronous, several requests at a time triggered by opening the page, etc) - you will need to do some extra work as JMeter doesn't provide any test elements to jump over defined virtual users defined on Thread Group level. There are several techniques on testing AJAX applications with JMeter, see How to Load Test AJAX/XHR Enabled Sites With JMeter guide for more details
I am building an application that will allow user to open a word document through a web page. This web application will open the word document using the local word instance on the machine.
I have two working solutions.
Using ActiveX (Only on IE)
Since the application is intranet application, I am using PsTools in the web service to remotely open word instance on remote machines.
The second architecture is what I am following right now. It is based on a Web Service which receives machines name through Javascript/jquery call. Later in the web method I am using PsTools to remotely execute MS Word instance on remote machine.
Both the architecture works, but both of them have limitations. With ActiveX I can use it on IE and it also requires changes in network policy to allow ActiveX. With PsTools, it is working great but I can't get the path of Word.Exe and I can only assume that it would always be at \\machinename\C$\Program Files(x86)\.....
We might make this application public as well and in that case our solution with PsTools will not work anymore.
I was just wondering if there is any other more suitable/cross browser way to open local word instance through web application ?
The document has to be modified on a remote location, one option would be to let the user download the document, then modify it and upload it to the server, this is out of question since we are replacing a thick client and wants to keep the user experience same
I am building an application that will allow user to open a word
document through a web page.
If it is an Intranet scenario, then you could use application protocol with Office URI schemes for links to the documents which will then open in the locally installed client.
The Office URI schema is like this:
<scheme-name>:<command-name>"|"<command-argument-descriptor> "|"<command-argument>
For Word specifically, an example would be:
<a href='ms-word:ofe|u|https://example.com/example.docx'>Edit</a>
Where, ms-word: is the scheme, ofe command stands for open-for-edit, the u is the command-descriptor to use the URI that follows, and finally the URI to the document itself. There are other commands like ofv (open-for-view), and nft (new-from-template), and also other command-descriptors like s for save.
Here is the complete reference: https://msdn.microsoft.com/en-us/library/office/dn906146.aspx
The protocols are registered with Windows when the Office client is installed.
You could enable WebDAV easily on your IIS server. The WebDAV client is built-in with Windows at the client-side.
You can also use components like FFWinPlugin Plug-in which is part of the SharePoint Foundation, or OpenDocuments Control which is an ActiveX control installed along with the Office client.
We might make this application public as well
I would discourage you from doing that, unless your company owns or deals-with services like OneDrive or Office.com. This can quickly get tricky as mentioned in the other answer. Moreover, enforcing a proprietary client on general public is not a good idea anyway. Further, even Microsoft's own solutions do not work reliably across browsers and work best with IE only (even Edge has problems with this), which would be forcing a specific browser to general public. Not a good idea.
However, if you really need to, then it would be better if you could use some of the solutions already built around WebDAV. Alfresco ECM (enterprise content management) is one example of public offering which uses WebDAV similar to your use-case.
There is another one by IT Hit and a live demo is here: http://www.ajaxbrowser.com. They also have a basic tutorial on how to setup your own WebDAV server on the same lines as your use-case. You will need to find their documentation.
When you say: "We might make this application public as well", what kind of scale are you talking about? Just a couple of folks from the a team, or as a real web application that needs to deal with edit conflicts, transactions, locking, performance, etc.? Even the intranet solution you mentioned will likely become a headache as soon as 2-3 people start to edit the same document.
For this type of document sharing, you basically have two options:
Significant investment in a rich web UI that behaves similarly to MS Word, with back-end services that will store the info in a scalable data store and provide simultaneous edits and document downloads, or
Integrating with a third party vendor API or white-label provider that offers similar capabilities for a fee. E.g. Box.com APIs, HyperOffice, FirePad, etc.
This would be a super-simple problem to solve if you can convert the document in question to a type of form. There are probably a hundred different services that offer embedded forms functionality with excellent reporting and database management. If a document in Word format is needed, then your app would just convert the stored data to a .doc/.docx document for users to download at will.
Whatever direction you go with, try to get out of the PsTools-based current setup. It's like a rinkydink house of cards and as #Matt-Burland mentions, likely to cause a security disaster pretty soon.
I'm attempting to make a Web app that needs to communicate to a program written in C Sharp. But I can't find a good form of communication. What I need is if a user clicks something on the Web app, it will notify the C Sharp program. Also, if an event happens on the C Sharp program, it needs to alert the Web app. Both of these are going to be running on the same machine.
Right now I'm mainly focusing on the C Sharp program just periodically "asking" what the status of the Web app is.
I've tried using POST requests to the Web app and I've had a bit of success with this but I don't know how to essentially store and update a "status" on the Web App. For example, C Sharp program sends a POST/GET request asking for the status, the Web app responds with "nothing has changed" or some sort of status code. I don't know how to keep track of that status.
I've attempted using Web Sockets but I don't think it is going to be possible on the C Sharp side. However, I'm definitely open to suggestions on how this might work.
I've looked into using the ReST architectural style but I'm having a hard time understanding how I would implement it. I'm using mainly AJAX on an apache server and most of the ReST examples I saw used IIS.
One way I've been successful with this is a horrible workaround. I use 3 files to store contents, status of Web app, and status of C Sharp program. But this requires me constantly fetching files, reading them, writing a new one, and uploading it.
Sorry if this question is poorly formed, I'm obviously new to a lot of this and this is my first SO post. Also, I'd include example code but I'm posting this from my tablet so it's not accessible right now.
If they are on the same machine, you can use 'pipes' (Unix), local sockets or file handlers.
These are all types of IO objects both applications can 'listen' to without exposing themselves to the network and without blocking while they are 'waiting' for data..
... But this will limit your scalability.
Another option is to use a Pub/Sub service such as Redis. This is a better option than websockets, because you can have multiple C# apps listening to multiple web apps on a centralized data source.
It uses the same IO concept (using sockets) behind an abstraction layer coupled with a database - it's very effective.
Good luck!
I implemented something similar to this. I needed a desktop application to listen for api calls from the browser. I ultimately decided to implement a "web connector" which can either be created as part of the application OR installed as a service.
Here is a good example: https://msdn.microsoft.com/en-us/library/system.net.sockets.tcplistener(v=vs.110).aspx
We have an application which consumes a large amount of data. Currently a desktop app, but we would like to deliver it via the browser.
It doesn't make sense to me to create a web app where we need to transfer a ll the data used for the visualizations.
We're looking at RDP and some products out there that provide RDP access via a fully javascript client. They seem to work well with our app, but I've been thinking about what it would take to move off Windows.
Switching the front end so that it could run under Linux would not be trivial, but not impossible, so the main stumbling block would be delivery.
I was wondering if there are any X11 javascript servers out there, but have not found any leads.
Use xpra's builtin html5 client, it supports any application you can run on an X11 desktop.
You can use an HTML5 VNC viewer like https://github.com/kanaka/noVNC coupled with a VNC server like RealVNC
AFAIK, recent GTK has been ported to HTML5+Javascript in Gtk Broadway
And you could make your application a web application, for instance by using Wt, or by making it an HTTP server thru specialized HTTP server libraries like libonion, libmicrohttpd etc.
By using AJAX techniques (e.g. thru jquery) your application won't transmit all the display data to the browser at once (but only incrementally and only the actually shown data).
You might also consider fastcgi as a way to connect your application to some web server.
I know two, both at very infancy:
https://github.com/GothAck/javascript-x-server
and
https://github.com/ttaubert/x-server-js
Both need simple tcp-to-websockets proxy in front, but all X11 logic happen inside web page and all x11 objects exist and interact within browser (so it's not just remote framebuffer but real server)
You can ever run full Linux distribution in Web Browser, but that's require to run x86/ARM emulator and GNU/Linux inside it. It provides X server with possible web connection too.
For very simple applications you can use libgreattao toolkit and tao-network-client to connect to it. I'm the author of both project. The API isn't yet frozen, but it rather behaves stable. You can read about it here:
https://nintyfan.wordpress.com/2015/04/30/server-buildin-into-libgreattao-and-tao-network-client/
It can provide some problems with applications with a lot of data, because all elements must be send to client, when it were created, but instead we don't send full graphics(only icons is send) and user interface could be changed quickly. It also don't support mouse enter/leave/move events.
I must tell: do not download tarbar, but download version from svn.
Sounds like the easiest approach for you is to get xrdp, which is an RDP-server for X. Then you would use your RDP client to connect to it. I think Nomachine NX supports html directly now, but I'm not sure. There was talk of an html X2go-client, but I don't know anything about that either.
In the web world a web browser makes a new request for every static file it has to retrieve, so; a stylesheet, javascript file, inline image - all initiate a new server request. Whilst my knowledge of the web is pretty good, the underlying technologies like websockets are somewhat new to me in how they work and what they are capable of.
My question is rather theoretical, but I am wondering if it's possible now or would ever be possible to serve static files via a websocket? Considering websockets are a persistent connection from the client (web browser) to the server, it makes sense that websockets could be used for serving some if not all static content as it would just be one connection as opposed to many.
To clarify a little bit.
I realise my wording about connections was incorrect as pointed out by Greg below. But from what I understand the reason CDN's were created and are still used today is to address the issue with browsers and or servers having a hard limit on the number of concurrent downloads, once you hit that limit your requests are then queued thus adding to the page load time. I am aware they were also created to provide cookie-less requests as well. So really my question should be: "Can websockets be used in place of a CDN?"
BrowserScope has some useful metrics, it appears as though the request limit is about 6 per hostname for most modern browsers and even IE8. But as I said sometimes people have more than 6 resources, does this mean they're being queued and slowing the page load time where websockets could potentially reduce this to one?
It's definitely possible but there are a few reasons why you probably don't want to use this for static resources:
You need at least one resource that is statically delivered over the standard HTTP mechanism which means you need something capable of serving static resources anyways. Generally you want to keep Javascript separate from your HTML which would mean another static load. Or you can be messy and put the WebSocket code embedded on the main page, but you still are really any better off yet.
You can't open WebSocket connections until a script on the page starts running. Establishing the WebSocket connection adds some initial latency.
Most browsers will load non-conflicting static resources in parallel (some older browsers have a severe limit on the number of parallel connections, but they still have some parallelization). You could open multiple WebSocket connections for different static resources, but doing this reliably and efficiently is going to take a lot of effort. Browsers have already solved most of these issues for static resources.
Each WebSocket connection is a guaranteed order message based transport. Combined with the serialized nature of Javascript execution this effectively means you get to process one WebSocket message at a time. You could use Web Workers to be able to process more than one WebSocket connection in parallel, but the main render script will still be serialized across those connections. You could certainly make this efficient, but once again, this isn't a trivial problem and browsers have already solved a lot of these static resource loading problems.
Many web servers support gziping resources before delivering them. WebSocket does not yet have compression support (it's being discussed as an extension in the working group). This means if you want to compress your resources over WebSocket you will have to do this in Javascript which will add more latency.
If you have parts of your page that are dynamically updated using static resources (e.g. loading in new images into a HTML5 canvas game), then WebSockets may be your best option because an already established WebSocket connection will have low latency and overhead for getting pushed updates from the server then getting these delivered over HTTP. But I wouldn't recommend using WebSockets for the initial static resources when you page first loads.
This answer does not really address your web sockets question, but it may make it obsolete:
The next generation technology that is supposed to solve the problem of transferring several assets over a single connection is SPDY, which is was a candidate for HTTP 2.0. It has working implementations in Chrome and Firefox and already some experimental server-side support by the likes of Google and Twitter.
Edit: SPDY protocol is now deprecated. You can however look into it for research purposes.