Wingate 7.2.2.3416 Performance issues

[rkellyatspamcopnet]

I'm moving from Wingate 6.5.2 + Kaspersky to a new host on which I've installed 7.2.2.3416 + Kaspersky with 30 day trial licenses. This enables me to move clients to the new setup and back as needed while resolving issues. Other than visually attempting to match configurations I did not transfer anything from Wingate 6.

The new host has one 2.2 GHz Pentium 4 CPU, 2GB memory and 400MHz bus, vs. one 1GHz Pentium III, 512MB memory and 133MH bus on the old host. Both are running Windows XP SP 3. The new host is much more up to date with MS security patches. I have a very small network (5-7 clients) and do not use Wingate's access controls.

A TRENDnet TW100-S4W1CA router feeds both hosts. Each host has a single NIC fed by the router and a single NIC supporting the internal network, which currently is shared in common across the clients. I have confirmed the performance issue on the new host persists when the old host is disconnected from the internal network.

Problem:

Clients using the new host stall when building web pages with images. Refreshing the page often allows completion. Turning off the Wingate cache considerably improves but does not fix the issue. Without cache, image downloads stall about 20% if the time, and the one attempt I've made to download mp3 files (from Amazon) stalled on the second file, at which point I moved that client back to the old host. Restarting a stalled image download using a download manager is usually successful. Interestingly, usenet downloads through the new host seem to proceed at about twice the speed of the old host, likely since they use stable TCP connections and benefit from the new host's CPU speed and additional memory.

With the cache active most downloads stall and also fail reporting incorrect file size. I turned off the cache after noticing various cache warning messages - the most common being

"{HTTPCache::ValidateResponse} response ETag "d48dfb52e84bcc1:8037" in response doesn't match client or our Etag - server error".

Without the cache I frequently see "Socket exception in CDNSService::OnRead Connection Reset by Remote Host {Thd 356} [socket #D2C, 10.25.25.3:53 to :0]" but haven't yet attempted to match this error to the stalled downloads. DNS on both hosts is configured identically so far as I can determine. Client IP's are static. 10.25.25.3 is the new host's local network IP, vs. 10.25.25.2 for the old host.

I use Commview to trace network packets - not yet productively in this instance however it does report the NIC traffic registers. All NICs on both hosts report no collisions, no over/under runs, nor frame errors. The Windows error log does not appear to indicate any relevant network issues. One 4226 error resulted when I was scanning the external link using 10 processes at a time.

I'm about ready to abandon Wingate 7. Perhaps you have suggestions I can try first.

[adrien]

Hi

That reported cache error is fairly common, and it's an error at the remote http server, but only results in the cache lookup failing. Are you getting heaps of these?

If you like, I can have a look at your system remotely, just open a ticket by emailing support@wingate.com, with remote connection info (we recommend Teamviewer).

Regards

Adrien

[rkellyatspamcopnet]

Adrien - thanks for your reply.

Actually I'm more likely to abandon Wingate than install a backdoor on a host with access to the internal network. Have we reasonable alternatives?

The issue with the cache isn't directly relevant, except that the problem is so much worse with the cache active on Wingate 7 so somehow the root problem plays into cache operation. Leaving cache disabled is not an issue for me.

By contrast having cache active on the Wingate 6 host does not appear to create any problem.

If it does come to installing TeamView, I'll need time to set up a separate physical network with disposable images for the Wingate host and a test client.

Again - thanks!

Best regards,

Bob

[adrien]

Hi Bob

I don't know if you've used TeamViewer before, but it doesn't open any back doors into your network.

It allows someone to see the desktop on the computer it's running on (the gateway), and you get to supervise what is being done, and control whether the remote connector can use mouse / keyboard etc.

WinGate 6's cache index was all in-memory, and so had a much smaller resource footprint (in terms of CPU) to do cache lookups. If you're using the default MDB cache index, that doesn't really work that well on low-spec computers. You could try changing database for the cache index to something like MySQL running on another computer.

We're actually planning to offer another cache module option that doesn't use a SQL based database for the index. You'd lose ability to access the data in the index for other purposes, but the performance we expect would improve at a cost of increased memory consumption.

I hope you trust WinGate enough to install it on your network without fear it creates a back door into your network, and we have no desire to put ourselves out of business by breaching that trust.

We do find however that actually seeing what is going on is the quickest and most effective / least painful way to actually resolve issues and move on.

Regards

Adrien

[rkellyatspamcopnet]

Adrien,

If my earlier comment in any way appeared to imply distrust of the Wingate product or Qbik staff I do apologize. That certainly was not my intention. I've used Wingate since 2008 and have never had cause for concern about Wingate's security.

I'm still reviewing TeamViewer's technology and security statements. Their architecture superficially resembles Webex, which I have used in a corporate setting. If finally I am satisfied I'll open a ticket as you suggest. Your comment about cache resource utilization does however suggest Wingate 6 may prove a better fit for the new host I'm building.

Thanks!

Best regards,

Bob

[adrien]

Hi Bob

no offense taken.

In the end, we can use whatever remote assist product you're comfortable with. We have found in general TeamViewer performs (in terms of responsiveness) better than pretty much all the others - which is why we recommend it.

Regards

Adrien