Page 1 of 1 1
Topic Options
#208269 - 2014-01-07 08:52 PM Kix32.exe is too large, I use an old version.
Robdutoit Offline
Hey THIS is FUN
***

Registered: 2012-03-27
Posts: 310
Loc: London, England
I have been grave robbing again and I have unearthed this rather interesting thread! I don't want to continue the discussion of whether kix32 is too large etc as I think that argument is irrelevant as kix32.exe is quite small compared to a lot of things out there.

But I would like to ask two questions about things that I picked up here.

Tokenising. With emphasis on reducing file size (not obfuscation) I still have not got around to tokenising my scripts, due to so many other more urgent things to do and just general lack of time. However I wanted to ask, is it possible to tokenise the scripts so that the main script calls the pupils script, the staff script etc? I assume that it does this as most people probably have scripts calling other scripts.

What really prompted me to raise this question is the suggestion that people are copying the kix32.exe file to the local machines and running the scripts by calling the kix32 locally. I have been running the scripts using the logon, startup etc in gpo and calling the kix32 from there.

Howard Bullock

 Quote:
I store Kix32.exe, crc32.exe, and 70+KB of script code on the client that is executed globally by 35,000 clients daily. I much prefer the added functionality in Kix32 and with it staged locally, I have no issues that site.

If you want to see my batch file for launching this it is here: LOGON.BAT (the overkill version)

if Kix32.exe or the scripts are altered or otherwise corrupted they will be replaced because they will fail a CRC32 check. If I add updated code on the DC again the locaaly cached files fail the CRC and will be updated.

You must not be doing very much with your code if you are elated with 3.21.
_________________________
Home page: http://www.kixhelp.com/hb/


Maybe I should look into doing this. I am finding that with some netbooks that we have, the login script takes ages to run and this might help speed it up. I never considered copying all the scripts plus kix32.exe to each local machine as the scripts and kix executable are not large by today's standards, but seeing two people in this thread mention copying the executable to the local machines, I am wondering if this is commonly done.

Does everyone else tokenise their scripts and then copy the tokenised scripts and kix32 exe to each local machine to run from there?

I am happy to lend anyone a pair of my gloves that I used to dig up this decade old thread! Its interesting what you find browsing through the website. This thread still has relevance today even with our gigabyte speed networks!


Edited by Lonkero (2014-01-14 04:32 AM)
Edit Reason: the original thread was last replied to10 years ago and not deeply enough related to warrant unburying the dead. http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=128905&fpart=1

Top
#208270 - 2014-01-07 09:14 PM Re: Kix32.exe is too large, I use an old version. [Re: Robdutoit]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4305
Loc: New Jersey
There are a couple of considerations here.

I tokenize many of my scripts, mostly to prevent unauthorized modification. Any script that we support commercially is tokenized. The performance difference of tokenized/plain text in most situations is negligible. You might see worthwhile improvement of tokenized scripts over low-performance WAN and dialup links, although these are becoming increasingly rare nowadays.

With KGen's BAT reformat capability, I also use the .BAT extension for many Kix scripts that are NOT tokenized, allowing me to distribute the Kix script and a copy of Kix - they both run from the same folder without any prep. .BAT is a normal extension to execute from the command line, so this form allows me to avoid having to register any extensions.

I do install Kix32 locally, but only on Servers and Admin workstations, where we rely on many of our administrative scripts to be available - Wus/WusSvc, tsAdm, LogMaint, Cleanup, and several other diagnostic and administrative tools.

As for installing Kix32 and scripts on every workstation, this quickly becomes unmanageable as Kix and the scripts are updated. Many of the sites I support have >5000 workstations and as many as 30,000. Managing the updates on all those compared to Kix32 and the login scripts on the NetLogon share is a no-brainer in favor of a single (replicated) location. The one partial exception to this is our Universal Login Script, which caches the INI file on the local computer. We found that repeated queries to the INI file over the LAN or WAN impacted performance. With the INI file local, it was cached in memory and was very fast. The script does have some overhead in determining if the local copy is current and consistent with the Netlogon version, but again, negligible.

Glenn

PS - Grave robbing is right! I think that 10 years is the record for necro'ing a thread! \:\)
_________________________
Actually I am a Rocket Scientist! \:D

Top
#208291 - 2014-01-12 01:48 PM Re: Kix32.exe is too large, I use an old version. [Re: Glenn Barnas]
Robdutoit Offline
Hey THIS is FUN
***

Registered: 2012-03-27
Posts: 310
Loc: London, England
I will have to think about this. My networks are small. Less than 100 computers at each network. Having looked at the issue further, I don't think the problem is the network as in copying over. I believe that the main slowdown is 1: deleting temp files on login and 2: installing Firefox profile updates and things like that on login.

What I am going to do first is change the setup so that temp files are deleted on logoff and I need to find a script that will allow me to calculate how long each line of code is taking to run.

I am going to be looking at buying impero software that will allow me to update flash player, firefox, java as well as all windows updates and this will eliminate the problems of updating firefox, although it won't fix this specific issue as the firefox profile needs to be updated on login as the profile is user specific.

It was just interesting that several people in this thread mentioned copying the kix scripts across. I might do this as I don't update the script more than once a month I would guess, and I certainly don't update the kix executable more than once every two years. But I am assuming that if the kixtart script is running and the running of the script is taking a while on the netbooks, then its the actual script that needs to be optimised and not copying the kix files across as obviously the script has already been "copied" across.

Thanks

Top
#208297 - 2014-01-13 09:25 AM Re: Kix32.exe is too large, I use an old version. [Re: Robdutoit]
Mart Moderator Offline
KiX Supporter
*****

Registered: 2002-03-27
Posts: 4646
Loc: The Netherlands
 Originally Posted By: Robdutoit

....
I need to find a script that will allow me to calculate how long each line of code is taking to run.
....


Something to get you going. It requires the TimeDiff() UDF.

 Code:
Break on

$start = @DATE + " " + @TIME
;Your code goes here
Sleep 6
$end = @DATE + " " + @TIME
?"Runtime = " + TimeDiff($start, $end, 'm', "1") + " minutes."

Sleep 5
_________________________
Mart

- Chuck Norris once sold ebay to ebay on ebay.

Top
#208307 - 2014-01-13 07:32 PM Re: Kix32.exe is too large, I use an old version. [Re: Mart]
Robdutoit Offline
Hey THIS is FUN
***

Registered: 2012-03-27
Posts: 310
Loc: London, England
I will have a look at that as well, although Glenn has kindly pointed out some code that I can use. Heaven knows when I will get around to testing it. When it rain it pours - and I am not talking about the weather at the moment, although it is chucking water down outside in England.
Top
#208308 - 2014-01-13 07:59 PM Re: Kix32.exe is too large, I use an old version. [Re: Robdutoit]
Glenn Barnas Administrator Offline
KiX Supporter
*****

Registered: 2003-01-28
Posts: 4305
Loc: New Jersey
Actually, the code I referenced is appropriate to log the time when a particular event in the script starts and/or finishes. Usually, it's assumed that a timestamp shows the completion of an event, the start time being the completion of the prior event. Of course, you can log the start and end if you want, particularly if you are logging specific function blocks and not every step along the way.

The TimeDiff that Mart pointed you to returns the difference between two timestamps, with ms accurracy. I would not use that for performance logging as there is much more overhead compared to the TimeStamp() UDF. It would be perfect, however, to use to determine precise differences between each of the values written to the perf log, probably by an analysis tool that read the perf log starting at line 2 and compared the time value with the prior line's time value. Something like
 Code:
$aPerfData = FileIO('.\perflog.log', 'R')
For $P = 1 to UBound($aPerfData)
  $Time1 = Left($aPerfData[$P - 1], 23)  ; prior value
  $Time2 = Left($aPerfData[$P], 23)      ; current value
  $Diff = TimeDiff($Time1, $Time2, , 1)  ; difference w/ MS 
  $aPerfData[$P] = $aPerfData[$P] + ' - ' + $Diff + ' Seconds.'
Next
$ = FileIO('.\perflog.log', 'W', $aPerfData)
This will calculate the difference between entries and write the different back to the file.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D

Top
Page 1 of 1 1


Moderator:  Lonkero, ShaneEP, Jochen, Radimus, Glenn Barnas, Allen, Mart 
Hop to:
Shout Box

Who's Online
0 registered and 152 anonymous users online.
Newest Members
Jagcats, Dramamu, Tamperold, RrrDdd, Stefan_H
17676 Registered Users

Generated in 0.033 seconds in which 0.011 seconds were spent on a total of 13 queries. Zlib compression enabled.

Search the board with:
superb Board Search
or try with google:
Google
Web kixtart.org