As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
We currently host webfocus version 5.3.2 and 7.1.2 in our production environment. We perform large batches (Loads, Build:summarizing data) on a nightly basis. The client then reports and audits the data during the day. The volume of data is increasing significantly as we grow, and thus must process more in a shorter time frame at night. We identified bottlenecks on the database server and added 32 GB of Ram to accomodate the requests and writing of data. It appears the middleware is now the bottleneck in terms of processing the read data locally.
So the question is, "Can the edatemp be placed into RAM to process the temp files more quickly?"
____________________________________________ PROD: WF5.3.2 with WFRS 5.3.2 ffs/ffs PROD: WF 7.1.2 with WFRS 7.1.2 OS: Windows 2003 Adapters: SQL Server 2000 SQL Server 2005 Oracle 9i, 10g
You're probably going to have to talk directly with IBI about that one. It would be nice, but that's not the architecture of the product.
There are, however, a number of things that can be done in your code base to prevent as few read/write operations as possible. Any intermediate hold files, especially when they are large and contain indices wil take significant amounts of time. If you can do more in single passes and fewer hold files, you can cut down processing time.
Regards,
Darin
In FOCUS since 1991 WF Server: 7.7.04 on Linux and Z/OS, ReportCaster, Self-Service, MRE, Java, Flex Data: DB2/UDB, Adabas, SQL Server Output: HTML,PDF,EXL2K/07, PS, AHTML, Flex WF Client: 77 on Linux w/Tomcat
Posts: 2298 | Location: Salt Lake City, Utah | Registered: February 02, 2007
Can you please update your profile signature with your product suite, releases, and platforms. That will make it easier for us to help you.
Darin is correct in what he is saying. Writing efficient WF code to process your data (you can use tracing to determine that; check Search for details) can improve performance tremendously.
In addition, it would be helpful to know what the source type and target type of your data loads are. That will also help us make recommendations.
I would go 64bit server and set your o/s cache high to take advantage of your 32Gb of RAM. You will have to reinstall wf server as 64 bit version as well possibly.
Server: WF 7.6.2 ( BID/Rcaster) Platform: W2003Server/IIS6/Tomcat/SQL Server repository Adapters: SQL Server 2000/Oracle 9.2 Desktop: Dev Studio 765/XP/Office 2003 Applications: IFS/Jobscope/Maximo
Posts: 888 | Location: Airstrip One | Registered: October 06, 2006
Kirkens the answer is yes if you use a product like SuperSpeed RamDisk. This maps your Ram as a virtual drive just like we used to do in the good old DOS days.
Once you have the disk mapped you can then configure edatemp to point to that location instead of the default which is under ibi\srv76\wfs.
For example assuming that you create a ramdisk mapped as X:
Add the following to edaserve.cfg and restart the WebFocus server