 |
No replication/synchronization is needed:
As of V9.08 there is no synchronization of CADENAS_DATA needed. At the local site, where the PARTapplicationServer is installed, access times then even will be a bit faster in compare to direct file access to 23d-libs.
At remote locations the speed should be Ok despite of accessing the headquarter. The main problem is the loading of large parts/ZJVs (also see caching with Squid).
With V9.08 clients further on directly connect to the LinkDB (in the same way as in current implementations).
Searching with filters and roles will be faster now from remote sites, although the LinkDB is not connected via AppServer. This is achieved by adding the LinkDB content to the full-text search index. That means, the LinkDB content has also to be updated by the "Nightly Update" (see Section 4.14.3.3, “Automated and cyclical update of data ” in PARTsolutions - Administration Manual).
SharedIndex (partsol.cfg -> [PARTindex] -> SharedIndexDir) may not be configured on the server. Constant net access would slow down the search. SharedIndex is only used on clients. Also see Section 29.6, “SharedIndex on $CADENAS_USER”.
Ports for PARTapplicationServer and SearchServer, configured in the configuration files differ by default, so that it is possible to drive V9.8 and <= V9.7 parallel on one server, which could happen in the changeover phase.
Available functions (with V9.08 SP0)
The PARTapplicationServer is providing the complete 23d-libs file system to PARTsolutions. That means:
For the most used functions APIs are implemented in the PARTapplicationServer, in order to make it faster. But not yet for all functions. That means, a few functions will currently be disabled in AppServer mode, meaning all functions, which write on 23d-libs, because it's a read-only file system.
For external access from PARTsolutions to the PARTapplicationServer from secondary locations SQUID can be optionally installed. Squid is free software, which is installed at customer site. For the PARTapplicationServer access HTTP is used. All ever loaded files are in the local cache.
Squid checks whether files are really up-to-date.
The cache can be initially filled via VBS scripting for certain catalogs. And via VBS command the files are nightly grabbed and copied in a temp-directory. Thereby the cache is filled.
Caching only works, when the headquarter is online.
This is not a real restriction, because the headquarter has to be online for LinkDB calls anyway. Also using earlier versions, PARTsolutions cannot be used remotely without access to the headquarter server.
When changing to the new PARTsolutions PARTapplicationServer, then also company internal parts, including LinkDB colors and role selection can displayed.
API: Via API inhouse third party systems like PDM systems for example can access the PARTapplicationServer. (Therefor an extra license is needed.)
Due to PARTapplicationServer's own caching an additional Windows File Caching is not necessary.[153] [154] It possibly can slow down the search on the server significantly.
Slowed down search when using a virtual disk
When testing on a virtual machine you have to consider, that the C disk on the server is not really local, but rather is in the network. (When testing on a real C disk the speed is possibly higher.)
When caching is used, all search indices are saved on the PARTapplicationServer. This makes sense, because accessing a local resource is faster.
Using a VM the process differs: Caching happens from the net into the net and then parts are loaded from there. This could act as a brake.
Better use an ESX host with local disks, still better an ESX host with local SSDs. In this way search times can be reduced again, especially if a search results in as many parts that they do not fit into the memory. Furthermore then there is no network bottleneck.
