Here's a couple of things that I have come across during performance tuning:
Logging Logging is work. Work consumes time. Many people tend to turn off logging completely for production environments. Advantage: It's faster. Disadvantage: Troubleshooting is harder. Besides this make sure you don't forget to turn off extended logging, after support has told you to activate it for a special ticket. Put caches and logs on separate physical drives to improve disc i/o. Logs and caches are written quite simultaniously. Don't deactivate your antivir. It might be helpful now and then. Adding exceptions for these directories would do instead: - Opentext\WS\MS\ASP\ImageCache - Opentext\WS\MS\ASP\Log - Opentext\WS\MS\ASP\PageCache - Opentext\WS\MS\ASP\RedDotTemp - Opentext\WS\MS\ASP\PluginCache - Opentext\WS\MS\ASP\RenderExtensionCache - Opentext\WS\MS\ASP\XMLCache - Opentext\WS\MS\ASP\Thumbnail For servers >8GB Ram set OpenText.WS.MS.ObjectProcessService.exe.config: <!-- Threshold for cache release in MB --> <add key="CacheMemory" value="2500" /> main.config: <PageBuilder> <!-- The threshold in MB of used ServerService memory that triggers a PagebuilderCache clean up operation. --> <PageCacheMemoryThreshold>2500</PageCacheMemoryThreshold> </PageBuilder> For 32GB RAM werden 12GB should be set for both values. As long as memory usage stays unter this, the value is ok or can be decreased. Does the usage hit this value, incease it. Optimize Caches Caches on local drives speed things up a lot. As long, as the local drives are fast. If the CMS is a virtual box and shares the hardware resoruces of the host with other guest VMs, this might become a problem. Than it may be good to store the caches in the server's ram instead: RdServer.ini [DEFAULTS] donotusefilecache=1 Cluster Communication Use Microsoft DFS replication instead of UNC Path (\\server\share\) for your RedDotTemp. App Pools You decide, when the app pool is recycled. By default, app pools are recycled every 29 hours. Then, all user sesseions are shut down, too. To avoid users from losing their sessein with virtually no reason, tell the app pool to recycle at night or whenever you editors tend to sleep. AppPool > Advanced Settings > Recycling > Specific Times > [0] = 01:00:00 Network Look at your routes. In some cases the system is slow while all components respond fast. Maybe your routing sends your data on a nice journey? DNS If your DNS is slow, adding the servers to your host files may speed things up. But don't forget the host files, when IP adresses are changed! Last but not least the two main rules for analyzing performance problems: #1 Trust nobody. Check it yourself. #2 Dont trust specifications of infrastructure. Measure the actual speed and performance yourself. It leads to nothing when you try to list up all parts of your CMS environent and try to check them one by one. Divide et impera: Try to look at CMS functionalities that only use a limited number of variables: Example: The CMS is slow. - Use the Server's local browser to rule out client and client network - Go to Server Manager, if it's fast, IIS is okay and databse is fast at least for small statements. Here, the Project Databases are not involved. - Go to SmartTree to check the project database. Does is still respond ok? - Open a page preview and measure the response time with fiddler if ti's slow, its PageBuilder, Navi Manager or PreExecute. - Check each of them to see wich of them is fast. If you don't like to do kung-fu in your templates to separate the three components: Do the following: - Create a view, that returns the current date with milliseconds (or ask me for it, and I can send you the SQL). Add a database content element to the head of your master page and get this value. This is the starting time for PageBuilder. - Create a Custom Rendertag that returns the current date with milliseconds and add it underneath your DB element. This is, when Navi Manager starts. (Or ask me for it, and I can send it to you) - Now write out the current timestamp with milliseconds in PreExecute and RdExecute. - Finally put a comment around all of them. Now you have a comfortable way to look what parts of the loading time of a page is caused by each of the components. Database Interestingly, most CMS actions don't create SQL statements with large executioon times. Instead, myriads of tiny sql statements are fired. That makes it a bit harder to tell, whether the duration is a good value or not. Another problem is, that they are not processed sequentially. A lot of them is parallel. A very important fact is, that the cms server can open an impressive amount of DB connections. Good DBAs would want to limit the value. Never do this. The number of connections cms can open and has to open to be fast has nothing to do with sanity. Unlimited is the only value that will work. Sometimes actions are much faster when you cast them out a second time, even after deleting the cache and a new CMS session. Then the database cache is hot and delivers faster. To proove that there is no caching involved, use SQL Server Profiler and Log the SQL sent between the initial and the repeated action. If the same queries are sent to the DB again and the result is faster, you can tell for sure that the DB is the bottleneck. Recipe for a fast CMS Database: 1. Unlimited Number of allowed connections 2. Fast HDDs 3. Fast HDDs. If you think that there are no nonger slow HDDs on the market: There are. 4. Use the smallest loglevel 5. Use different physical drives for Data and Logfiles 6. GBit Lan between CMS and Database with dedicated NIC It helps a lot, if the DB server is dedicated to the CMS. If the db server is a VM, CPU, Memory and Dic I/O are irrelvant. Look at the host machine underneath. It is common belief that SSDs should not be used in Databases because of the limited writing operations per cell. Depending on the type OF SSD (cell type), this is no longer relevant today. Hope this helps somebody. Cheers, Boris -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/reddot-cms-users. For more options, visit https://groups.google.com/groups/opt_out.
