I Want Performance!

One of the biggest complaints I hear about PLM systems is the lack of performance. Users want things to move faster and are frustrated when the system takes what is perceived to be a long time to respond. In the back of their minds, the users probably know the system is dealing with millions of records and billions of relationships, but they are in a hurry. Server and Network upgrades are very expensive and do not always address the problem. So, what are some ways we can address performance issues without breaking the bank?

Many times, investment is the only answer

I will start by saying that underpowered servers and poor network connections are a real source of PLM performance problems. If your server is buried with the current workload, or your network is saturated, you may need some serious investment to fix these things. Of course, these problems are usually obvious, and well understood, and are largely only limited by your budget.

But sometimes there are cheap fixes as well

PLM performance issues can have many causes. Every link in the chain between the user and the product information that they want to access can be significantly degraded without actually breaking. It is these degradations that can cause a lot of performance issues that are relatively easy and inexpensive to fix. When trying to resolve performance problems for users, I have always tried to start from the user end and work back upstream to the data.

The user's device

The user’s device can be a huge bottleneck. Have they cleared their cache and temp file areas sometime this decade? Have they rebooted recently? Is their machine due for an upgrade? It might be a good investment for a heavy PLM user. If the machine’s CPU seems adequate, is the memory swapping out to disk all the time, maybe a simple memory upgrade can help. If the disk seems overwhelmed, can they get a solid-state disk? A small investment in the user’s machine might provide a tremendous experience improvement.

The Wi-Fi Network or LAN

Is the Wi-Fi network saturated? Moving to a wired connection can provide a big boost in performance, especially if they are working with large files. Most older buildings have a Wi-Fi network that was designed assuming most of the users to be hard wired. In one of my buildings, the usage was exactly the opposite of the design, and the Wi-Fi network was super saturated. Also, occasionally, one segment of a hardwired LAN is super saturated – modern networks can reconfigure your subnets and provide some relief.

Latency can be a difficult to fix

How bad is the latency back to the server? When it gets up to the hundreds of milliseconds performance can be impacted. Latency can be one of the hardest things to fix, because it is driven by physics (I.e., the speed of light), but it can have a dramatic impact on performance. (In some cases, you can use virtual desktops to help fix latency, but this can be expensive as well.) But latency can also be driven by simpler problems

Sick Routers

In some cases, the latency is not driven by physics. Routers on the network can have issues that cause latency problems. If a Router is ‘sick’ and losing packets, it can inject latency as it retransmits the missing packets.? Check the router logs to see if this is an issue.

Another issue is incorrect routing tables. I have seen cases where routers sent packets halfway around the world because an incorrect routing table said that was the shortest path. When we fixed the table, the performance increased dramatically.?

Sick cabling

Routers aren’t the only things that can be ‘sick’. The network cables themselves can become sick and cause packet loss. They might be wrapped around a big electric motor or pinched such they the shielding has broken down or simply be terminated poorly in the connector. These issues are harder to find, but some rigorous detective work can make sure this is not an issue for you.

Bad Routing

If you work in a multi-server environment, make sure that the users are pointed at the correct server. I have seen North America users that had their home server defined as Asia and vice versa. This type of inadvertent misconfiguration can cause a whole host of issues.

Server-side issues

Once we make it back to the server, we are still not done looking for ‘simple’ performance issues. A server can have all the horsepower it needs and still have slow performance.

Resource Contention

One of the big issues with server performance is resource contention. Make sure you know what else is running on the server that might be slowing down the PLM Application.

Zombie attack

One source of issues is ‘zombie’ processes. These are processes that have incorrectly terminated and are still consuming resources. They may just be using memory or in the worst case they are eating up CPU cycles as well.

OS imposed limits

Another issue I have seen is when the Operating System artificially limits your resources. Look at process count limits and other limits that can slow down the PLM even when there are plenty of resources available on the server. These are usually set one at the beginning and not increased as usage grows.

System Backups

One resource conflict that I have come to hate is system backups. Backups normally run in their late evening window when the system is relatively quiet. But sometimes they are delayed or run longer than anticipated and are running full blast right in your prime time working period. If you see performance issues, wayward system backups are a good thing to check.

Guest Applications

Another source of resource conflict is other applications on the server. I have normally had dedicated infrastructure for my PLM Application. In a few cases, we shared infrastructure and the other Application started to grow and did not invest in the infrastructure pool to keep pace with its needs. Make sure you have good service level agreements and, where possible, use Virtual Machines to segregate resources on shared hardware.

One time I remember being surprised by this type of conflict because we had dedicated hardware, but lo and behold, there was another application chewing up our resources. It seems that their server was having problems and the support team decided that, because we had plenty of room, we could temporarily share while they fixed the other application server. Of course, they neglected to inform me of the change and we had bad performance for a few days before we figured it out.

Database problems

The Database is another area where misconfiguration issues can cause real performance issues. There are several common Database performance issues that can impact PLM. Many of these can crop up long after the initial configuration was done.

Database File Extents

An obvious one, that has caused me some headaches, is database extents. When database tables are created, they are built using a file of finite size. When this ‘file’ fills up, the database creates another file to extend the data table – known as an extent. A small number of these extents do not have a huge impact on performance, but adding many can have a significant impact. The extent issue is normally seen when a little used table is pressed into bigger service by some enhancement. The small default table size is way too small, and extents grow like crazy. This gives poor performance every time the table is accessed.

Database Cache size

A related issue is memory cache size. To improve performance, databases normally use a shared memory area to cache recently used information, assuming it will be used again soon. This area is sized when the database is created but may not be expanded as usage expands. This can also lead to performance issues.

Poor Database Indexing

Another database issue that can impact performance is poor indexing. The database accelerates the query process by building indexes into the data so it can find records quickly. There are two issues I have seen.

One is that the indexes get out of synch or are corrupted in some way. This can cause performance issues. The other issue is that an enhancement or change in usage pattern has users retrieving information that is not indexed correctly or not at all. This causes huge performance issues as your database has just become more like a flat file. Both of these issues can be fixed easily, but you need to know that they are going on. A trained Database Administrator (DBA) should be able to check the database logs and see these quickly.

Poor Application Code

Sometimes, a developer will pick a very inefficient algorithm to get something done. Or she can just write some bad code. These knots in the code can cause sever performance issues when the code is activated. You can monitor query performance and even monitor the code execution to find areas where the system seems to spend a lot of time. Look at these areas and see if a better implementation of the function could improve performance for that operation.

Conclusion

Not all PLM performance issues require a huge investment to fix. Make sure your end-to-end user experience is not plagued by glitches, misconfigurations, or overloads. A little IT detective work and associated tweaks can really increase your user's performance without breaking the bank.

Have you used this Blog to solve some of your own performance problems? Do you have some other performance enhancement tips that do not cost a fortune to implement? We would love to hear about your experiences in the comments.

?

?Author Bio:

Digital Guideposts is written by Mark Pendergast – retired Data Junkie, Deep Thinker and Innovator. He worked with product data for over 30 years of his 41-year career in Automotive Components Manufacturing. His background includes work in Engineering, Operations and Information Technology. He is also an Electrical and Computer Engineer (BS-ECE) and a Certified Project Management Professional (PMP). In his spare time, he mentors a High School FIRST Robotics Team, reads and plays on his computer.

?

?