Where Should EXE's Launch From- Server or User's Local Hard Drive? 10

[drosenkranz]

Hello,

We're having a philosophical discussion in terms of performance on where the EXE should be launched from, the server or the local user's hard drive.

Option #1 says that the EXE should be launched from the user's local hard drive. An update program on the user's machine checks the server for an updated version of the EXE. If the EXE on the server is newer (an update), then the file is first copied down to the local user's hard drive and then launched from their own hard drive. Whether an update occurs or not, the EXE is always launched from the local user's hard drive.

Option #2 says the EXE should reside on and be launched from the server.

All databases reside on the server for both options. We have 650+ users that may need to run one or more applications at a time.

Which option is the better choice in terms of performance & network resource usage?

Thank You For Both Your Time And Input,

Dave
The 2nd mouse gets the cheese.

 

[ramani]

Hi
1. Hands down or Up... Option 1 is my choice for best performance for the level of users you are talking.

2. ALways, check for the version number and if the users version is old.. download from server the latest version.
This is tricky though, since the EXE running cannot copy on to itself. YOu have to devise this in indirect way so that the executable can be copied and then rerun.

ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com
Merry Christmas & Happy New Year

 

[jesylv]

I agree with Ramani for a network that size however I have been using option 2 on sites with up to 50 users with no noticible impact on performance.

The limit is in fact a combination of application size, network speed, network traffic, application server speed (Data thoughput), and number of users.

Please note the following caveat:
If all users login at about the same time, the network will experience traffic saturation and the application will take for ever to load.

Jean

 

[Walid]

Does any one remember what is the sequence of loading executable file in Intel systems.
To make a long story short, the application has to be in your machine memory for your OS to execute.
Based on this fact, I really don’t understand what is the moral of this philosophical discussion. When you double click an EXE file in your network, meaning you brows the network and found an *.AVI on your friend’ computer, so you decided to see what is that and doubled clicked it. All the binary will travel to you computer for execution. Try it, go to the remote computer and see in the task manager-> Process, the process you just instantiated is no where to be seen. So what is the point behind even thinking about launch the application, or to be accurate, save the application on the server. Do I miss something?
Are you guys talking about COM object in EXE format not a stand alone EXE, maybe!!
Walid Magd
Engwam@Hotmail.com

 

[Scott24x7]

Walid,
Your point is valid, in that the .EXE is running on the local machine, not on the Server. Unless you are using something like MS Terminal Services, or Cytrix, that will be the case, BUT, there's still a "Gotcha" lurking in the bushes.
By launching the .EXE from the server, across your network, you are now still USING the .EXE that is on the server. So, you have a file handle to that .EXE from your machine. The network traffic has now been increased, because your machine is constantly communicating with that .EXE file via the handle that you have created with it, thus increasing your network traffic considerably. Where as something like Cytrix or TS continually feed "Screen updtes", you only get these when the screen changes, and these usually have between an 8k and 20k bandwidth requirment, so on even a 10baseT network, you wouldn't notice much. It's when you start shoving all that .EXE traffic over the same bandwidth that your data is moving across, it becomes "Traffic Jam" much quicker. Better for your network performance to launch .EXE's from local machines, NOT from servers.
Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[wgcs]

Now, with Option #1, we're not talking about the EXE on server deciding whether the client should be updated or not... we're talking about two pieces: (A)One that rarely changes and (B) one that is updated.

(A) Is the EXE, and resides on every client. All it needs to do is know where to look on the server for the updated version of (B), and how to check if the updated version is actually newer than the (B) that is on the client.

(B) can be an EXE or an APP, and isn't executed by (A) until (A) has determined that the latest copy of (B) has been copied onto the client.

This setup is more complicated than (2) above, but will always yield better network bandwidth usage, since each version of the EXE is only copied across the network to each client Once, where with (2), above, the EXE is "copied" (to be executed) to each client EVERY time the EXE is run.

 

[ramani]

Hi Wgcs,

The modus operandi is quite simple.
Always start the application via a batch file. This can be done thru VFP code also, but for simplicity I am taking of a batch file.. the analogy can be extended by other ways also.
A.bat
*****
EXE1
EXE2

Now in the exe1.. look for the date of creation of EXE2 thru ADIR() at the server software place. If that date varies from the ADIR() of the same file in the local directory.. do a file copy. and exit cool.
Now EXE2 will take over.
The extra load is running a small executable EXE1 ahead of the real executable EXE2.

Another way to avoid a.bat is to run the EXE2 thru windows options .. first run EXE1. In windows shortcut this provision is available.

Also.. if some one bypass the a.bat or the shortcut.. your applications EXE2 should first check for the version number of the executable and the parameter field stored somewhere in the server data (may be in the owner file.. one field for this).. and if older version.. show the door.

SO with this combination.. the purpose can be achieved easily. ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com
Merry Christmas & Happy New Year

 

[Walid]

Scott,

Thanks for your response. I want to assure you that there is no file handle what so ever on the machine hosting the executable file. Once you have the binary transferred to your local computer, you can go ahead and turn the other machine off as far as your program is self contained - doesn¡¦t reference any resources in the remote machine - , you will be fine. Unless we are talking about a file server scenario like VFP Client/File Server for instance, there is no point to lunch the application from the server. Even with 10/100 Ethernet you will saturate your band width so fast especially in multi-user environment. Finally, I hope your hammer is not on my head -ƒº

Ramani,

I suggest you start every application by instantiating an application object, this will be the controller of the whole entire program. Something like
goMyApplication = CreateObject(¡§MyApplication¡¨)
Exactly like what we do with Excel or Word

This object then will handle the live update function as it was programmed or configured in the system files.
For instance, log to the company that programmed the App¡¦ FTP server looking for updates, download them and overwrite the old ones then start your main App after that.

The idea of the application object is very powerful for this kind of functionality

Happy holidays for all of you.



Walid Magd
Engwam@Hotmail.com

 

[Scott24x7]

Walid,
Sorry, still can't fully agree with your statement. Try this:
Put an .EXE on your local machine. Run it. While the app is running, try to delete the .EXE file. OS will not allow it. You will get the messsage "The process cannot access the file because it is being used by another process." (using DOS prompt, or "Can not delete: Access Denied" if using windows highlight icon, press delete key).

Put the same .EXE on a server. Run it. While it's running, try to delete the .EXE. Again, OS on either machine will not allow, because the .EXE is currently in use. Exact same results as above. This file is LOCKED. The only way to have the file locked is to have a handle to that file. The OS DOES transfer the binary data to the PC running the app, BUT, it also maintains a connection to that file. This simple test proves that to be the case.

Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[drosenkranz]

Hi Everyone,

Thanks for all the inputs - very helpful having some insights from people other than those working out the issues at our end.

I did notice (and was curious why) I couldn't delete (or rename) an EXE when it's already in use (launched) out on the server (or my local machine for that matter). Any more info and opinions on EXE launching locations would be greatly appreciated on this end.

Thanks For All Of Your Time And Energy,

Dave The 2nd mouse gets the cheese.

 

[Walid]

Scott,
I apologize if I didn’t make my self clear. Sure, I didn’t mean that you can delete a process while it is already running, any decent OS will reject this command.
I will use this example to clarify my point
Consider this scenario, Friday 4:45 PM the project manager assigned an urgent bug fix to you – sound familiar??!! - it was in the old system which was written entirely with FoxPro for Dos. Sure enough, you don’t have this version in your local computer but you know that your coworker John has it on his computer.
So, you brows the network and access this particular computer and double click Foxprox.exe and you now have this historical version up and running.

At the moment, leave your program running and go to your hypothetical friend John and take a look on his Task Manager, Processes tab.
Foxprox.exe is not there. Lets go one step further with all due respect to John, go ahead and delete this file from his machine – actually I just did that and came back – HIS OS WILL NOT GOING TO COMPLAIN, and happily enough, it will obey your order and delete the file because this process IS NOT RUNNING ON THIS COMPUTER. Remember that we still in John’s office playing with his machine, Sorry John or Kally in my case.

Now, go back to your computer and continue doing any thing with the Foxprox.exe, it will run fine because all the binary actually is on your own computer.
The process Foxprox.exe is there in your task manager, sure you can’t delete this process from YOUR computer while it is already running.

Now, issue the command quit and don’t forget to go back to Kally’ machine and restore his program from the trash can, I will BRB.

This was my point when I said it is not such a good idea to lunch a program from the server while it will run entirely on the client with no assistance or work load distribution between the client and the server. It is no more than wasting band width.

I hope I made my self clear this time.
Happy holidays
Walid Magd
Engwam@Hotmail.com

 

[jaa69]

Hands down

Running the Exe on the workstation will run many times fast especailly with that many users. This part of the question is a no brainer. Now the batch file trick works perfect for checking the version of the program.

I would use the following
AGETFILEVERSION(aversion,"c:\Myprog.exe" )
AGETFILEVERSION(aversion2,"f:\Myprog.exe" )
if aversion[4] != aversion2[4]
* Do your copy update here
endif

That will compare the version numbers of the applications this can be part of a batch file that fires when it is launched from the desktop.

Hope this helps. Running it on the workstation also prevents slow networks taht Net Admins deny exsist. Data Access will not change, but the application will not take 10 minutes to come up when fired. So much better choice.

 

[clarkrj]

Hi

I favour running on the workstation for another reason.

Have you tried getting 650 people to logout at the same time when you want to put an updated EXE on the server.

You would be in for a VERY stressfull time


Rich

 

[chpicker]

I cheat. I have a single field in a database that I can change, and *POOF* all users apps immediately close themselves down, and it won't let them back in. *grins*

Other than that, I also use a Loader program. This loader program is located on the user's machine. It compares the timestamp on the user's copy with the copy on the server and copies it over if it doesn't match. Regardless, it then launches the app.

I also pass a command-line parameter to the app to let it know that it was opened by the launcher. The app will refuse to run unless opened by the launcher. Sure, this is easy to bypass by any competent computer user...but how many of your users fall under this category? *grins*

Walid...your scenario does not work. If you browse to another computer on your network and double-click on an EXE file to run it directly from there, you cannot then delete the EXE file, no matter what computer you try it from, until you quit the program. Windows will not allow it, either on your computer or the computer that actually contains the file.

Ian

 

[DanEvansJr]

I see that this debate still rages . . .

For many years, I was a staunch proponent of option #1, running a single EXE from a fileserver location, but as my applications grew, my skills improved , and the number of users grew, I decided to TRY option 2.

From their local machine, my users run what I call a 'runner' exe that does the version checking for me. If there's a newer version of the main application on the file server, runner.exe copies it down and then uses shell32.dll to run it.

That's not all, upon shutdown, the application itself looks for a newer version of the runner.exe. That way, I'm assured that when a user loads up the app, they're getting the latest version of the application and the app loader.

There's a little more programmatic work, but trust me, this is a hell of a lot easier than telling 100+ people to vacate an application because you need to make an update.

 

[drosenkranz]

Hi DanEvansJR,

Thanks for the feedback but... Your response begs another question:

How did you copy a new version of the "runner" EXE program back to the user's PC while it's (still) running?

I also have my users launch their "runner" EXE which checks for the newer version of the "main" EXE. If newer version exists on the server, then it copies it (the "main" EXE) down to the user's local hard drive first - then launches it from the user's PC.

But in your case - After your user finishes running their "main" EXE, how did you manage to copy the newer version of the "runner" EXE down to the user's PC while the original "Runner" EXE is still running?

Are you using a batch file (DOS) to launch the EXE's? (this would explain it)

If not... I'd love to know how you did that. Please... Do Tell.

Dave The 2nd mouse gets the cheese.

 

[skoko]

My application first check with server if its current now. If its not application shut down with message to update. Each user have icon on desktop for update (batch file that copy file \\server\folder\file.exe c:\folder)

 

[clarkrj]

It would be automatic if you used a batch file

I don't know if an EXE could be created which launched an APP file to check the dates, then launched the second APP file when it had been updated.

Anyone got time to test this?


Rich

 

[RLG07734]

Dave:
I tend to do mostly the same thing... use a 'runner.exe' to launch apps. But runner.exe is only a shell... checks all the apps against the server and downloads new ones. runner.exe never needs updating, since all the code is in the .app files. All runner.exe does is:
1. checks existing local files for updated versions on the server using adir commands.
2. downloads any .app file that exists on the server but doesn't on the local (again using adir commands).
runner.exe doesn't change.

Ron

 

[bholmstrom]

To chpicker:

Your Response above:

I cheat. I have a single field in a database that I can change, and *POOF* all users apps immediately close themselves down, and it won't let them back in. *grins*

Other than that, I also use a Loader program. This loader program is located on the user's machine. It compares the timestamp on the user's copy with the copy on the server and copies it over if it doesn't match. Regardless, it then launches the app.

I also pass a command-line parameter to the app to let it know that it was opened by the launcher. The app will refuse to run unless opened by the launcher. Sure, this is easy to bypass by any competent computer user...but how many of your users fall under this category? *grins*

Walid...your scenario does not work. If you browse to another computer on your network and double-click on an EXE file to run it directly from there, you cannot then delete the EXE file, no matter what computer you try it from, until you quit the program. Windows will not allow it, either on your computer or the computer that actually contains the file.

Ian

Question:

What is the "loader" program you use, I am very interested in moving my cusotmers from "server" based exe to a client based "exe". The program is becoming quite large, and sevearl clients are feeling the stress

Thansk

Bryan Holmstrom
bholmstrom@conduitsoft.com