[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]
==== REVPARAM Questions un-answered (OpenInsight 32-bit Specific) ====
=== At 20 AUG 2009 08:15:07AM Martin Drenovac wrote: ===
{{tag>"OpenInsight 32-bit Specific"}}
I've previously asked about the reference to the REVPARAM file in http://www.revelation.com/o4wtrs/oecgi3.exe/O4W_DOMINO_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&KEY=0A51C5E55C79C9B1852573CB0053F472&KEY1=0A51C5E55C79C9B1852573CB0053F472 - and Kevin had indicated that the developers would give some info.
I have also checked the SENL Nov '08 article where they describe a revparam issue - however, both articles don't quite answer my problem.
Question is: Is the revparam file only searched for on every OPEN or on every Read / Write.
We have a case of where we've got 60 concurrent users - hammering the server with 20K SMB searches for REVPARAM, and immediately thereafter speaking to the LH Service - which in turn returns 120Bytes of data. So we've got 3000bytes overhead to read 100 bytes.
If someone wants the wireshark logs - happy to provide them.
Can someone from REV please drop me a line as to the use of REVPARAM.
Is it OPEN only - or every access to a file?
Is it really true that if you have 1 REVPARAM at the top of the tree of your dir structure that it won't go searching for the REVPARAM even if your data is a further 2 levels down?
Network 3.x at the moment, moving to 4.6 as soon as we get these answered.
Thank you greatly
----
=== At 20 AUG 2009 11:34AM Jared Bratu wrote: ===
[i]"Is it really true that if you have 1 REVPARAM at the top of the tree of your dir structure..."[/i]
Not exactly, It works from the bottom up to the top, not top to bottom.
[i]"Is it OPEN only - or every access to a file?"[/i]
It depends. See below...
Each time attach_table is called the directory tree is searched for a REVPARAM file.
On the [u]first OPEN[/u] statement for a specific table the directory tree is searched for a REVPARAM file.
The system DOES NOT search for each read/write.
In the examples below [b]bold lines[/b] indicate a REVPARAM search took place.
Lets say a REVPARAM file exists in DataVol in following pseudocode:
[b]Attach_Table \DataVol\A\B\C\D[/b]
[b]Open D_TABLE1 to D_HND[/b]
Write Rec On D_HND, KEY1
Write Rec On D_HND, KEY2
Write Rec On D_HND, KEY3
The search would look for a REVPARAM in the following directories in the order shown:
1. \DataVol\A\B\C\D
2. \DataVol\A\B\C
3. \DataVol\A\B
4. \DataVol\A
5. \DataVol (SUCCESS)
In the example above two separate searches are performed for the REVPARAM file.
Now, this is where it gets interesting. Using the same directory tree consider this pseudo code:
[b]Attach_Table \DataVol\A\B\C\D[/b]
[b]Open D_TABLE1 to D_HND[/b]
Write Rec On D_HND, KEY1
Write Rec On D_HND, KEY2
Write Rec On D_HND, KEY3
...Later in the same session in another subroutine...
Open D_TABLE1 to D_HND
Write Rec On D_HND, KEY1
Only two searches are performed. The second time OPEN is called for D_TABLE1 no search for the REVPARAM is needed. Subsequent OPEN statements from separate routines to the same table in the same instance of OpenInsight do not require a search for the REVPARAM.
There is a catch, calling Attach_Table will reset the OPEN statement REVPARAM cache demonstrated above. Take the following pseudocode:
[b]Attach_Table \DataVol\A\B\C\D[/b]
[b]Open D_TABLE1 to D_HND[/b]
Write Rec On D_HND, KEY1
Write Rec On D_HND, KEY2
Write Rec On D_HND, KEY3
...Later in the same session in another subroutine...
[b]Attach_Table ANOTHERVOL[/b]
[b]Open D_TABLE1 to D_HND[/b]
Write Rec On D_HND, KEY1
Four separate searches are performed. Even though "\DataVol\A\B\C\D" is already attached and D_TABLE1 is already open. Simply calling Attach_Table, to any volume, can affect all subsequent OPEN statements.
[u]Conclusion:[/u]
-Using Attach_Table always searches for a REVPARAM file.
-Attach_Table will cause any table that was already opened to re-search for a REVPARAM file. This only happens the first time the table is accessed after an attach_table command.
-Subsequent OPEN statements to a table that was already opened will not result in a REVPARAM search (unless attach_table is called - see above)
-Keeping a REVPARAM file in the data volume will reduce the number of directories the client searches.
----
=== At 20 AUG 2009 04:55PM Martin Drenovac wrote: ===
Thank you Jared...we'll go and implement your recommendations re revparam placement.
----
=== At 26 AUG 2009 08:45PM Barry Stevens wrote: ===
]]
Q. "Is it really true that if you have 1 REVPARAM at the top of the tree of your dir structure..."
A. Not exactly, It works from the bottom up to the top, not top to bottom.
<<
Are you sure your response is correct, or, is it related to OI/Service versions, as I sure I have seen something that says if you have just 1 revparam in your Oinsight main folder, it will be quicker.
Is it OInsight or lh_service that looks for revparam.
----
=== At 26 AUG 2009 08:59PM Barry Stevens wrote: ===
]]
Q. "Is it really true that if you have 1 REVPARAM at the top of the tree of your dir structure..."
A. Not exactly, It works from the bottom up to the top, not top to bottom.
<<
Are you sure your response is correct, or, is it related to OI/Service versions, as I am sure I have seen something that says if you have just 1 revparam in your Oinsight main folder, it will be quicker.
Is it OInsight or lh_service or Driver that looks for revparam.
If single revparam is only valid from a single version, then what version of what.
----
=== At 26 AUG 2009 09:04PM Barry Stevens wrote: ===
From the UD 3.0 manual.
*************************************************************
What else is different from the previous Network Products?
There is only one REVPARAM file no matter how many different subdirectories you have with .LK and .OV files.
*************************************************************
This is a benefit!
----
=== At 27 AUG 2009 08:12AM Jared Bratu wrote: ===
Yes, this is still true in all versions of the UD 3.0 and later.
----
=== At 27 AUG 2009 08:29AM Jared Bratu wrote: ===
The Universal Driver on the client workstation is responsible for finding the REVPARAM file. The file is a simple configuration to tell the client how to talk to the server's linear hash service (universal driver service)
To confirm what you quoted from the documentation in a different message, only 1 REVPARAM file is required. This is true as long as all clients can see the file at some point in the network path.
What was in question is HOW it searched for the REVPARAM file. In Martin's case his network diagnostics showed a lot of excess network traffic by his clients looking for the REVPARAM.
Placing the REVPARAM closer to the data files and calling attach_table less will help reduce the number of times each client must search for the file.
----
=== At 27 AUG 2009 07:03PM Barry Stevens wrote: ===
OK, cool
----
=== At 27 AUG 2009 07:03PM Barry Stevens wrote: ===
Thanks
----
=== At 30 AUG 2009 05:51PM Dan Reese wrote: ===
Whoa!
It is true as long as all linear hash files are in the same directory tree. The search goes up the directory structure until it either finds a revparam file or it hits the root of the drive.
The installation manual says you only need 1 revparam file, but that assumes all data files are under the OI directory. If OI is on one drive letter and your data is on another, you need a revparam file for each drive (i.e., at the top of each tree).
----
=== At 31 AUG 2009 01:22AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote: ===
See Page 8 of SENL Vol 5 Issue 1 :)
http://www.sprezzatura.com/library/senl/senl-v5i1.pdf
[url=http://www.sprezzatura.com]The Sprezzatura Group[/url]
[url=http://www.sprezzatura.com/blog]The Sprezzatura Blog[/url]
[i]World leaders in all things RevSoft[/i]
[img]http://www.sprezzatura.com/zz.gif[/img]
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=7951103ADC6AC4B38525761800434D5C|View this thread on the forum...]]