Tag Archives: Performance

Availability of Xceptance LoadTest 4.2.0

XLT 4.2.0 delivers a large set of new and improved functionality.

The Script Developer has seen a lot of enhancements. Most noticeably is the support of variables now. You can store data from the web page, run calculations in JavaScript and store the result, and reuse all later. There is now the notion of global and local test data. So any data that applies to multiple test cases at the same time can be managed more easily now. Besides the already mentioned store commands, the Script Developer also permits assertion and wait commands for visibility, select and check boxes, as well as value attributes of an element.

Further usability improvements permit easier switching between projects and the execution of a single command in a test case for faster development. Test cases can now be run directly from the package tree without the need to open them first. The test data management has been completely reworked to simplify and speed up editing of data.

The load test engine supports a fully variable load test profile now. You can define any load pattern you want, such as a 24 hour test with peaks around noon and early afternoon, low traffic during night hours, slow ramp up in the morning and multiple load changes over the course of the day. Additionally the ramp up of arrival rates is now supported as well.

To speed up things and fully utilize the available connectivity, the upload to and the download from agents has been fully parallelized. Optionally you can adjust the desired concurrency. Also the timeout against agents can now be set.

The documentation layout as well as the report design have been redesigned to improve usability, make them visually more pleasant, and unify their appearance. Third party libraries used to deliver enhanced functionality have been upgraded to cover the latest browsers as well as UI trends.

Please see the detailed release notes for more information about new features, enhancements, and defect fixes.

Nice reading: CSS3 vs. CSS

Nice article about the advantages of CSS3 in terms of coding as well as download speed: CSS3 vs. CSS: A Speed Benchmark.

I believe in the power, speed and “update-ability” of CSS3. Not having to load background images as structural enhancements (such as PNGs for rounded corners and gradients) can save time in production (i.e. billable hours) and loading (i.e. page speed). At our company, we’ve happily been using CSS3 on client websites for over a year now, and I find that implementing many of these properties right now is the most sensible way to build websites.

Until today, all of that was based on an assumption: that I can produce a pixel-perfect Web page with CSS3 quicker than I can with older image-based CSS methods, and that the CSS3 page will load faster, with a smaller overall file size and fewer HTTP requests. As a single use case experiment, I decided to design and code a Web page and add visual enhancements twice: once with CSS3, and a second time using background images sliced directly from the PSD. I timed myself each round that I added the enhancements, and when finished, I used Pingdom to measure the loading times.

More…

Enjoy reading.

Speed matters for your ranking

Nati Shalom discusses in one of his latest blog entries the changes Google made to its page ranking algorithm and how it influences your Google page ranking.

Last month Google added Website speed to its site ranking algorithm: It’s Official: Google Now Counts Site Speed As A Ranking Factor… The rationale behind this move by Google is fairly straightforward:

Slow web sites lead to a poor user experience, and therefore should not appear at the top of the search list even if they contain relevant content.

This emphasizes once more the influence of performance on your daily business. A simple change to your site can now affect your entire page ranking and how users find your content. Continuous performance testing is now even more important than ever.

Some nice reading about HBase

HBase LogoIf you want to stay in touch with cutting-edge technology in terms of scalability of databases, high traffic sites, and large storage volumes, you should read these two articles on the new hstack.org blog.

Cosmin Lehene wrote two excellent articles on Adobe’s experiences with HBase: Why we’re using HBase: Part 1 and Why we’re using HBase: Part 2. Adobe needed a generic, real-time, structured data storage and processing system that could handle any data volume, with access times under 50ms, with no downtime and no data loss. The article goes into great detail about their experiences with HBase and their evaluation process, providing a “well reasoned impartial use case from a commercial user”. It talks about failure handling, availability, write performance, read performance, random reads, sequential scans, and consistency.

(via High Scalability)

Ist die Geschwindigkeit ein Teil des Pagerank?

In diesem Interview mit SEO marketing expert Amanda Watlington ist die Rede davon, dass Google die Geschwindigkeit einer Website in die Platzierung im Suchergebnis einfließen lässt.

Google is now using page loading speed in their ranking algorithm. The engineering of some sites can make this a difficult problem to fix quickly, so webmasters should study the problem now with speed detection tools such as YSlow and Google Page Speed.

Das wäre nur konsequent von Google, da bereits die Webmaster-Tools in der Google-Administration die Seitengeschwindigkeit ausweisen. Zudem profitiert Google von schnellen Webseiten indirekt, da der Aufwand für die Indizierung sinkt bzw. die Updatezyklen kürzer sein können. Damit steigt auch die Aktualität von Suchergebnissen und das verbessert die Wettbewerbssituation für Google.

Wir freuen uns natürlich auch darüber, weil damit nicht zuletzt auch die Bedeutung von Last- und Performancetests steigt.

Java-GC unter die Haube schauen

Diese Optionen für das JDK6 sollte man kennen, wenn man dem Garbage Collector bei der Arbeit zusehen will. Speziell für das GC-Tuning sind diese Optionen unerlässlich:

Details zu den Optionen und zur Auswertung kann man unter GC Tuning oder in der Liste der JDK-Optionen finden.

Was sind Visits, was sind Sessions?

Wenn wir mit Kunden über die möglichen Lasttesteckdaten sprechen, dann ist immer wieder von Visits und Sessions die Rede. Beide Begriffe stammen aus dem Englischen, sind aber durch das Internet und die meist in Englisch ablaufende Softwareentwicklung in den allgemeinen Sprachgebrauch im Bereich Last- und Performancetests eingegangen. Selbstverständlich gibt es auch deutsche Entsprechungen, wenn auch weniger oft benutzt: Besuche und Sitzungen.

Warum geht es im Allgemeinen?

Visits und Sessions sind Begriffe aus der Webentwicklung, werden aber auch als Metriken im Webumfeld genutzt. Der technische Teil verbindet sich in der endgültigen Definition mit der wirtschaftlich/mathematischen zur eigentliche Bedeutung. Was wir also wollen ist: a) wissen was dahinter steckt, b) erfahren was die Begriffe definieren und c) wissen wozu man die Zahlen braucht.

Was ist ein Visit?

Wenn man sich dazu entschließt, eine Webseite zu besuchen, dann ruft man irgendwann eine erste Seite auf. In diesem Moment hat man einen Visit begonnen oder auf Deutsch – man ist zum Besucher geworden. So lange man sein Surfen auf dieser Webseite fortsetzt, solange setzt man seinen Visit fort. Alle einzelnen Seiten zusammengenommen, bilden damit, beginnnend mit der ersten Seite, einen Visit.

Für den Betreiber ist damit klar, dass ein Interessent oder Kunde seiner Webseite einen Besuch abgestattet hat. Am besten läßt sich das mit dem Besuch eines realen Ladens vergleichen. Wenn man in den Laden geht, dann beginnt man seinen Besuch/Visit und wenn man ihn wieder verlässt, dann endet der Besuch/Visit.

Natürlich gibt es auch Ausnahmen von der Regel. Wenn man nur mal schnell 5 Minuten in die Küche geht bzw. in einem realen Laden schnell zum Auto läuft, weil man sein Geld vergessen hat, dann zählt das nur als ein Visit, weil man nur eine Besuchsabsicht hatte.

Über die Metrik Visit läßt sich damit einfach messen, wieviele Besuchsabsichten pro Zeiteinheit vorgelegen haben und auch in die Tat umgesetzt wurden. Dabei spielt es keine Rolle, ob man etwas kauft, zurückbringt oder gleich wieder an der Tür kehrt macht.

Im Internet gibt es nicht nur echte Besucher, sondern auch jede Menge Automaten, die sich in den Netzweiten herumtreiben und mit jedem Abruf einer oder mehrerer Seite jeweils auch einen Visit erzeugen. Das bringt natürlich die Statistiken durcheinander. Deshalb versucht man durch technische Maßnahmen, diese meist unrelevanten Besuche herauszurechnen. Das Wie kann bei Interesse ein weiterer Blogeintrag werden.

Was ist eine Session?

Nun haben wir geklärt, was hinter dem Begriff Visit steckt, aber was ist dann eine Session?

Einfach gesagt, ist eine Session die technische Abbildung eines Besuchs/Visit. Die genutzte Technik und Software müssen sich nämlich merken, welche Anfragen zusammengehören, damit es möglich wird, Dinge wie ein Login oder einen Warenkorb technisch umzusetzen.

Sessions bestehen aus Daten, die Informationen über die Vorgänge des Visits zusammenfassen, oft als Sessioninformationen bezeichnet. Diese Datensätze haben im Regelfall eine begrenzte Lebenszeit. Wenn man seinen Visit beendet bzw. nicht fortsetzt, also nicht mehr klickt, dann beginnt eine Uhr zu ticken, die nach eine einstellbaren Zeit (oft 30 Minuten bis 2 Stunden), die Daten entfernt, damit es zu keinen Überläufen kommt. Das nennt sich Session-Timeout. Nimmt man vor Ablauf der Zeit seinen Besuch wieder auf, kommt also in den Laden zurück, dann beginnt die Uhr von Neuem zu ticken.

Vergleichbar ist es mit der Situation, dass man an der Kasse sein Geld nicht findet, den Korb schnell an der Kasse lässt, um Geld zu holen. Kommt man nun nicht rechtzeitig zurück, dann hat jemand den Korb ausgeräumt und die Waren zurückgestellt.

Die Anzahl der Sessions müsste eigentlich immer gleich der Anzahl der Visits sein. Da aber Visits oft anders gezählt werden, weil geschäftliche Kriterien dahinter stehen und keine technischen, liegen oft die Visits unter der Anzahl der Sessions pro Zeiteinheit.

Wir hoffen, dass diese kurze Erklärung hilft, die Begriffe Visit und Session zu verstehen und auseinander zu halten.

Singletons auf die faule Art

Wir hatten heute eine kurze Diskussion über Singletons und die Art und Weise ihrer Erzeugung, speziell wenn man sie faul (lazy) erzeugen möchte. Die Wikipedia hat dazu diesen schönen Eintrag – On Demand Holder Idiom:

In software engineering, the Initialization on Demand Holder idiom (design pattern) is a lazy-loaded singleton. The idiom can be implemented in both single-threaded/serial and concurrent environments, but care must be taken to correctly implement the idiom under concurrent conditions.

Ganz besondern wichtig ist die Erklärung, warum Lazy in diesem Fall so und nicht anders funktioniert:

The implementation relies on the well-specified initialization phase of execution within the Java Virtual Machine (JVM); see section 12.4 of Java Language Specification (JLS) for details.

When the class Something is loaded by the JVM, the class goes through initialization. Since the class does not have any static variables to initialize, the initialization completes trivially. The static class definition LazyHolder within it is not initialized until the JVM determines that LazyHolder must be executed. The static class LazyHolder is only executed when the static method getInstance is invoked on the class Something, and the first time this happens the JVM will load and initialize the LazyHolder class.