I need some big time help speeding up an installation. If this isn't the best place for this post please let me know and I'll repost under another section. I've built a standard installation Using InstallShield Windows Installer 2.01. The install is composed of 7 custom merge modules and a handfull of type 38 CA's that execute some very simple VB code. The compiled network MSI with all files compressed is about 25MB. It takes about 2-5 minutes for the installer to initializa before the welcome screen ever appers and about the same ammount of time to deliver the files and configure the machine.... I need to cut the installation time down by at least half. I must deliver the product from the network (Can't deliver to the user's hard drive or CD). Other than that I'll take whatever suggestions anyone has nomatter how outrageous.
Thanks
Michael Scilingo
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
HELP!! Installation performance HELP!!
Started by
mscilingo
, Sep 09 2002 18:36
10 replies to this topic
hambone
-
- Members
- 206 posts
Posted 09 September 2002 - 18:50
okay then, first you need to get yourself a left-handed chicken, avoid getting a right-handed one because they have a tendency to be to high strung. next go to a large field that has a western exposure ( avoid fields that are surrounded by trees as the left-handed chicken will have a tendency to run into the woods ). finally you have to ....
but on a more serious note, how about using a smaller msi to launch the install of the larger one. using a 25MB msi requires that 25 MB be copied to the local system and then installed. using a smaller msi to launch the other should allow you to post a message to the user alerting them to expected delays on install.
other options inculd checking the MTU ( maximum transmission unit ) size for the network connection and verifying that you are optomized for the type of connection used.
hope some of that helps or twigs someone else to provide other options... good luck...
but on a more serious note, how about using a smaller msi to launch the install of the larger one. using a 25MB msi requires that 25 MB be copied to the local system and then installed. using a smaller msi to launch the other should allow you to post a message to the user alerting them to expected delays on install.
other options inculd checking the MTU ( maximum transmission unit ) size for the network connection and verifying that you are optomized for the type of connection used.
hope some of that helps or twigs someone else to provide other options... good luck...
mscilingo
-
- Members
- 5 posts
Posted 09 September 2002 - 20:22
Thanks Hambone,
Left handed chickens are out of budget till next year
Seriously though, not a bad idea about launching one msi from another. But it still doesn't make the total install time any faster, which is what my boss is looking at. Network bandwith in relation to MSI size is a good point. The MSI reference says I can make my MSI smaller by using orca to export all tables and import them into a new project, but I've never been able to make this work... I'm still open to suggestions the task masters are beating their drum harder than ever
--Mike
Left handed chickens are out of budget till next year
Seriously though, not a bad idea about launching one msi from another. But it still doesn't make the total install time any faster, which is what my boss is looking at. Network bandwith in relation to MSI size is a good point. The MSI reference says I can make my MSI smaller by using orca to export all tables and import them into a new project, but I've never been able to make this work... I'm still open to suggestions the task masters are beating their drum harder than ever--Mike
Leigh Ravenhall
-
- Members
- 269 posts
Posted 10 September 2002 - 06:53
Glad I don't work for your boss. I've got a 35Mb compressed installation package that has an execution time somewhere between 15 and 45 minutes after the copying, depending on the speed of the machine.
And your boss is objecting to 5-10 minutes? He should be offering prayers to anyone that will listen thanking them he has you rather than me.
And your boss is objecting to 5-10 minutes? He should be offering prayers to anyone that will listen thanking them he has you rather than me.
Ian Blake
-
- Members
- 483 posts
Posted 10 September 2002 - 09:18
I was a little unhappy with my small msi because it was 6Mb. I traced the problem to custom actions made by Installshield. They made merge modules for old style Microsoft packaged installs eg. DCOM95.exe and placed these in the binary table. I was able to reduce the size of my msi by moving such programs to the source and installing and running them from source. This is one way to make a lighter msi.
Another thing to avoid. Do no wrap everthing into a single .exe file. The exe file needs to be unpacked to make a .msi and .cab file which takes time. If the .cab is seperate from the .msi the source file will remain on the source media until needed.
I believe the fastest way to execute is not to compress but could result in excessive storage requirements that might remove any advantage.
Another thing to avoid. Do no wrap everthing into a single .exe file. The exe file needs to be unpacked to make a .msi and .cab file which takes time. If the .cab is seperate from the .msi the source file will remain on the source media until needed.
I believe the fastest way to execute is not to compress but could result in excessive storage requirements that might remove any advantage.
Ian Blake
(Currently Unemployed)
(Currently Unemployed)
mscilingo
-
- Members
- 5 posts
Posted 10 September 2002 - 14:11
Ian and Leigh,
Thanks for the reply. Actualy Leigh, you're right, he is being totally unresonable in his request, but since he signs the checks, the best I can do is to make him happy.
The only merge modules I have in the install are the 7 I built myself, they range in size from 300KB to 1.8 MB and must remain Merge Modules since they are all shared components that may be used by other apps.
The build must be compressed because server space is at a premium. However, I did like the idea about splitting the cab file from the MSI, that could pose an interesting solution that I will test today.
Still, I'd like to hear other people's ideas and opinions about my setup issue and my tyranical boss
Best Regards
--Mike
Thanks for the reply. Actualy Leigh, you're right, he is being totally unresonable in his request, but since he signs the checks, the best I can do is to make him happy.
The only merge modules I have in the install are the 7 I built myself, they range in size from 300KB to 1.8 MB and must remain Merge Modules since they are all shared components that may be used by other apps.
The build must be compressed because server space is at a premium. However, I did like the idea about splitting the cab file from the MSI, that could pose an interesting solution that I will test today.
Still, I'd like to hear other people's ideas and opinions about my setup issue and my tyranical boss
Best Regards
--Mike
Ian Blake
-
- Members
- 483 posts
Posted 10 September 2002 - 16:57
Just to clarify my opinion. There is nothing wrong with merge modules. The problem is placing large exe files in the Binary Table.
Running the exes from source has the disadvantage that IS does not allow some files to be compressed and others compressed. MSI does allow this.
Running the exes from source has the disadvantage that IS does not allow some files to be compressed and others compressed. MSI does allow this.
Ian Blake
(Currently Unemployed)
(Currently Unemployed)
mscilingo
-
- Members
- 5 posts
Posted 10 September 2002 - 17:29
Ian,
Sorry for the confusion, my misunderstanding. Actually, all of my exe's are fairly small, and I'm getting a pretty decent compression ratio (about 80%) overall. So no big complaints there. Splitting the cab file out from the MSI made things run a little faster. It now only takes about 45 seconds to initialize and about 4:30 to run including removal of the previous version with full UI enabled.
Personally I think I'm not going to be able to do any better than that, but I'm still slower than the last version by almost 2 minutes... Damn Code bloat! I wonder if it will do any better with the UI disabled... back to testing.
--Mike
Sorry for the confusion, my misunderstanding. Actually, all of my exe's are fairly small, and I'm getting a pretty decent compression ratio (about 80%) overall. So no big complaints there. Splitting the cab file out from the MSI made things run a little faster. It now only takes about 45 seconds to initialize and about 4:30 to run including removal of the previous version with full UI enabled.
Personally I think I'm not going to be able to do any better than that, but I'm still slower than the last version by almost 2 minutes... Damn Code bloat! I wonder if it will do any better with the UI disabled... back to testing.
--Mike
Leigh Ravenhall
-
- Members
- 269 posts
Posted 11 September 2002 - 01:48
Are you using InstallScript? If you do, you'll be including a couple of extra meg of InstallShield scripting engine files. Without InstallScript, you should also save some time by skipping the initialisation of the scripting runtime.
mscilingo
-
- Members
- 5 posts
Posted 11 September 2002 - 16:59
Leigh,
Thanks for the reply. Actually I was confused about something regarding the installscript engine. I have no installscript code in this installer. Only CA type 38 that kicks off some one-liner Vbs code, but ISSCriptBridge.DLL, IsConfig.ini, ISRT.Dll, ISScript.MSI and InstallScript are still listed in my Binary table. Does this mean that CA type 38 is treated like installscript? Since Windows 2000 already has the VB Script engine built in, and I don't need the installscript engine, how do I get around this?
Thanks for the reply. Actually I was confused about something regarding the installscript engine. I have no installscript code in this installer. Only CA type 38 that kicks off some one-liner Vbs code, but ISSCriptBridge.DLL, IsConfig.ini, ISRT.Dll, ISScript.MSI and InstallScript are still listed in my Binary table. Does this mean that CA type 38 is treated like installscript? Since Windows 2000 already has the VB Script engine built in, and I don't need the installscript engine, how do I get around this?
Leigh Ravenhall
-
- Members
- 269 posts
Posted 12 September 2002 - 02:38
I guess you could remove the ISScript stuff manually using ORCA after the installation is built. You may also have to remove the actions that start and stop the InstallScript runtime engine.
Another thing, if you run the installation with full logging, the log file should be able to tell you where all the time is being taken.
Another thing, if you run the installation with full logging, the log file should be able to tell you where all the time is being taken.