Suggestions for speeding up setup time for an networked application.
Hi,
I like to develop a Java application which will resides on a network drive which can be accessed by many users (maybe 2 or 3 at the same time the max.).
This application can be run on a command line or interactively using a UI. It will use some configuration that will be read in from a file on the network drive.
I would like to look into ways to speed up the "startup/initialize" time especially if when it is running in command line.
I was wondering if you can offer any strategy/suggestions/tools that I should look into for doing this.
Thank very much.
[598 byte] By [
cleya] at [2007-11-26 13:48:40]
> I would like to look into ways to speed up the
> "startup/initialize" time especially if when it is
> running in command line.
>
Why do you think it is slow now?
And why does the start up time matter?
> I was wondering if you can offer any
> strategy/suggestions/tools that I should look into
> for doing this.
Performance is application/environment specific. The only real general solution is to profile the application. There are tools that automate this process called generically "profiler" (as suggested by the other post). You can instrument the code yourself although this is often only provides a rough picture and can sometimes lead to misleading results.
Thanks for the input...
I guess I am trying to see what my options are. It seems to be so wasteful to start up a JVM locally on each individual PC where the "startup/initialization" is all the same.
One of the command line option will be something like "-help" to let the user know what are the available options/arguments to be passed into the application.
Profiler will help identify the critical performance area/bottleneck.
Thanks...
cleya at 2007-7-8 1:24:48 >
> I guess I am trying to see what my options are. It
> seems to be so wasteful to start up a JVM locally on
> each individual PC where the "startup/initialization"
> is all the same.
Well, you could run on servers all the time, clustered, to avoid frequent startups. Then the users would use clients connecting to the servers, where most of the work would happen, maybe. Or maybe not.
But ultimately you're going to have to boot up the servers and start the server processes, so you can't avoid initialization.
If you're looking to do something more architectural than post-profiled tweaking, I suppose you can look for things that happen during run time that could better be done at compile/build time, especially for such things that happen during startup.
Also in my experience, if a system has reinvented the wheel too many times, you get long startups. Look to see where you could have just used the API but inexplicably did not.
I realize this is all basically hand-waving, but there you go.
Message was edited by:
paulcw
Thanks paulcw
cleya at 2007-7-8 1:24:48 >
> I guess I am trying to see what my options are. It
> seems to be so wasteful to start up a JVM locally on
> each individual PC where the "startup/initialization"
> is all the same.
That doesn't answer my question though.
Again why does the start up time matter?
Let me give you several examples.....
1. A server application takes 2 minutes to start up. This is a clustered server.
2. A call center has an application that each call center employee uses to work with customers. The start up time is 2 minutes.
In case 1 why would the start up time matter? It would only matter if all of the servers are down. If all of them are down then there is no transactions being processed. If only one of them is down then one of the other clustered servers deals with it.
In case 2 why would the start up time matter? Generally each call center employee only starts the application when they come in each day. Or not even then, since log in/out doesn't necessarily require the app to be exited. Now in larger call centers with short response times the start up time might matter (average call time) but in this case the solution is to allow the employee to log out with exiting the application.
Two scenarios neither one where start up time is really relevant.
In terms of resource usage on individual PCs why does that matter as well? What else is running that this is a problem on each PC? Note that even is this is an issue then it it isn't a performance/start up issue. It would be one of resource usage and it would impact the lifetime of the app not just when it starts up.
In my experience start up time has only been relevant in two situations.
1. There is only one server instance.
2. Developement time (and annoyance).
The first is a problem which obviously clustering would solve. The second although annoying is not a production problem. And thus it might not be worth spending time on in terms of the delivery schedule.
Hi, jschell.
Sorry, I should have made it more clear... This is not a server application, it is actually just a client application which is put on a network file share so more than one users can access it... I thought about using JWS to do the deployment, but since the intended users are all from the same group and share the same network share to begin with and the application will need to have access to local files, I opted for the network share over the JWS so that I don't have to signed the application.
It is currently a client type application because of the swing UI that this may need to be called when executed interactively.
The application is a data file conversion utility which is intended to convert a data file from one file type to another file type (some of which is customized data file). Currently, the design is that the application will be called for each file conversion; which is probably not very efficient, and maybe you have other ideas?
I was looking at this to learn more about options/strategies for my benefits, and here are 3 of the areas that I was interested...
1. If the user use the "-help" option to display usage help, it would be nice if the command line mode will return quickly.
2. For whatever reason, if the user chooses to say convert more than one files, it would be nice that there is someway the application won't exit and needed to be reloaded again. *The other option is to allow for multiple files specification in the command line which is going to be quite complicated since different file type has different options.
3. The initialization (configuration on which file types are supported and how they are supported) is the same and doesn't change frequently, it seems to be such a waste that each initialization will need to reset all that. Although I really don't see a good way of doing this unless I have server components like Web services or Beans to provide that sort of "information".
This is a relatively small application/utility, I cannot image it to hit any individual PC's resource limitation... I was only looking at sharing resources for efficiency and not because of constraint if there is something "simple" that I can do...
Thanks....
cleya at 2007-7-8 1:24:48 >
Exactly how long is it taking to start up?
How are you measuring initialization? I mean, what event tells you that it's done starting up and ready for user input? Is it just from the time the user starts the program to the time the GUI throws a window on the screen? If so, how long does it take to start a simple GUI "Hello World" app?
How powerful are the client machines?
You mentioned calling this from the command line. Have you considered creating a command-line UI? What happens in the GUI...just selecting a file type? That seems like the kind of thing that it would be easy to put in a command-line UI as well.
Are you doing anything in particular during the startup of your application that you suspect is taking too long? Apart from creating the GUI, what does your application do prior to the user interacting with it?
As mentioned, a profiler will tell you where you are using resources and taking time. This will provide information on where in your code you can make changes to attempt to speed up the application and in your case application startup.
But, first I would check if the network is causing the slow startup.
Run your application locally on a PC (no network access including the data) and compare the startup time to running from the server. Then try moving the data to the server and run the application timings again. Is the network the reason for the slow startup? Is it network access of the application or the data?If it is one or the other (or both), then fiddling with your code probably won't make much difference, but at least you will know.
If this is a network issue, can you move the application to the individual PC's, leaving the data on the servers? This would make for a more difficult administration of the application because you would have to update all the PC's when the application changes. Still this is sometimes done when network latency is hampering applcation performance. Sometimes an application that performs poorly on the current network is an impetus for enhancing the network infrastructure...
Good Luck!
I am really sorry...
This utility is only in design/development stage. I am just planning for the worst and see if there are options/tools/discussions out there for say that tells the machine to have the JVM around for a limited time period just so in case the application will be called again; or options for sharing resource among users.
What is a command-line UI?
The utility is basically allow users to convert one data file type to another... Pending on the input file type and the output file type, there may be various options available for the conversion. The UI will prompt or provide a screen for the user to input those options.
When the application starts up, it will load from a "global" configuration file that will tell the application the input options with default values and output options with default values by file types; it will then check to see if those default values were overriden by user's local profile. It will then check to see if it was called by using the command-line mode or not. If it was command-line, it will check to make sure all the required parameters are passed in. If it was not called by using the command-line mode, then it will popup the UI.
Thanks... I am really sorry for the confusion...
cleya at 2007-7-8 1:24:48 >
If I were you I wouldn't worry about it until you've tried it and you have real data about how well it works. That's when you use the profiler.
On some systems, I think that the Java actually may already stay resident, at least on some level. If not, maybe Java Web Start can be configured to make this happen. I've never had to look at this so I have no idea. I find that Java always starts up plenty fast.
A command line UI is one where you can start a program on the terminal, and interact with the program on the terminal. I suppose if you've only ever used a computer with a GUI you might never have seen one. So for example your program might check its arguments on startup, and if the user didn't specify something, it will ask the user for input, on the terminal (without opening any windows).
I'd suggest creating a file of defaults in the executable jar that you'd use to deploy the program. Then either create a user-selected defaults override file in the user's home directory, or better yet use the Preferences Framework.
>
> The application is a data file conversion utility
> which is intended to convert a data file from one
> file type to another file type (some of which is
> customized data file). Currently, the design is that
> the application will be called for each file
> conversion; which is probably not very efficient, and
> maybe you have other ideas?
>
Nothing indicates to me that the overall design is a problem.
Besides the questions asked by the others, how often is this actually used?
Does each user use it 50 times a day or once a week?
How timely does the conversion need to be? One alternative soluiton is to use a server that does conversions based on dropped files. The server always runs. The users drop a file into a server directory. Sometime later the result file shows up in another directory.
> I was looking at this to learn more about
> options/strategies for my benefits, and here are 3 of
> the areas that I was interested...
> 1. If the user use the "-help" option to display
> usage help, it would be nice if the command line mode
> will return quickly.
There shouldn't be any 'initialization' in this case. The only start up then is the VM.
> 2. For whatever reason, if the user chooses to say
> convert more than one files, it would be nice that
> there is someway the application won't exit and
> needed to be reloaded again. *The other option is to
> allow for multiple files specification in the command
> line which is going to be quite complicated since
> different file type has different options.
You can wrap the tool (the existing code) in a controller. The controller just keeps calling the tool with new files. The VM only runs once. This might require that the tool be modified if there are dependencies on state which are kept as statics.
> 3. The initialization (configuration on which file
> types are supported and how they are supported) is
> the same and doesn't change frequently, it seems to
> be such a waste that each initialization will need to
> reset all that. Although I really don't see a good
> way of doing this unless I have server components
> like Web services or Beans to provide that sort of
> "information".
Not sure what this is. If you are doing a lot of reflection that could impact performance depending on how you are doing it. However given that you are doing translations I would normally suspect more problem with io (file reading/writing) and the translation processing itself.
I am really sorry, I thought I had posted a response already.
Thanks for all the feedback.
Currently, there is no real issues. The application/utility is actually just under development; I am just trying to gather more general thoughts/idea as to how to design it better.
Again, thanks for all your feedback. It helps me think and plan a better application.
cleya at 2007-7-8 1:24:48 >
