Java Menu Overhead November 13, 2008
Posted by Adam in: Cool Stuff, General, Sunray, add a commentTags: java menu, java menu overhead, java overhead, sun menu memory, Sun-Ray, sunray menu memory
Although the Java menu seemed like a good option, when we ran the figures, it seemed the overhead really was a little excessive when one considers that no extra functionality was provided; only some smoother edges.
These figures were taken from a sample and represent estimates.
The Tcl menu (menu displayed, not connected to windows): 30Mb.
The Tcl menu (menu is still active in background, user connected to windows): 45Mb.
The Java menu (menu displayed, not connected to windows): 70Mb.
The Java menu (menu is still active in background, user connected to windows): 90Mb.
We can reduce the Java overhead by roughly 20Mb if we remove the Java window manager, this will reduce the functionality of the JFrame, but it is a worthy sacrifice for the memory we save.
That brings our new totals for the Java menu to 50Mb (not logged in) and 70Mb (logged in).
So assuming we have removed the Java windows manager, the difference between the menus is roughly 25Mb per user. This means for every two users on the Java menu, we could have three users on the Tcl menu.
Let us take a crude example of a sun server with 16Gb RAM; 350 Tcl users or 230 Java users (Not these figures are theoretical and using 100% of the memory). Thus I would make another sweeping estimate and for a stable system, divide these totals in half. Giving us a final total of 175 Tcl users or 115 Java users: that is 60 extra users on the Tcl menu!
So what is the conclusion? It depends on your setup, priorities and of course budget. Does a slightly more stylish menu warrant the memory overhead? In most cases I would assume the reason why Sunrays are being used in the first place, is to cut costs and deploy in a large scale environment, so unfortunately attractiveness will be an afterthought.
With functionality, efficiency and capacity being paramount; I decided on Tcl.
…for the moment…
A bright dawn for sunrays November 10, 2008
Posted by Adam in: Cool Stuff, General, Green Computing, Sunray, 5 commentsTags: java menu, java swing, Sun-Ray, swing, tcl, tcl java development, Tcl smoothing, wish8.5
“You never get a second chance to make a first impression.”
The core of the new sunray release was to ensure the sunray server software were setup in an optimal manner. Moving onto new and powerful servers, with a fresh install configured for performance.
However the key to accessing this functionality is the menu screen. To focus to the latter stages of the project the menu has undergone several stages of development using the Waterfall model for software life cycle.
Obviously this element to the project is where the users will get their first impressions, deciding on their likes and dislikes of the system as a whole, so getting the front end as user friendly as possible was key to the design and planning. Research was conducted on several possibilities and in the end we narrowed it down to two potential languages; Tcl and Java. The menu which had previously been made and used was written in Tcl and with its two buttons, chiefly acted as a floodgate for the sunrays – if the menu were not there; the sunray devices simply cycle continuously waiting for a server or else connect to a terminal server utilising resources when there is no demand. But now we needed more functionality and implemented in such a way that actually reduces the hassle of logging in, rather than adding another stage to the process.
The prototype for the system seemed to perform effectively, although by no means complete it had the core functionality and no major issues arose. The most negative feedback was due to the slightly overwhelming blue and clumsy buttons.
Ideally we needed a simple login menu, without too much information, yet intuitive enough to understand immediately without guidance. Our original two button interface had roughly a dozen variations for connecting to different servers which made updates laborious. There must be facility to input a username and password, select screen resolution and be resistant to any tampering.
Given the adaptability of Java, it seemed like a logical move to create a visually superior model. Using java swing we created a slick and fully functional menu.
The JFrame itself is expandable, allowing for additional options to be displayed without requiring a new window.
However when analysing the memory overhead, the use of a Java menu utilised substantially more memory than the Tcl menu. This overhead unfortunately meant it would not be a feasible option when compared to the lower requirements of Tcl.
Thus we revert back the previous possibility of a Tcl menu, though there were several changes which needed to be made. The visual aspects of the menu were simplified and colours were swapped for a more sensible greyscale.
With the new buttons, a dropdown menu was created to reduce the requirement for extra shell scripts. Now the majority of the menu and its functions will run directly from the original Tcl script.
Finally, the only issue left with the menu was the slightly blocky fonts used. We had originally overcome this problem by using images rather than text labels, but this isn’t the ideal solution as changing text becomes an annoyance. Instead by downloading the most recent version of Tcl (and wish), smooth rounded fonts are available and the final result – I think – looks stylish and more importantly works efficiently and effectively.
