The upcoming Xceptance LoadTest 4.2 will discontinue the direct support of JRuby as a programming language for writing test cases. This will not change the way Java and JRuby interact and therefore you can still use all Java components and integrate them into your JRuby-based test suite. You can also still write test cases in Ruby and use XLT-APIs.
You can read about this feature, in case you are not sure whether or not you will be affected by this change: XLT 3.3.0 JRuby support release note.
Version 4.2 of Xceptance LoadTest will not continue the JRuby package anymore (jruby.jar). The test execution scripts for JRuby-based tests and all demo test cases will be removed as well.
If you have any questions regarding this change, please do not hesitate to contact our support team directly.
XLT 4.1.8 has been released. It contains a couple of improvements and bug fixes. You can get the latest version here: https://lab.xceptance.de/releases/xlt/4.1.8/.
These are the two most important changes.
Optimized scanning CSS rules
XLT simulates the download behavior of a browser as close as possible. With
com.xceptance.xlt.css.download.images set to
onDemand, XLT carefully considers the download of image resources referred to in CSS files. It checks all CSS rules if they apply to all elements in the DOM tree and, if so, extracts the resource information for later download. This process was previously very expensive and ran for up to several seconds when a page was complex and a lot of CSS rules had to be matched. This has been optimized heavily.
Configurable retry behavior for keep-alive connections
If persistent connections (keep-alive) are enabled, test cases might failed sporadically with an exception such as:
java.lang.RuntimeException: org.apache.http.NoHttpResponseException: The target server failed to respond
This exception occurs only when the request was sent while the connection was about to be closed on the server side at the same time.
The underlying HttpClient retries requests if the connection was closed by the server. However, by default it retries only idempotent operations such as GET and HEAD, but not POST and PUT. In order to avoid these connection errors, the user can now configure whether non-idempotent operations are to be retried as well. Common browsers seem to use the same behavior and most certainly assume that the server did not start to process the request when it closes the connection immediately without responding with a proper HTTP status code.
A new boolean property
config/default.properties controls whether or not operations such as PUT and POST are retried in case of certain networking problems. Note that idempotent operations are always retried.
We just released Xceptance LoadTest 4.0.5. It is a minor update and recommended for everyone. But you might have special interests if you use the Script Developer heavily.
Besides a few defect fixes, release 4.0.5 delivers four great improvements to speed up test case creation and maintenance with Script Developer and make your work more productive.
- The XLT Script Developer runs on Firefox 4 and 3 now.
- Test variables are now resolved recursively, so you can use variables within resolved content.
- There is no need to open modules anymore if you want to edit a line or two of it. Also enabling/disabling of module code can be done easily from the main test case. This saves time and aids script maintenance.
- During script debugging and script execution, you can now evaluate assertions instantly to see whether or not your verification expression will match.
The full set of release notes can be viewed directly in the release area. You will also find documentation and the download link there. As usual, th
Today we released update 4 of XLT 4.0. You will find all the details about it at the usual place: https://lab.xceptance.de/releases/xlt/4.0.4/. Check out the release notes too. This release addresses minor script developer defects.
As always, updates are free for all customers and all people using XLT despite the license.
There are new public Amazon EC2 images (AMI) available each running 4 agentcontrollers of XLT 4.0.0.r6019 on ports 8500 to 8503. Feel free to use them for your load testing purposes.
- EU-West: ami-9b5064ef
- US-East: ami-5647b63f
- US-West: ami-539dcd16
The usage of the images is free or charge but you have to pay your AWS usage costs of course. Please keep in mind that you need a valid license to run a load test with more than 5 virtual users.
We just released Xceptance LoadTest 4.0. This release of our load test software got some really nice feature enhancements to make your regression testing easier. So we stick to our general software approach: One tool for regression and load testing. One set of scripts for both purposes.
Continue reading Xceptance LoadTest 4.0 is available
People asked for a rough guide for running load tests against their live site and whether this is a good idea at all.
Well, let me first say that test environments exist for exactly that purpose. So if you already have something live, of course you used it before going live for load testing, and now you cannot run another test there… yes, you need a test environment. This is well spent money for several reasons:
- Created data will not pollute your installation aka log entries, analytics data, orders in the database, created users, and so on.
- You do not have to take your live site down for testing.
- Problems during testing will not leave your live site down or take it down.
- Your hosting company or IT department might charge for all test traffic against the live site as it would have been real traffic (revenue share, bandwidth utilization), so having your own testing realm makes expenses more predictable.
- You can easily change code and retest when changes are necessary. You can profile, you can debug.
- You do not risk problems with traffic going to live systems, such as payment due to configuration or testing errors. If you already had items from test orders piling up in your office, you know what I mean.
So, get yourself a test environment. Spend the money and enjoy the freedom to measure, debug, and tune.
P.S. Of course, there are situations, where you cannot replicate a live environment or you cannot find application problems in a test setup due to totally different timing behavior… Well, this indicates only that your live environment is already screwed.
Heute mal wieder etwas aus der Reihe “Erfolgreiche Fehler” oder “Unsinnige Dialoge”. Gefunden im Nautilus von Ubuntu 9.10.
Google hat sich entschieden, Problemen bei der Entwicklung von Webapplikationen aus dem Weg zu gehen und kündigt die Unterstützung des Internet Explorer 6 auf. Auch der Support vom Firefox 2 läuft aus, aber den nutzen ja die wenigsten Leute, weil das Update auf Version 3 einfach ist. Zudem war der FF2 nicht schlecht bei der Einhaltung von Webstandards und dürfte locker dem IE7 das Wasser reichen können.
Das ist ein gutes Signal, denn wenn der Marktführer es vormacht, dann werden viele Leute und Firmen nachziehen.
Many other companies have already stopped supporting older browsers like Internet Explorer 6.0 as well as browsers that are not supported by their own manufacturers. We’re also going to begin phasing out our support, starting with Google Docs and Google Sites. As a result you may find that from March 1 key functionality within these products — as well as new Docs and Sites features — won’t work properly in older browsers.
Mehr dazu im Google Enterprise Blog.
Einige aktuelle Zahlen zur Nutzung verschiedener Webbrowser finden sich bei Bivingsreport.
Mein Windows XP meinte heute, dass diese Datei eine Intel IPhone kompatible Datei sei… kommt das iPhone von Intel und Apple hat es nur lizenziert? Oder hat man sich hier bei Microsoft vertippt? Eventuell hat hier Intel auch nur Rechte an einer IPhone-Applikation, die nie große Verbreitung fand. Komisch…