Sporadic performance in arev after upgrading from 2.1 to UD 4.5 (Networking Products) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[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]]


==== Sporadic performance in arev after upgrading from 2.1 to UD 4.5 (Networking Products) ====
=== At 18 AUG 2008 05:24:59PM dave w bennett wrote: ===
 
{{tag>"Networking Products"}}
 
<QUOTE>
We had the 2.1 driver and had good results, now with the UD 4.5 driver our IO to the server is improved and sometimes when it's 40 times slower. We have a speed monitor on one of the automatic users logins for years which tests how long it takes to read next 1000 records and write each one 10 times and this test is very sporadic and a great indicator of what the users are experiencing.

What should we look at?
</QUOTE>
----

=== At 21 AUG 2008 09:33AM Bob Carten wrote:  ===

<QUOTE>

Dave:



Standard care and feeding of UD:



- Ensure SYSTEM user has full rights

- Use TCPIP

- Specify servername and port in the revparam

- I prefer to specify sharename too

- If all directories are under OI, use a single revparam in OI, remove revparam from subdirectories

- If data direcories are elsewhere, use another revparam to control them





Things to keep in mind ( or more than you ever wanted to know  )



It is lhClient.dll which reads the revparam, not the lhservice, so revparam must be visible under client users rights.

The client dll will search for a revparam till it finds one.  The search proceeds by going up the subdirectory tree.  The UD client wants to find a revparam, even if that revparam only says ServerOnly=0.  In general, the LHClient makes an educated guess using hints from the revparam about how to access the .lk and .ov files.  I suspect this logic is a source of some slowdowns; I like to fully specify servername, tcpip port and sharename to avoid that logic.





 .LK and .OV files are read by the service, not the client, so they need to be available to SYSTEM user.  Clients do not need any rights to .OV or .LK files.  I like to put a 'placeholder' subdirectory under oi with a revparam containing a sharename directive, then have all the data subdirectories elsewhere.



An example of fully specified revparam, separation of client and server roles:



Given a windows 2003 server with a C and D drive, apps on C, data on D where 



c:\revsoft\oinsight  is OI directory



and data is in mutiple subdirectories like



d:\revdata 

d:\revdata\customers

d:\revdata\inventory

d:\revdata\sales





\\myserver\apps\revsoft\oi has a revparam with

serveronly=1

servername=MyServer

TcpIpPort=12345

NamedPipeName=None

ShareName=OIAPP



\\myserver\apps\revsoft\oi\appdata has a revparam with

serveronly=1

servername=MyServer

TcpIpPort=12345

NamedPipeName=None

ShareName=OIDATA



This subdirectory (\\myserver\apps\revsoft\oi\appdata) has nothing in it except the revparam.  It exists solely to satisfy LHClient.dll



On the server, the Shares are set up in the registry as

OIAPP=c:\revsoft\oinsight

OIDATA= d:\revdata



In OI or Arev, you attach your data using the appdata placeholder

ATTACH_TABLE 'APPDATA\CUSTOMERS'

ATTACH_TABLE 'APPDATA\INVENTORY'

ATTACH_TABLE 'APPDATA\SALES'





The lhclient dll finds the revparam in appdata, calls the LHService which does the rest of the work. I believe that this model of fully specifying the data locations and separating the LH client role from the LH service role gives the most predictable results.

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=B268BDD9426E53D3852574A90075A4EF|View this thread on the  forum...]]