Scheduled maintenance on Saturday, August 8th from 7am to 10am (UTC). Licensing registrations and key activations will be unavailable during this period. More info here.
We'd love to hear about it! Click here to go to the product suggestion community
Almost 20 seconds elapsed from the instant when you click apply to the instant you get back to Firewall rule page?
Guys, I hope that you track this as a bug and improve the performance.
In reply to lferrara:
In Addition, Lucar:
threads like this should not even been opened. Waiting 10-14 seconds after updating a firewall rule is a shame!
Sorry for posting. I am just a privat user like you.
Just wanted to know, if there is a new issue with the V18 release, because the time to complete a task is kinda the same in V17 to V18, from my experience.
Something i looking forward is CM. Central has some powerful UI. You will be fast in configuration and easily push this configuration to your XG.
In reply to LuCar Toni:
While i have found that the process of rule creation and updates takes 15+ seconds on the XG125 running either V17.5 or on my test V18 box, I know that on several customers XG310 units running V17.5 it is a lot faster.
While a few people have been using CM to make changes and are advising that the rule updates are faster, is this actually the case? is the CM GUI just more responsive because the changes to the actual firewall are being background tasked, and still taking 15+ seconds to complete, but because the CM is not instant access people are just not observing the time requirement.
Personally while my XG125 units in the field are slow at firewall edits and changes, I am not finding the GUI that unreasonable. If I was seeing that delay on the XG310's I think I would be more concerned. I also do not use anything smaller than a 125.
Appreciated your opinion Luca. As I said, most smb will use only XG and nothing else.
Just my opinion: I would not agree with you Luk, because i assume, SMB customer would rather use more then one product (XG). Most likely Endpoint, mobile or something like that. So the story to use Central is not new to most customers.
Lets stay on topic here:
Personally speaking, i use a XG125 at home and rather rarely touch this box. So i did not even notice the UI performance at all.
Other boxes (XG450 and 230) are quite fast.
My lab vmware appliances are quit (Uses the I7 of my workstation).
If you access the webadmin of a CM managed EAP2 appliance, there will be a banner "Please do not change something on the Webadmin".
Did you see this change? Did somebody test this and report some feedback about CM to the DEV Guys? They are looking for your Feedback!
I am running a 50/20mb/s link. If you think the management by the CFR is quick you must have a very fast connection and be close the server network speed wise.
Using my J1900 XG I decided the GUI was too slow and moved a more powerful box, well the CFR management is slower than the J1900.
In reply to rfcat_vk:
Thanks Ian for your feedback.
Well, I am an SMB customer, so let me share my perspective.
I absolutely agree with Luk. As a customer, the last thing I want to be told after buying a product is that I need to buy something else in order to "really use" the product I just bought. It gives one the impression they have been "bait and switched" and trust me, it is not a positive feeling.
So to bring that full circle to the thread topic, the time it takes to update a firewall rule isn't too much of a problem for me personally because I don't do a lot of it; my firewalls are set up and I rarely need to make any large scale changes. If I had to, I can see where it would be a frustration though, and I can promise you "buy Central" would not be an answer I'd personally be very happy receiving.
On other firewalls, saved changes are applied (or compiled should I say ?) only when you click "apply". In other words, you may create many rules, or modifications, but the Firewall will apply these changes only when asked to. For Checkpoint, saving changes is instantaneous, but applying it is quite long.
TTFB stands for time to first byte. To put it simply, this is a measurement of how long the browser has to wait before receiving its first byte of data from the server. The longer it takes to get that data, the longer it takes to display your page Krogerfeedback
In reply to Meidinger Duncan:
I find the speed of the XG UI excruciating. On a working system, already configured, for just a simple inspection or just a couple of edits to the rules it is slow but now worth worrying about. But trying to configure a new system, esp. when you need to experiment a little (I have spend the last 3 days setting up v18 EAP3) then you will spend HOURS just trying to do something that on other firewalls takes only a few minutes. After HOURS you get fatigue and start forgetting what you just did 5 clicks before which makes the whole process open to errors and frustration.
I think the problem might have to do with the not "updating the firewall backend" but the recalculating the main page counters and performance indicators. That needs to be rethought - when I am working on setting up the firewall, and testing FUNCTION, I don't care at that point about the PERFORMANCE indicators. That main page "control centre" is brilliant, but those counters should be constantly updated with every UI refresh on other pages.
In reply to lemonadesoda:
typo, for clarification: That main page "control centre" is brilliant, but those counters should NOT be constantly updated with every UI refresh on other pages.
I agree with lemonadesoda
UI and logs should be the highest priority faetures to rewrite as now the UI is very slow compared to the market. Updating a firewall rule on UTM9 requires a second.