I consider the UI extremely slow. I know it is using Java and that is taking some time. But here are some figures:
- clicking Login until dashboard appears: 22 seconds
- from Policy: clicking on top level first rule set until it appears: 16 seconds
- from Troubleshooting: clicking on "Rule tracing central" until it appears: 13 seconds
- clicking on Logout until login screen appears: 15 seconds
As soon as I had something on screen within one session I can click there again and it appears much faster. There seems to be some compilation mechanism which is cacheing its results until logout.
It is the same for Firefox and IE, Java version is 126.96.36.199.
Is this expected behaviour or is there something wrong?
sounds to if there is a slow connection to the appliance.
The browser will load the applet obviously. Do you have caching enabled in Java?
Once the UI is loaded it will load lists etc. from the appliance once requested. is the appliance close to you or in a very remote site that might have some 'slow' connection or larger latency?
I am connected to MWG through a Squid proxy. My PC is connected to Squid through LAN, Squid is connected to MWG through LAN.
The complete internet browsing runs through this Squid and this MWG, so I would know already if there were any bottlenecks.
1 Gbps ought to be enough for everyone. :-)
And yes, Java caching is enabled.
a Squid between Client and MWG unfortunately is not a good idea. I have noticed this a while ago (so the behaviour might have changed) but Squid causes problems with the connections between Client (Applet) and MWG (mwg-ui process).
Without squid in the line you may see there is only 2 or 3 connections between client and MWG which are kept open and used for heartbeating the connections and (of course) exchange data. With Squid in the line I noticed that those persistent connections were not kept open correctly but closed by Squid which caused the client to build a few dozen connections between Applet and mwg-ui.
In the customer environment where I saw this behaviour this led to slow and sometimes freezing UI experience, so we were able to get an exception to have the Applet talk to MWG directly.
Since we don't have any proof (apart from what I slightly remember ;-)) that this is really your problem, do you think there is any chance of running the UI on a computer which does not need to go through Squid to MWG, e.g. a laptop in a network "close" to MWG (with a direct connection)? Maybe this helps to solve the problems.
you are right: I tried a direct connect between my client and MWG without Squid (fortunately I am the firewall administrator too :-) ) and the UI became much faster.
I will try to investigate what the problem with Squid and MWG is and report back.
then you have a trustworthy firewall administrator who opens any port you desire... lucky you! ;-)
As far as I know the problem with Squid (at least version 2.x) is/was about HTTP 1.0/1.1 and persistent connections. We have not further investigated as the customer was happy accessing the UI directly but I think the issue was that connections were closed between Squid and MWG, so that the Applet had to create a new connection every now and then. There is pretty much noise between Applet and UI which caused the problems.
I would investigate if there is anything about persistent server connections in the Squid configuration that could help and play around with the settings. But as mentioned earlier, so far I only make some guesses here. In case you need assistance to troubleshoot what exactly happens support might be able to take a closer look at any debug data you can provide.
Let me know if you find something helpful!
I looked at all the relevant keywords in squid.conf, but did not find anything making any difference.
For now I changed our usage of the administration UI to direct access (without Squid in between), mostly because this is my last workday before vacation.
Actually I consider this a MWG bug based on probabilty reasons: if Squid had any serious problems with Java applets and persistent connections, then I would find a considerable amount of hits for this on Google. Well, I don't.
I will be happy to work with McAfee support on this if McAfee is willing to put any effort into this. Time frame would be mid/end September, after my vacation.
it is definitely possible that there is an issue in the MWG applet or maybe it is designed in a way that does not work very well with persistent connections. Actually this has not been followed up when I discovered the problem, as customer was happy with an exception. To troubleshoot I recommend to file an SR with support and provide at least a feedback and some details about the environment. Also if there is any chance it would be great if you can ensure Squid is causing the issues, e.g. using the same computer one time with Squid one with without Squid but without changing too many other "aspects" that might cause a different result, e.g. the problem exists on one computer but does not on the other - could be a lot things that causes trouble :-)
I've recently upgraded to the 7.4.x branch of web gateway and startup time for the web gateway went from "painful, but it's worth it for this beautiful interface" to "oh my God, I'm going to hurt someone, where's a stopwatch app? This is ridiculous!" ... 1minute 40 seconds under Java 7 u75 (the latest supported in the Java 7 branch). Ain't nobody got time for that.
I took a poll of coworkers on their startup times. Some wiseacre said "5 seconds." I had him show me. I was in disbelief.
He was running the latest Java 8.
Given that most appliance vendors manage to break horribly when Java jumps a major version, I'm loathe to upgrade all my boxes, but I did want to share this zomg with y'all.
Out of curiosity I tested this on my system:
Windows7 Enterprise 64-bit
Java 7u75 32-bit
HTTPS Connection to MWG:4712
100Mbps router between client and MWG on seperate subnets.
From the time i hit the logon button until the dashboard displays is ~10-15 seconds for both IE and FF.
I'm not so sure it has anything to do with the version of Java.