Networks

Ask something
Discussion Locked

SQL application over a 1.5Mbps DSL WAN l

0 helpful
5 replies

by determined

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I currently have 2 sites connected together over a DSL WAN link. Server is PIII with 1 550Mhz CPU(Xeon?) It's Dell Poweredge with 8 scsi drives(4 -9gb & 4 -36gb). 1/2 gb of RAM. Os-Microsoft Small business server 4.5(Win NT 4.0,Sv. Pack 6, Exchange 5.5) 20 clients are logging in total(15 local , 7 remote on Win 98 clients). 1 particular user has to access an SQL db over the wan and is having a very slow response time(6 minutes, on some processes). Others over this wan link(for printing and email have no similar speed degredation).

My questions is 1: Is the SQL app the issue(it's an access front end). 2: How much can I do about the Wan links. I have been told that although the firm is paying for 1.5mbs, there are not guaranteed that speed. Lastly, I noticed the processor was running at 97% utilization and the SQL exe was taking just about all of my ram. I'd like to recommend that the server be upgraded with anohter processor and RAM. We are also entertaining the usage of Citrix and or Windows Terminal Server as the number of users on this SQL application will grow to 50(30 which will be staff in the client's 3 remote offices.)Also, I want to suggest the client offload the SQL product to a dedicated server.

other details: 3com swithces, netopia DSL routers in both offices and Covad DSl are all now in place. There is a VPN between the routers passing IP packets, using encryption and not encapsulation.
Thanks.

5 replies

by mckaytech

A couple of observations: SQL is very CPU and RAM intensive but a badly written front end can really aggravate that by using inefficient queries and that can, in turn, can a lot of unnecessary WAN traffic.

As far as the DSL link, it would be interesting to know what your CIR (committed information rate) is because that is all you're guaranteed to get. On a 1.5meg DSL, I've heard of CIR as low as 128k. But in this case, I don't have the sense that the WAN is the problem.

I have tremendous regard for Terminal Services over a WAN link and think it works well in most cases (it generally only consumes 9-15k of bandwidth per user, in my experience) so it would easily support all your users over the WAN link. BUT... if you have an application that redlines your CPU and RAM with one user, it is going to get much, much worse in a Terminal Services environment. Our minimum Terminal Services box is a dual-CPU with 4gig of RAM and with that we can support 25-50 concurrent users depending on the efficiency of the application. But I've even seen our servers pulled down to nothing by a single user running an inefficient application.

I think the first thing I would do is get some measure of traffic on your WAN and see if you're anywhere near your CIR. Then I would really take a close look at the application and the queries it is generating.

paul

by mark.thomson

If your Access front end is pre Access 2000 then there is a good chance that it will be a bandwidth hog (even on your LAN), moving to a thin client environment should improve your remote users' SQL Server performance up to the level of your local users. Throwing extra RAM at SQL server is one of the best ways to improve performance and is currently very cheap, we have just maxed out a Dell Poweredge (1gb) for 150GBP.
You will probably need to upgrade to the full version of Back Office with the increased number of users you are quoting (SBS tops out at 50 concurrent users)

This discussion is closed to new replies.