Video Screencast Help
Endpoint Management Community Blog
Showing posts tagged with Reporting
Showing posts in English
Ludovic Ferre | 12 Jan 2010 | 0 comments

Being back to work I had the opportunity to check how aila does behave on real production systems yesterday morning.

And to do so I had to make a few adjustments that took us to tag v0.3.0_Rev163:

  • When aila is executed the following options are now defaults:
    • '-0, --zero'
    • '-pc, --progress-counter'
    • '-dc, --dump-cache'
  • As such the related command line options names have changed:
    • '-0, --zero' is now '-n0, --no-zero'
    • '-pc, --progress-counter' is now '-npc, --no-progress'
    • '-dc, --dump-cache' is now '-ndc, --no-dump-cache'
  • Corrected a problem for very long log entries (over 1024 bytes) by setting the line read buffer to 2048 and updating the cs_uri_query handling section.
  • ...
yogeshsadhu | 06 Jan 2010 | 0 comments

Good news for you all!

GSS 2.5.1 is now avaliable for Live Update !

This update supports for two new operating systems Win7 and 2k8 R2.

In addition to Live update 5 , this release is also made available as media ship.

Go ahead and do the Live update for new Ghost Solution.

Please share your experience with win7 and 2k8 R2 imaigng.

The product version will be 11.5.1.2266.

 

Ludovic Ferre | 06 Jan 2010 | 0 comments

Free time for coding will soon become scarce again, as my winter holidays are almost over.

So what is it that I still haven't put in aila [1] and that I would like to put in. Looking back should we change anything to the existing code?

Looking forward first: I have started to work on a feature to keep all parsed data (summary and detailed structures) in-memory. The idea is to run the parse process and drop to a command line prompt for interactive operations such as searching entries with a given ip address, a given package guid or a given computer guid. This feature was thought a while back and put in the wish list only to be dropped soon after. But given we have done almost everything though in the first place, I am interested in this coding challenge and I do believe the feature could really help troubleshooting or base lining
operations. 

Looking back: I need to do some work to ensure aila is schema agnostic, i.e. the parse starts and aila...

Ludovic Ferre | 04 Jan 2010 | 0 comments

Time flies by, the New Year is almost an old thing already, and most definitely is aila-0.2.3.

So tonight we have a lot of changes, let's go with the big header tags:

Head Revision 131 was tagged as v0.2.5-Rev131

This is from the main line of code, which is written on Linux systems (32-bit and 64-bit). This is the trunk of the subversion tree. The changes from v0.2.3 are numerous and detailed in the attached diff, but here's a brief highlight:

  • Implemented http to ascii conversion (%22 %20 %97 now display " { } < > etc when you use the --csv-format command line)
  • Added html file type accounting
  • Corrected issue with the asp / aspx file type accounting
  • Added GetLicense.aspx to the accounted Altiris Agent interfaces
  • Added checks to not add invalid ip addresses in the string cache
  • Added context search to find guid types (so we differentiate entries if they are package or computer guids)
  • ...
Ludovic Ferre | 31 Dec 2009 | 0 comments

It'll be soon time to look back upon 2009, and look forward to 2010.

But right now we'll look back at our post v0.2.0 tag [1], and forward to the next tag of course.

What did we mean to put in this tag, and what really made it? Below where the plans drafted in [1]:

  1. [n+] A Simple Linked List implementation (dynamic array)
  2. [n+] IP Address search in the IIS log files
  3. [++] Contextual data for guid and ip searches
  4. [n+] A Win32 branch to ensure code portability
  5. [++] Use of the link list to store all data in memory
  6. [++] Creation of a shell to query in memory data

1. The simple link list was implemented and discarded, as too costly in term of performance (given the file parse is raw in-memory processing taking 100% of a core for the duration of the process). It took the processing time from a fixed 30 seconds to a variable one between 60~100 seconds! Gasp.

2. IP address search was...

Ludovic Ferre | 30 Dec 2009 | 0 comments

In my previous blog post (here) and self-reply I was searching for a solution to the negative impact on performance a large cache had.

It included some really wacky ideas (the front and rear indexing for example) and some better one (storing ip's in their original form i.e. 32-bit unsigned integers). I spent much time thinking about the best possible indexing (considering tree implementations, sorted list, as well as block memory allocation to limit the hits on mallocs) and after a walk this morning (I went to the weekly street market refill my fresh basket) I thought that performance was prime, thus I decided to revert the cache store to the basic array used originally.

With that decided I knew I would gain some performance over the linked list implementation, but I wanted to gain from the...

Ludovic Ferre | 29 Dec 2009 | 1 comment

Argh... with most feature comes a cost, and the great benefits from the string cache (which does a huge simplification, storing data from hundred of thousand of lines into 7~16,000 entries between 0 and 36 bytes long) comes a huge performance hit as it is right now (illustrated below).

Illustration 1: Simple linked list implementation currently in use.
simple_list2.png

Working with the string cache to store guids and hit counts for them we saw some interesting statistics whilst there was only a minor performance cost with up to 7,600 cached entries.

But as I added the Client IP Addresses (c_ip) yesterday the string cache doubled in size reaching upward of 16,000 entries. Knowing that the string cache is implemented with a simple list (which is a bad circular list implementation that acts much like a stack form which we never pop) we have hit the limit...

Ludovic Ferre | 27 Dec 2009 | 0 comments

As we did right after the previous tag (0.1.8) [1] it is time to take a break from coding to look back upon what we achieved and look ahead for what remains to be done before the next tag can be created.

Looking back

The following objectives were decided (in two stages - the post and a self reply):

  1. Naming of the resulting program (generally v0xx)
  2. Naming of the main source file (currently prog.c)
  3. Externalization to purpose driven c files for major functions
  4. Implement a make file to handle the above changes?
  5. Logging out-source to a log_event function and handler
  6. Clean up code from global variables when possible
  7. Document the code and interfaces used as well as the flow
  8. Add a string cache

Steps 1-3 were completed easily. Step 4 is not yet required, as I have a compilation shell script in place. Note that the script is under source control and uses gcc with the -Wall so that...

Ludovic Ferre | 25 Dec 2009 | 0 comments

Santa was busy last night but did not forget the CWoC folks on Connect. So under the tree this morning I found commit 67 [1] which was good enough to be tagged, as version 0.2.0 [2].

Has stated in a previous post [3] it contains a new feature in the form of a string cache. Without going into too much of the code itself we can say the following of the cache and it's current implementation and use (versus other implementation options and usages):

  • The string cache is currently a static array, set to hold a maximum of 8192 string cache entries.
  • The string cache entries are based on a struct defined as shown here:
    struct string_cache_entry...
Ludovic Ferre | 20 Dec 2009 | 1 comment

With 0.1.8 out the door and 0.1.9 coming on I thought it could be nice to actually plan for the features and improvements I'd like to see in the next tag (not necessarily 0.1.9).

Here's a brief overview of the required changes, with detailed explanations below (bear with me reader, as this is a work in progress):

  1. Naming of the resulting program (generally v0xx)
  2. Naming of the main source file (currently prog.c)
  3. Externalisation to purpose driven c files for major functions
  4. Implement a make file to handle the above changes?
  5. Logging out-source to a log_event function and handler
  6. Clean up code from global variables when possible
  7. Document the code and interfaces used as well as the flow

Here are some of the details for each point with pro and cons where applicable:

1. Naming of the resulting program (generally v0xx)

This is decided already, albeit it may not be the nicest name I...