Welcome, Guest. Please login or register.
September 06, 2008, 11:05:37 AM

Login with username, password and session length

189062 Posts
22034 Topics
52843 Members

Latest Member: fox

Search:     Advanced search | Tag Cloud
+  Welcome to the Comodo Forum
|-+  Desktop Security Products
| |-+  Comodo Firewall
| | |-+  Bug Reports
| | | |-+  Performance issue when remembering answer from Def+ alerts (V3.0.18 - .25 X32)
« previous next »
Pages: 1 [2] Go Down Print
Author Topic: Performance issue when remembering answer from Def+ alerts (V3.0.18 - .25 X32)  (Read 3471 times)
Ronny
Global Moderator
Comodo's Hero
*****
Online Online

Posts: 390



« Reply #15 on: July 16, 2008, 03:57:26 AM »

I'm having a D+ rulebase with 275 app rules in it.
Only to apply the rules takes 20 seconds !! and 50% cpu (and i don't have a 5 year old cpu !!).
So if i "remember" anything to the D+ rules than it also takes 20sec's and 50% cpu to "learn and remember" so i'd call that slow.

Vista SP1 x32 (UAC) - 3.0.25

edit put up a screengrab from cpu/time load for installing an app.
this is on a dual core with peak of 52% cpu load total.
« Last Edit: July 16, 2008, 04:54:22 AM by Ronny » Logged
PiCo
Comodo Loves me
****
Offline Offline

Posts: 105


« Reply #16 on: July 16, 2008, 01:37:08 PM »

The thing I don't understand is: why does it work super fast in training mode (automatic learning of rules), BUT there's a 20 sec hang as the friend above said when doing it manually?
Logged
Vettetech
Computer Security Testing Group
Comodo's Hero
*****
Offline Offline

Posts: 4512



« Reply #17 on: July 16, 2008, 01:38:38 PM »

No hang for me works great actually and I have a P4 overclocked to 3.06 GHZ with 2 gigs of ram.
Logged
Ronny
Global Moderator
Comodo's Hero
*****
Online Online

Posts: 390



« Reply #18 on: July 17, 2008, 12:57:22 PM »

This issue is related with the way the D+ rules are saved.
They are all in the Registry and if i put the procmon on cfp.exe while applying the D+ rules
It first does a RegDeleteKey over all key's below HKLM\System\Software\Comodo\Firewall Pro\Configurations\0\HIPS

It takes from 19:43:44.31 - to - 19:43:45.84.

After that it uses RegCreateKey and RegCreateValue to rebuild the policy.

It takes from 19:43:45.84 - to - 19:43:59.83.

Most of my rules are "Custom Policy" only a few are "Trusted".
An export of my HIPS Policy key is 2,20MB large.
Logged
aigle
Comodo's Hero
*****
Offline Offline

Posts: 325



« Reply #19 on: July 18, 2008, 05:09:57 PM »

On my system I have always got a slow down in application launch with CFP. It was never the case whe I used SSM ands EQS. I wish that the developers look into performace issue seriously.

I want a smart n quick CFP, not a plump n lazy one.
Logged
Vettetech
Computer Security Testing Group
Comodo's Hero
*****
Offline Offline

Posts: 4512



« Reply #20 on: July 18, 2008, 05:19:54 PM »

Once again I disagree with all of you. Each pc is different understand. I run Comodo 3.0 with D+ active and NOD32 on 2 pc's. Also all of my family runs Comodo with D+ active and Avast. ANY program I start launches in seconds. That is once the program  has been learned. If the program isn't learned yet then there is a pause of about 5-6 secs or so till the program actually starts. No one in my family complains about performance issues. I also have about only 25 porcesses running at all times.  My 2 pc specs are as followed:

Desktop : P42.4 overclocked to 3.06 GHZ
               1 GIG of RAM
                7800 GTX video card overclocked of course
                500 Watt PSU
                2 160 GIG 7800 RPM Seagate Hard Drives

Laptop : Intel® Core™ 2 Duo T9300 (2.5GHz/800Mhz FSB/6MB cache
            2 GIGS of RAM
            8700m GT video card
             160 GIG hard drive
« Last Edit: July 18, 2008, 05:21:30 PM by Vettetech » Logged
Ronny
Global Moderator
Comodo's Hero
*****
Online Online

Posts: 390



« Reply #21 on: July 24, 2008, 01:30:44 PM »

Vettetech i can tell you this is really getting annoying i just installed a new application and it prompts me several times to "learn" you can count how many just by counting the CPU spikes see screenshot, and the screenshot is not even complete, it is still prompting me with pop up's.
It started at 20:05 and finished at 20:26 that's no fun to wait for !!

Processor Genuine Intel(R) CPU T2500  [ at ] 2.00GHz, 2000 Mhz, 2 Core(s), 2 Logical Processor(s)
2GB Ram
Vista SP1

My D+ Rulebase is now 298 applications large.
I think i'm gonna try to disable all other programs and see if that helps any.
Logged
Vettetech
Computer Security Testing Group
Comodo's Hero
*****
Offline Offline

Posts: 4512



« Reply #22 on: July 24, 2008, 03:35:05 PM »

Why don't you use install mode when installing something and also put D+ in training mode.
Logged
Ronny
Global Moderator
Comodo's Hero
*****
Online Online

Posts: 390



« Reply #23 on: July 24, 2008, 05:06:13 PM »

I do use Install mode, but after install i'd like to be in control of what the application can or can't do.
And this was definitely not so on a small D+ policy. The way it get's written to the registry just doesn't scale on a large policy. First delete the whole policy and then completely rebuild it in registry is just to slow.

Logged
Vettetech
Computer Security Testing Group
Comodo's Hero
*****
Offline Offline

Posts: 4512



« Reply #24 on: July 24, 2008, 05:17:25 PM »

I guess I don't understand exactly what your getting at. I never install anything that I do not know or trust. I usually download and install game patches, WindowBlind skins, etc. I have everything I need in my pc. I have never had any reason to monitor every program I am installing. I might try something from time to time but if I am doing that I do it under a Sandbox.
Logged
khagaroth
Comodo Family Member
***
Offline Offline

Posts: 57


« Reply #25 on: July 26, 2008, 03:08:15 AM »

Why don't you use install mode when installing something and also put D+ in training mode.

And why exactly are you asking this stupid question? The problem isn't the way the user uses the program, the problem is the way the program works. The user shouldn't have to change his behavior just because a part of the program (storing settings) was badly written.

The best solution would be to completely ditch storing settings in registry and switch to a database. But even changing the registry structure so that it won't have to be completely rewritten each time a rule is added/deleted *) would be enough. Especially when it not only causes slowdowns, but also loss of configuration, when a rule is added at system shutdown (because there is not enough time to delete/rewrite the whole tree before the system halts).

*) Ie. by switching from numbered rule keys (current behavior - the key number specifies order of rules, so if a rule is added elsewhere but the end, the whole policy key and its rule subkeys has to be rewritten to accommodate for the order change) to named keys (ie. application name or checksum value) and storing the order in a separate key as "order=rule key" value pair. This way, only one rule key has to be written/deleted at a time and then only the values of the key storing the order has to be rewritten. This would be a huge speedup, with not that much work on programmers part (compared to switching to database storage).
Logged
malbeth
Comodo Member
**
Offline Offline

Posts: 47


« Reply #26 on: August 28, 2008, 05:44:44 AM »

This issue is related with the way the D+ rules are saved.
They are all in the Registry and if i put the procmon on cfp.exe while applying the D+ rules
It first does a RegDeleteKey over all key's below HKLM\System\Software\Comodo\Firewall Pro\Configurations\0\HIPS

It takes from 19:43:44.31 - to - 19:43:45.84.

After that it uses RegCreateKey and RegCreateValue to rebuild the policy.

It takes from 19:43:45.84 - to - 19:43:59.83.

Most of my rules are "Custom Policy" only a few are "Trusted".
An export of my HIPS Policy key is 2,20MB large.


Holy Molly, that's one speed-optimized algorithm  Shocked Could anyone with 3.0.14 care to do a similar Regmon trace?

For the 50% CPU usage ppl, you are using dual-core CPUs, and the process of recreating the rules uses 100% of one of the cores. Just we wait until CFP learns to utilize multi-core CPUs to their full potential...

I've developed a habit lately to post this issue to every thread announcing new version. Now it appears that technically it's not a bug - adding rules looks working as intended - but man does this need to be improved!
Logged
gibran
Forum Member
Global Moderator
Comodo's Hero
*****
Offline Offline

Posts: 3443


Sometimes words are meaningless indeed...


« Reply #27 on: August 28, 2008, 06:40:42 AM »

The idea of a separate database is interesting if there is a way to protect it from accidental deletions.

I always wondered why CFP handles alerts this way. The only plausible reason I devised would be that this way CFP ensures no malware is going to tamper CFP configs during alert answering.

D+ policy branches don't require any particular order so it would possible to add only what it is really needed.

If CFP reg integrity was really the rationale behind this design I guess some hash regkey could be added to verify policy integrity.

Logged

MrBrian
Computer Security Testing Group
Comodo's Hero
*****
Offline Offline

Posts: 326


« Reply #28 on: August 28, 2008, 07:42:18 PM »

Holy Molly, that's one speed-optimized algorithm.  Could anyone with 3.0.14 care to do a similar Regmon trace?

I have v3.0.14 and did a trace with Process Monitor when creating a permanent D+ rule via alert.  For each of the existing 240 rules (likely because I have roughly 240 items in my Computer Security Policy list), CFP v3.0.14 did 4 or 5 registry operations.  Lastly, on the program whose rule was created, there were many registry operations.  It appears, from having observed approximately 5 rules created via D+ alert, that the entire policy of only the affected program item is rewritten in v3.0.14 when creating a D+ rule from an alert.
« Last Edit: August 28, 2008, 07:45:42 PM by MrBrian » Logged
Tags: CFP 3.0.21 BUG CFP 3.0.20 BUG CFP 3.0.19 BUG Alert remember answer slow CFP 3.0.18 BUG CFP 3.0.22 BUG CFP 3.0.23 BUG CFP 3.0.24 BUG CFP 3.0.25 BUG 
Pages: 1 [2] Go Up Print 
« previous next »
Jump to:  

SSL Firewall
Page created in 0.108 seconds with 19 queries.
Powered by SMF 1.1.5 | SMF © 2006, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks
Design by 7dana.com