Prevx1 R update - v1.2.0.51

This release contains the following changes:

- Updated license information display on status screen of console
- Increased performance
- Improved policy handling and optimisation
- Improved scanner performance
- Ability to Clear all content from the Jail
- Updater will not run if a scan is in progress
- License display error resolved
- Help button on status screen
- Updated driver with performance improvements

This release addresses many performance and compatibility issues, and is a fairly major update in that regard. If anyone has any compatibility issues or significant performance issues, please feel free to PM me. We are putting a lot of focus on compatibility, so any feedback is greatly appreciated. Anyone that was put off by such issues, but still interested in the program, may want to try this build.

 

So what about the PrevxR version?

 

aigle,

did you read the topic name?

Prevx1 R update - v1.2.0.51

 

Ah! sorry. I just missed it.

 

This is indeed just for the R version

 

Ya, I can see it now!!

 

How does this fare in terms of CPU usage now?

Does it still have conflicts with the new versions of ZoneAlarm?

 

I personally don't see any problems, but not sure you want to hear it from me

ZoneAlarm still has their message stating that there's a conflict, but we've never actually known there to be one. Since ZoneAlarm is one of the most popular firewalls, you can imagine we have a lot of users using both of them together, and none of them are actually having any problems. To bypass the compatibility message from ZoneAlarm you do have to uninstall Prevx1, install the ZoneAlarm update (if that's what you're doing, which is the most common), then install Prevx1 with ZoneAlarm disabled. We're not sure why they put that message in there, other than, perhaps, as a pre-emptive attempt to avoid potential conflicts, but we are in contact with them to get this resolved.

 

Hum, it makes me curious as to which "performance" was increased. Could anyone clarify on exactly what this means? RAM usage was always low with Prevx, but CPU usage was high for me. I thought that was what was addressed.

Thanks for the quick replies Notok. I'll try this when the issue with Zonealarm has a resolution.

 

They just generally do further code optimizations. We haven't had any issues with high CPU usage or some time (with the exception of possible software conflicts, but I'm not aware of anything ATM), so this is more about how quickly the program works.

Unfortunately that's completely up to ZoneLabs. Prevx1 has no actual compatibility problems with ZoneAlarm, there is no known reason for the message they display.

 

Hi sosaiso,

The focus on the performance changes have been in 4 key areas:

1. Impact on a processes when they aren't triggering any alerts - that is the monitoring element. Previously, we did quite a lot of work before deciding that we weren't interested in the specifics on an action. This resulted in a slight overhead on each operation across the system and therefore general system slugishness. We have made changes in our drivers that mean that we now have zero impact when an process performs an operation that we aren't interested in - a registry read for example.

2. Throughput rates of concurrent events - that is the number of simultaneous actions the agent can handle at the same time. Here we used to action each event in series - though we kept decisions and reports seperate. Now we can action many concurrent events simultaneously. The change here means that if you monitor the pxagent process you will see its thread count rise under heavy load and fall off again later when the system is quieter. This has a slight negative impact on memory use temporarily, but has a great impact on throughput. We have also made changes to our logging so that it suspends disk writes during times of high load - it then plays catchup once the high load is over.

3. Internal memory usage - that is the amount of memory consumed and the amount of times data is copied around. Essentially here, we have spent some considerable time analysing the performance of commonly used routines to ensure that they are optimized for speed. As an example, for those of you that are fluent in C++, this is the kind of change we've made:

Old method: SomeObject someMethod();
New method: void someMethod( SomeObject& result );

This might not seem much of a change, but if SomeObject is a deeply nested class containing a lot of dynamically allocated memory, this kind of change can make a significant performance improvement. It means a lower overall memory footprint and lower CPU use. It also lowers the overall time taken be the agent to make a decision involving user-configured rules.

4. Synchronization Lock Scope. Here, we have analysed the scope of each synchronization lock (the things that stop more than one thread modifying something at the same time). We found that there were a couple of choke points that could be improved. For example, we used to use the C-runtime libraries for disk I/O and memory management - both contained locks outside of our control. We found that under high-load we spent 99% of the time waiting for these locks. This was a crazy situation, so we've rewritten everything to use the low-level Windows APIs directly.

These changes have been filtering in slowly since about 1.2.0.47, but 1.2.0.51 contains them all. BTW, we're actually in test on 1.2.0.52 and this should be on Prevx1R sometime today or tomorrow.

Regards,

ghiser1