I’ve been busy past two weeks on a customer side in Moscow, installing and tuning the new intranet system for normative documents department of one of the largest retail banks here. The most interesting thing is that all web UI for end-users was built with the toolkit.
Can’t say this was an easy task , because main target browser version in the bank is IE6 (yep, corporate standards does not change fast) and we had to apply a lot of optimizations and workarounds for this “world’s fastest” web browser But finally, it is live and people was very impressed with it. The most thing loved by everyone is a pageless search results, that is fast even with 15K records found, thanks to Table lazy load feature and data models.
So, thanks again guys, for all your work and help, you did a great job !
yes, we had to optimize the client side, mainly the search section - there were slowdown issues because of custom columns , based on layouts and specifics of table rendering in 6.0.0 version of toolkit. 6.1 with optimized table rendered and our client side UI optimization with layout solved this.
We also actively using the “veiws” pattern, so right now we’re optimizing the complexity of nested layouts, used in the view to allow faster views switching (this is mainly for IE browsers, as Safari/FF renders pretty fast even without this).
P.S. I’m planning to publish several screenshots with a short story on what was done to this forum later this week as I get permission from the client representative.
Regarding the server side - almost no optimization were made there, we just tied this custom web interface web application to the main erm system business beans (which is an enterprise app, running the same app server). We only changed the standrad spinning wheel in CSS to a centered custom and large sized animated gif with “please wait” animation for those cases where search requests to the erm system taking more than a second.
Previously, I promised to post a couple of screenshots, so here are they finally goes.
Our client uses an ERM system to put to and keep track of internal docs and regulations that are used by all divisions across country. So, this is a web front-end for this system for fast search and access to such documents.
Nothing special was made in this project, just pure vaadin + tpt components used. We’ve only made a custom container, inspired from hbncontainer to pul lout search results from the ERM backend, combining with Vaadin’s table this allowed to quickly search and display thousands of rows without any client and server overhead.
The user interface is based on a “views” pattern via TPT. The center area displays current view, while left navigational area, top bar and status bar are just static components.
Documents are opened and displayed in a tabbed view. What we really messing here is a close button on a tab For now it is solved by having a personal “close” button on each tab’s content.
Each document also contains an attached office file (or several files). To allow quick content preview of such files, I’ve made a PDF viewer (office documents are converted on demand to PDF transparently via openoffice server), based on IcePdf rendering engine - server-side fetches particular page and page fragments on demand and client side (vaadin window and embedded component) displays it. Since IcePDF is now open sourced, Im planning to extract this viewer and made it a part of TPT package or even to a separate package.
Search results are exportable to excel file via Apache POI and Vaadin’s stream resource.
And another screenshot for the PDF view - I cannot show original document, so I uploaded different one just for test. This is a 260 MB PDF file which was created from scanned book (scanned at 300 DPI) and it contains more than 900 pages. Typical open time is 3 to 4 seconds on my powerbook (glassfish v2 as an appserver) and page or scale switch (incremental or random) is less then a 2 seconds.
Great work Dmitri. I am looking for information related to Vaadin performance and your notes are very useful.
I just need more evidence that Vaadin is fit for production environment. Obviously I will need to do my own tests.
One big drawback I can see for me is the lack of server push support (Ticket #111). Although 1 polling component is enough to update the whole window, it is still inefficient for rapid feedback.
Raymond, forgot to put usage stats for you - currently there is max peak registered with 1300 concurrent users, and daily average is 640 concurrent users. Since customer presented in all regions of Russia with up to 9 hours timezone difference, system is active and under load almost 24 hr/day. Everything is running on a single T2100 server (Solaris OS) with 16G RAM under Glassfish v2 and JDK 1.6
If you set up polling, it only sends changes from server to client and updates only the changed parts of the window. When there is nothing to update, a poll is completely invisible to the user.
In practice there are not too many places where you would like to use a real push mechanism (like the one offered by www.kaazing.com) - it requires a lot of open http connections and is quite a bit harder to deploy and maintain (there is a need for separate push server hosted in a subdomain). For many use cases polling is good enough practical solution.
That said - if your solution depends on real push, please be in touch - folks at IT Mill could probably help you in integrating a push solution (like the Kaazing) to your application.
http://code.google.com/p/gwteventservice/ looks promising; I agree we don’t need full push, we just need notification of server-side events without polling to trigger refreshes.
Dmitri, I have a question. How is Glassfish compared to Tomcat? I have been using Tomcat for so many years now (on Linux and Solaris machines) and so far, never seriously tried other application servers.
I have only Servlets. No JSPs and other J2EE features.
If one doesn’t need more than a simple Servlet Container, is there a need to use other application servers?
I had tested jetty briefly and it looked OK to me (but never deployed it in production).
I use LVS (Linux Virtual Servers) technology to scale the environment for large number of users.
by the fact, glassfish uses tomcat inside as a web container. (Yes, it also offers, by default, its new grizzly http connector but you may also revert to tomcat’s default http connector anytime by setting a system property).
We do use full jee app server because we want to run ejb from time to time or be able to run them when needed.
And we do selected glassfish mainly because of the following:
It does not require tweaks or corrections/tuning just to make it work in comparison to jboss which often requires attention
It has administration console and it is very well done and user friendly - this was very important for IT people from customers side - they’re 60% Windows people and do not like tweak xml files for everything.
Netbeans well integrated with it which is important for debugging purposes
So far, we did not notice any serious issues in production with it (for our area of application, of course, do not think it is bug free).
If your target is only servlets/jsp, I think you don’t need the complete application server, however, if you want to made domains, virtual servers, web applications, etc… management more user friendly via the web console you can give it a try.
But finally, it is live and people was very impressed with it. The most thing loved by everyone is a pageless search results, that is fast even with 15K records found, thanks to Table lazy load feature and data models. 
