Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Erfahrungen / Meinungen zu Vaadin

441 views
Skip to first unread message

Chris Seidel

unread,
Jan 26, 2011, 5:19:58 AM1/26/11
to
Hallo,

kann hier jemand bereits über praktische Erfahrungen (am besten sogar
produktiv) mit Vaadin berichten? Oder theoretische Meinungen...

Find es kurz betrachtet sehr gut, nur hab ich kein gutes Gefühl in Sachen
Performanz / Skalierbarkeit, dass jede UI-Aktion vom Server behandelt wird.

Danke

Michael Justin

unread,
Jan 26, 2011, 9:04:10 AM1/26/11
to
Am 26.01.2011 11:19, Chris Seidel wrote:
> Hallo,
>
> kann hier jemand bereits über praktische Erfahrungen (am besten sogar
> produktiv) mit Vaadin berichten? Oder theoretische Meinungen...

Praktisch: http://habarisoft.appspot.com/sx

Eine kleine interaktive Demo für einen RTF -> XHTML Konverter, benötigte
wenige Stunden vom ersten Entwurf (als Vaadin Anfänger).

> Find es kurz betrachtet sehr gut, nur hab ich kein gutes Gefühl in
> Sachen Performanz / Skalierbarkeit, dass jede UI-Aktion vom Server
> behandelt wird.

Skalieren erledigt die App Engine, oder der Web Container z.B. JBoss
oder GlassFish schon - solange Vaadin und die eigene Anwendung sich an
die entsprechenden Spezifikationen und Best Practices hält, kein Problem.

Performanz: welche UI-Aktionen der Server behandelt, kann man pro
Control steuern, z.B. um Daten erst auf Drücken eines Submit Buttons auf
den Server zu übertragen, im Prinzp genau wie bei einem HTTP POST.

--
Michael Justin

Chris Seidel

unread,
Jan 26, 2011, 10:23:03 AM1/26/11
to
On Wed, 26 Jan 2011 15:04:10 +0100, Michael Justin
<michael...@nospam.gmx.net> wrote:

> Performanz: welche UI-Aktionen der Server behandelt, kann man pro
> Control steuern, z.B. um Daten erst auf Drücken eines Submit Buttons auf
> den Server zu übertragen, im Prinzp genau wie bei einem HTTP POST.

Na gut, das erwartet man ja, dass ein Formular erst bei Submit gesendet
wird.

Ich meine solche Dinge wie z.B. das Sortieren einer Tabelle,
Anzeigen/Verstecken von UI-Elementen oder Validierung was man ja auch
komplett lokal mittels Javascript tun könnte. Das soll bei Vaadin wohl
fast immer in einen Serveraufruf münden.

Das hier http://demo.vaadin.com/Calc ist vlt. ein schlechtes Beispiel,
aber hier endet wahrlich jeder Click auf dem Server. Dementsprechend träge
fühlt es sich auch an.

Sascha Broich

unread,
Jan 26, 2011, 11:12:21 AM1/26/11
to
On Wed, 26 Jan 2011 16:23:03 +0100, Chris Seidel wrote:

> Ich meine solche Dinge wie z.B. das Sortieren einer Tabelle,
> Anzeigen/Verstecken von UI-Elementen oder Validierung was man ja auch

> komplett lokal mittels Javascript tun k�nnte. Das soll bei Vaadin wohl
> fast immer in einen Serveraufruf m�nden.

Naja, daf�r �bertr�gt er aber von der Tabelle nur so viel, wie sichtbar
ist. D.h. sortiert wird zwar auf dem Server, angezeigt wird aber nur wenig.

Performance-technisch sieht es eigentlich normal aus, wie eben bei einer
Ajax-Anwendung.

Wenn du lieber mit clientseitigiger Logik arbeiten m�chtest, empfiehlt sich
Smartgwt.

> Das hier http://demo.vaadin.com/Calc ist vlt. ein schlechtes Beispiel,

> aber hier endet wahrlich jeder Click auf dem Server. Dementsprechend tr�ge
> f�hlt es sich auch an.

demo.vaadin.com ist an sich ein wenig tr�ge. Aber wenn man eine
Tastatureingabe �ber den Server-Umweg baut, wird es immer tr�ge wirken.

An sich gr��ere Verz�gerungen ohne wirkliche Arbeit auf dem Server habe ich
bisher noch nicht gehabt.


Leider kann ich nicht mit eigenen Online-Beispielen dienen, da unsere
Software nicht �ffentlich ist. Aber wir bauen schon etwas gr��eres im
e-Goverment-Bereich (Projektplan > 12 Monate) mit Vaadin.


Sascha Broich
--
Wodurch er zu erinnern liebt,
da� es ihn immerhin noch gibt.
(C. Morgenstern)

Chris Seidel

unread,
Jan 26, 2011, 11:56:15 AM1/26/11
to
On Wed, 26 Jan 2011 17:12:21 +0100, Sascha Broich
<nospam...@sascha-broich.de> wrote:

> Aber wenn man eine
> Tastatureingabe über den Server-Umweg baut, wird es immer träge wirken.

Eben das ist meine Befürchtung. OK, nicht jeder Tastenanschlag, aber eben
sehr viel, was man eigentlich auch auf dem Client abfackeln könnte.
In meinem Falle geht es um eine Anwendung (Klassisch MVC), die derzeit auf
einem Server mehr als 3000 Kunden mit zig tausenden Benutzern abfackelt.
Wenn man dann nur wegen Vaadin 10 Server braucht, dann war's das nicht.

> Leider kann ich nicht mit eigenen Online-Beispielen dienen, da unsere

> Software nicht öffentlich ist. Aber wir bauen schon etwas größeres im


> e-Goverment-Bereich (Projektplan > 12 Monate) mit Vaadin.

Wie weit seid ihr da?
Für wie viele gleichzeitige User soll das gehen?
Lasttests schon gefahren?

Kennt jemand ev. eine Vaadin-Anwendung, die man im Netz testen kann?

Danke

Bernd Eckenfels

unread,
Jan 26, 2011, 5:03:50 PM1/26/11
to
Chris Seidel <cr_s...@arcor.de> wrote:
> kann hier jemand bereits ᅵber praktische Erfahrungen (am besten sogar
> produktiv) mit Vaadin berichten? Oder theoretische Meinungen...

Wir machen grade ein paar Projekte, auch in zusammenarbeit mit ITMills, aber
produktive Erfahrungen haben wir noch nicht. Es lᅵuft jedenfalls recht
flott.

> Find es kurz betrachtet sehr gut, nur hab ich kein gutes Gefᅵhl in Sachen

> Performanz / Skalierbarkeit, dass jede UI-Aktion vom Server behandelt wird.

Bei Sites mit vielen Usern/Sessions kᅵnnte das erhᅵhten Bedarf an Hardware
nach sich ziehen (ist bei uns nicht so das Problem). Auf der anderen Seite
ist es immer noch schneller als traditionelle Web 1.0 full-page requests.

Kritischer sehe ich aber die Client Performance, besonders bei aktuellen
langsamn Javascript Engines und komplexen Dialogen.

Ausserdem sind HTML Style Links/Navigations etwas aufwᅵndiger. Und wenn man
auch eine non-js Version haben will ist es IMHO ein Nogo.

Gruss
Bernd

Bernd Eckenfels

unread,
Jan 26, 2011, 5:05:35 PM1/26/11
to
Michael Justin <michael...@nospam.gmx.net> wrote:
> Skalieren erledigt die App Engine, oder der Web Container z.B. JBoss
> oder GlassFish schon - solange Vaadin und die eigene Anwendung sich an
> die entsprechenden Spezifikationen und Best Practices hält, kein Problem.

Abgesehen von der Serialisierung der Session (der Vaadin App und alles was
dranhängt). Da muss man aufpassen wenn man mit Session Failover clustern
will.

Gruss
Bernd

Bernd Eckenfels

unread,
Jan 26, 2011, 5:07:19 PM1/26/11
to
Chris Seidel <cr_s...@arcor.de> wrote:
> Das hier http://demo.vaadin.com/Calc ist vlt. ein schlechtes Beispiel,
> aber hier endet wahrlich jeder Click auf dem Server. Dementsprechend trᅵge
> fᅵhlt es sich auch an.

Ich finde auch sie sollten typische Abhᅵngigkeiten Client-seitig einbauen
(Events, Filter, ...). Aber das ist in der Architektur gut nachreichbar.

Gruss
Bernd

Sascha Broich

unread,
Jan 27, 2011, 5:37:43 AM1/27/11
to
On Wed, 26 Jan 2011 17:56:15 +0100, Chris Seidel wrote:

> In meinem Falle geht es um eine Anwendung (Klassisch MVC), die derzeit auf
> einem Server mehr als 3000 Kunden mit zig tausenden Benutzern abfackelt.
> Wenn man dann nur wegen Vaadin 10 Server braucht, dann war's das nicht.

Nunja, die Sache mit dem Session-Overhead ist ist bei der Größenordnung
sicherlich zu bedenken. Andererseits sind es ja vor allem die Daten, die
den Overhead erzeugen, nicht die Logik oder die Oberfläche.


> Wie weit seid ihr da?

Nunja, wir sind etwa im ersten Drittel, haben aber auch schon eine andere,
kleinere Anwendung (mit Vaadin) fertig.
Die Web-Oberfläche reagiert bisher recht flüssig, unsere alte PHP-basierte
Version ist da deutlich träger.


> Für wie viele gleichzeitige User soll das gehen?

Wir rechnen mit im Mittel 100 Usern gleichzeitig, allerdings werden wir
auch viel Last über Webservices haben.

Ordentlich RAM ist beim JBoss fast schon Pflicht, der Sockelverbrauch liegt
doch recht hoch.


Sascha Broich
--
Heute verlierst du.
Morgen gewinnen die Anderen.

0 new messages