TZ 270 - 7.0.1-R1262 - bad experience with low bandwidth connections
one of my customers got a new TZ 270, because it's a very small location with very less bandwidth (1.5 Mbps). In the past with Gen6 that was no major issue, it was slow, but I was able to connect to the Firewall without any bigger problems.
But with the new inflated SonicOS 7 it's close to a nightmare. It took around 2.5 minutes from connecting until it showed the Dashboard. It loaded nearly 30 MB of Data.
Assuming all these files are really needed and optimized, why not honoring the "Accept-Encoding: gzip, deflate, br" Request Header the Browser is providing and gzipping these huge files? This would bring down the marked 19MB to around 5MB, a 75% reduction in data transfer?
On-Box Management in low-bandwidth environments will be a real struggle.
Yeah, would be good if there was a low-bandwidth optimised version or theme for the web interface. I would be happy to accept fewer features/graphics/colours/whatever in the web interface, in exchange for the ability to get things done more quickly.
Compare the speed of the Gen 4 web interface with Gen 6 and Gen 7. It's not just Sonicwall guilty of this, I get the feeling that web interface developers only test things on a fast, recent PC with a 1G link to whatever it is they're developing!
Hi @Arkwright having a different theme will probably not happen, I'am still annoyed about the Classic/Contemporary Situation on the SMA. But by just gzipping the content coming from the Firewall it would help a lot, performance overhead is IMHO minimal considering the new Appliances are so powerful (according to SNWL).
I can confirm poor performance of the managment UI in a low internet bandwidth environment. Even when managing locally. TZ570 on 7.0.0 R9XX.
I do wonder, if the firewall has internet it will try to pull things from Sonicwall's servers. Cause when managing locally without internet there aren't any delays.
It's not just bandwidth, unfortunately. /api/sonicos/dynamic-file/getObjectList.json [~430KB] is fetched every 11-15 seconds so long as you have the web interface open, even if you're doing nothing with the web interface. This pegs a core for about 3-4s on my machine, every time.
It seems that there were some changes in SonicOS 7.0.1-5023 on that matter, because it looks to me that finally there is some gzip Encoding on the way. This makes the Experience much more snappier on low bandwidth deployments.
The Firmware Upload took 30 Minutes, but it was worth it :)
The Firmware Upload took 30 Minutes
Is it really better than the past?
We have client has a 10mb PPPOE half duplex link. We cant even load the management UI.
Page show blank after admin login. However, Sonicwall support said he cant do anything with it.
Hi @Nat in my case it's way way better. But your blank page got me thinking, because I'am having the same problem in latest Google Chrome on macOS. After submitting the admin credentials the page becomes blank. This only happens on my endpoint with Google Chrome, Firefox and Safari is working fine though. On another Endpoint every Browser is working fine.
It seems besides gzip compression the web application is profiting from caching as well.
I might be wrong, but for me it looks that Firefox is way faster then Google Chrome here, especially for subsequent re-logins. Maybe Firefox is able to handle the caching much better, I did not do a deeper analysis. Google Chrome takes now around 1 Minute (from 2.5 Minutes) for every login, but Firefox only takes 1 Minute for the first and around 15 Seconds for any subsequent login.
Next week I'am on-site at another low-bandwidth location and report back.
My client bought 3 TZ 270 and deployed last week. Only 1 site has a low speed link (10mb half duplex).
Only the low speed site goes blank after login. The other 2 working great so I think the issue is the low speed and half duplex.
And I did check on different firmware: 5018 on TZ370, 5023 on 3700,SonicOS 7.0.1-R1368 on 6700.
All of them are downloading around 20MB resources(from chrome debugger) on initial login to system status page.
I completely wiped all Browser Data from Google Chrome on my macOS Endpoint and finally I'am able to login.
IMHO I tried to clean all Application Data for that specific site, but this did not do the trick for me.
Are you saying 5023 on the slow line isn't giving you anymore improvement?
@Nat I have to back-paddle a bit, Google Chrome stopped working for me again, ending in a blank page like yours. This was working only for a short period of time. I stick with Firefox for the moment, faster and reliable for that matter.
On my internal checking, both 5018 and 5023 are encoding with gzip already. And from the downloaded resources , both around 20MB.
My client still using 5018, I don't have a 5023 device with slow speed internet to test.
If firefox does work, I can suggest to my client.