defaria.com/blogs/Status/archives/2006_12.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" id="sixapart-standard">
   4 <head>
   5    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6    <meta name="generator" content="Movable Type 5.2.3" />
   7
   8    <link rel="stylesheet" href="http://defaria.com/blogs/Status/styles-site.css" type="text/css" />
   9    <link rel="alternate" type="application/atom+xml" title="Atom" href="http://defaria.com/blogs/Status/atom.xml" />
  10    <link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="http://defaria.com/blogs/Status/index.xml"$>" />
  11
  12    <title>Status for Andrew DeFaria: December 2006 Archives</title>
  13
  14    <link rel="start" href="http://defaria.com/blogs/Status/" title="Home" />
  15    <link rel="prev" href="http://defaria.com/blogs/Status/archives/2006_11.html" title="November 2006" />
  16    <link rel="next" href="http://defaria.com/blogs/Status/archives/2007_01.html" title="January 2007" />
  17 </head>
  18 <body class="layout-one-column">
  19    <div id="container">
  20       <div id="container-inner" class="pkg">
  21
  22          <div id="banner">
  23             <div id="banner-inner" class="pkg">
  24                <h1 id="banner-header"><a href="http://defaria.com/blogs/Status/" accesskey="1">Status for Andrew DeFaria</a></h1>
  25                <h2 id="banner-description">Searchable status reports and work log</h2>
  26             </div>
  27          </div>
  28
  29          <div id="pagebody">
  30             <div id="pagebody-inner" class="pkg">
  31                <div id="alpha">
  32                   <div id="alpha-inner" class="pkg">
  33
  34                      <p class="content-nav">
  35                         <a href="http://defaria.com/blogs/Status/archives/2006_11.html">&laquo; November 2006</a> |
  36                         <a href="http://defaria.com/blogs/Status/">Main</a>
  37                         | <a href="http://defaria.com/blogs/Status/archives/2007_01.html">January 2007 &raquo;</a>
  38                      </p>
  39
  40
  41
  42
  43                      <h2 class="date-header">December 28, 2006</h2>
  44                      <a id="a000604"></a>
  45                      <div class="entry" id="entry-604">
  46                         <h3 class="entry-header">Mkcc.pm and mkvob</h3>
  47                         <div class="entry-content">
  48                            <div class="entry-body">
  49                               <ul>
  50   <li>Pulled out common code from mkview that will be needed for mkvob into Mkcc.pm Perl module</li>
  51
  52   <li>Re-engineered mkview to use Mkcc.pm</li>
  53
  54   <li>Started recoding mkvob to use GPDB and the new Mkcc.pm</li>
  55
  56   <li>Code complete on mkvob - need to test</li>
  57
  58   <li><b>Issue</b>: It seems that we have multiple versions of mkview_linked and that UK has continued development of their version of mkview_linked while we've been developing on mkview_linked here in Dallas. IOW there are two versions in separate vobs!</li>
  59 </ul>
  60
  61                               <h3>The old mkvob_db</h3>
  62
  63 <p>There are some oddities in the old mkvob_db code. For example, there is an insistence in setting umask to 0 before creating directories, which are created with specific permissions. Setting umask is only for the new creation of a directory or file. One could, instead, simply make the directory then chmod it to whatever you really wanted the permissions to be. The new subroutine MakeDir in Mkcc.pm does just that, as well as chown if owner and group are passed in as well as only making the directory if it is needed. This simplifies the code a lot and removes the need to save, set and restore umask.</p>
  64
  65 <p>Another oddity of the old code can be seen in the following:</p>
  66
  67 <div class=code><pre>
  68 foreach $rgn (@regionList) {
  69   $debug && print "DEBUG: Checking tag in $rgn\n";
  70
  71   $cmd = 'lsvob -s -region $rgn';
  72
  73   @output = ctcmd($cmd);
  74
  75   foreach $item (@output)
  76   {
  77     if ($item =~ /^$tag$/)
  78       {
  79         print "VOB tag $tag already exists in $rgn\n\n";
  80         exit (1);
  81       }
  82   }
  83 }
  84 </pre></div>
  85
  86 <p>Looks innocuous enough - run through a list of regions looking to see if this newly requested vob tag already exists in any of the regions. However there are bugs and inefficiencies in the above code. For starters the single quote on the setting of $cmd says to <b>not</b> expand the variable $rgn. The resulting command then becomes "cleartool lsvob -s region $rgn" which, of course, would return an error, which, of course, is not checked for here. So the code, while trying to verify that this vob tag does not exist in any of the regions, fails to actually check it!</p>
  87
  88 <p>However if we just correct that by using double quotes we will now incur a performance penalty. Now the registry server will be required to return all the vob tags for each and every region which can take some time. Is there any way we can make this faster? Why yes there is! Specify the actual vob tag (as in cleartool lsvob -s -region &lt;region name&gt; &lt;vob tag&gt;)! You know sometimes people say that Clearcase always returns all of the registry data which is then parsed locally. Then again, sometimes it's the programmer who asks for it!</p>
  89
  90 <p>So the new code looks like:</p>
  91
  92 <div class=code><pre>
  93 foreach (@regionList) {
  94   debug "Checking for $tag in region $_";
  95
  96   @output = ctcmd "lsvob -s -region $_ $tag";
  97
  98   error "VOB tag $tag already exists in region $_", 1 if !grep /Error/, @output;
  99 } # foreach
 100 </pre></div>
 101
 102 <p>Note the simplifications for debug (now a subroutine from Mkcc.pm), usage of the default variable ($_) and error reporting (also a subroutine from Mkcc.pm). This algorithm performs the same task, correctly and orders of magnitude quicker.
 103
 104                               <p class="entry-footer">
 105                                  <span class="post-footers">Posted by  at  4:50 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000604.html">Permalink</a>
 106
 107
 108                               </p>
 109                            </div>
 110                         </div>
 111                      </div>
 112
 113
 114
 115                      <h2 class="date-header">December 27, 2006</h2>
 116                      <a id="a000603"></a>
 117                      <div class="entry" id="entry-603">
 118                         <h3 class="entry-header">Reworking GPDB tables, mkview</h3>
 119                         <div class="entry-content">
 120                            <div class="entry-body">
 121                               <ul>
 122   <li>Finished gpdb_add_project.pl with new table layout</li>
 123
 124   <li>With gpdb_getProjectsAtSite I can now return to mkview. Implemented new paging usage listing projects at the site</li>
 125
 126   <li>Finished coding of mkview such that it is now functional with GPDB and can make views</li>
 127 </ul>
 128
 129                               <p class="entry-footer">
 130                                  <span class="post-footers">Posted by  at  4:46 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000603.html">Permalink</a>
 131
 132
 133                               </p>
 134                            </div>
 135                         </div>
 136                      </div>
 137
 138
 139
 140                      <h2 class="date-header">December 19, 2006</h2>
 141                      <a id="a000602"></a>
 142                      <div class="entry" id="entry-602">
 143                         <h3 class="entry-header">GPDB Database performance</h3>
 144                         <div class="entry-content">
 145                            <div class="entry-body">
 146                               <ul>
 147   <li>Moved convertdb and gpdb_add_vob into Clearcase</li>
 148
 149   <li>Attempting to standardize which Perl to use, which Oracle.pm to pickup and how to insure that other sites have the proper prerequisites for GPDB</li>
 150
 151   <li>Discovered that Oracle is not supported on Linux here at TI. This will be a problem for GPDB</li>
 152
 153   <li>Still working on issues of the new GPDB design and attempting to get gpdb_add_project.pl to work with it</li>
 154
 155   <li>Got definition of performance problem that Donna is experiencing. She is attempting to populate a pull down with just the project names for a site. Doing so causes lots of transfer of data as the current GPDB API gpdb_getProject effectively transfers all kinds of project information where Donna needs only the project names.</li>
 156
 157   <li>Developed a new API, gpdb_getProjectsAtSite that returns only the project names in a more efficient manner</li>
 158 </ul>
 159
 160                               <h3>gpdb_getProjectsAtSite</h3>
 161
 162 <p>Donna may be right and we may need to enlist the help of Ajay here.</p>
 163
 164 <p>I coded up a gpdb_getProjectsAtSite function:</p>
 165
 166 <div class=code><pre>
 167 sub gpdb_getProjectsAtSite ($$) {
 168   my ($site_name, $resource) = @_;
 169
 170   resetErr ();
 171
 172   unless (lc $resource eq "clearcase" or
 173           lc $resource eq "designsync") {
 174     setError (-1, "gpdb_getProjectsAtSite: Resource must be one of 'clearcase' or 'designsync'");
 175     return ();
 176   } # unless
 177
 178   my $siteID    = siteID $site_name;
 179   my $condition    = "site_id = $siteID and $resource = 'Y'";
 180
 181   my @projects = @{GPDB::primitive::searchData ("projects", $condition)};
 182   my @project_names;
 183
 184   foreach (@projects) {
 185     my %project    = %{$_};
 186     my $name    = projectName $project {PARENT_PROJ_ID};
 187
 188     next if !$name;
 189
 190     push @project_names, $name;
 191   } # foreach
 192
 193   return @project_names;
 194 } # gpdb_getProjectsAtSite
 195 </pre></div>
 196
 197 <p>Basically you call it with a site name and a resource (being clearcase or designsync). It does some housekeeping (resetting the error variables and checking that resource is one of clearcase or designsync). Next it translates the site name to an ID. We need an ID
 198 and we shouldn't burden the users with having to supply that. The siteID function is a new internal function for gpdb.pm because I often find the need to translate a site name to an ID. Next we compose a condition which is the part after "where" that says find things that have "site_id = $siteID and $resource = 'Y'". Remember resource is either "clearcase" or "designsync" and we wish to find project records where the site matches and the resource is toggled on (i.e. = 'Y').</p>
 199
 200 <p>There's a new primitive, searchData because getData only finds single records by "ID" only and findData will return multiple records based on a fieldname = value specific condition. Here we want two different fieldname/value pairs and an "and" condition. Therefore the searchData primitive takes two parameters, the table name and the condition, and composes a "select * from $tableName where $condition" and returns an array of hashes like findData does.</p>
 201
 202 <p>At this point we have an array of projects whose site IDs match our passed in Site Name and whose $resource is toggled on as 'Y'. But we want to return project names to be nice for the user and that's what the foreach loop does. Note it calls another new internal routine called projectName which returns the project's name for the product ID (the parent project ID that is). Note also that projectName will return undef if the project is retired. That's what the "next if !$name" statement is for. All non-retired project names therefore are pushed onto @project_names which are returned from the subroutine.</p>
 203
 204 <p>I do not see how I could make this any faster.</p>
 205
 206 <p>Well how did it perform? Selecting on Dallas and Clearcase projects (because gpdb_add_project.pl that does DesignSync additions is still not working well) there are 194 Clearcase projects at the Dallas site. Running a small test script here and at Manchester yields:</p>
 207
 208 <div class=code><pre>
 209 <b>Dallas:</b><u>time testproj_names.pl</u>
 210 real    0m7.156s
 211 user    0m1.260s
 212 sys     0m0.310s
 213
 214 <b>Manchester:</b><u>time testproj_names.pl</u>
 215 real    0m23.708s
 216 user    0m0.490s
 217 sys     0m0.170s
 218 </pre></div>
 219
 220 <p>That's 24 seconds from Manchester or roughly 3.5 times as slow.</p>
 221
 222 <p>Switching over to selecting designsync records, there are 9 of them at Dallas. Timings for this are:</p>
 223
 224 <div class=code><pre>
 225 <b>Dallas:</b><u>time testproj_names.pl</u>
 226 real    0m1.402s
 227 user    0m0.810s
 228 sys     0m0.120s
 229
 230 <b>Manchester:</b><u>time testproj_names.pl</u>
 231 real    0m3.646s
 232 user    0m0.300s
 233 sys     0m0.080s
 234 </pre></div>
 235
 236 <p>Again in the order of 3 times as slow</p>
 237
 238                               <p class="entry-footer">
 239                                  <span class="post-footers">Posted by  at  5:32 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000602.html">Permalink</a>
 240
 241
 242                               </p>
 243                            </div>
 244                         </div>
 245                      </div>
 246
 247
 248
 249                      <h2 class="date-header">December 14, 2006</h2>
 250                      <a id="a000601"></a>
 251                      <div class="entry" id="entry-601">
 252                         <h3 class="entry-header">Users/Sites and Projects</h3>
 253                         <div class="entry-content">
 254                            <div class="entry-body">
 255                               <ul>
 256   <li>Implemented schema changes for GPDB based on previous meetings</li>
 257
 258   <li>Dropped PDB_ from table names to make them shorter and more understandable</li>
 259
 260   <li>Created all new tables and mapping tables. Adjusted sequencing</li>
 261
 262   <li>Changed users table to use AXID for key. Associated changes to other tables</li>
 263
 264   <li>Added synonyms where required</li>
 265
 266   <li>Updated drop_all.sql to reflected all new tables, views and sequences</li>
 267
 268   <li>Reorienting gpdb.pm for new database layout</li>
 269
 270   <li>Initially dropped the projects_by_site view as the new data structures handle this in a different way. Later added the view back this time gathering information from 3 different tables.</li>
 271
 272   <li>Got convertdb to be able to add users, sites and projects.</li>
 273
 274   <li>Got gpdb_add_vobs.pl working again in new structure</li>
 275
 276   <li>Started getting web pages to reveal data in new structures</li>
 277
 278   <li>Working on gpdb_add_project.pl to accommodate new schema layout</li>
 279
 280   <li>Changed gpdb_add_project.pl to use sites table instead of a sites file</li>
 281
 282   <li>Changed -s parm for gpdb_add_project.pl to instead specify a site to process - default being all sites</li>
 283 </ul>
 284
 285                               <p class="entry-footer">
 286                                  <span class="post-footers">Posted by  at  3:48 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000601.html">Permalink</a>
 287
 288
 289                               </p>
 290                            </div>
 291                         </div>
 292                      </div>
 293
 294
 295
 296                      <h2 class="date-header">December  1, 2006</h2>
 297                      <a id="a000600"></a>
 298                      <div class="entry" id="entry-600">
 299                         <h3 class="entry-header">GPDB Bug Fixed</h3>
 300                         <div class="entry-content">
 301                            <div class="entry-body">
 302                               <ul>
 303   <li>Fixed bug in domain_ranges.sql script</li>
 304
 305   <li>Finished Create site</li>
 306
 307   <li>Added replica_name field</li>
 308
 309   <li>Fixed naming error with snapto_dir and owning_group</li>
 310
 311   <li>Expanded size of snap_notify to 1024 bytes</li>
 312 </ul>
 313
 314                               <p class="entry-footer">
 315                                  <span class="post-footers">Posted by  at 11:21 AM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000600.html">Permalink</a>
 316
 317
 318                               </p>
 319                            </div>
 320                         </div>
 321                      </div>
 322
 323                   </div>
 324                </div>
 325             </div>
 326          </div>
 327       </div>
 328    </div>
 329 </body>
 330 </html>