2010-11-13 6 views
16

Tôi đang tăng kích cỡ ứng dụng MS Access 2003 lên chương trình phụ trợ SQL Server. Trên máy tính dev của tôi, SQL Server là cục bộ, do đó hiệu năng khá tốt. Tôi muốn kiểm tra hiệu suất với một máy chủ SQL từ xa để tôi có thể giải thích hiệu ứng của độ trễ mạng khi tôi thiết kế lại ứng dụng. Tôi hy vọng rằng một số truy vấn có vẻ nhanh chóng hiện sẽ chạy khá chậm khi được triển khai để sản xuất.Tôi làm cách nào để mô phỏng độ trễ mạng trên máy phát triển của mình?

Làm thế nào tôi có thể làm chậm (hoặc mô phỏng tốc độ của từ xa) SQL Server mà không cần sử dụng máy ảo hoặc chuyển SQL sang máy tính khác? Có một số loại proxy hoặc Windows tiện ích mà sẽ làm điều này cho tôi?

+1

Chỉ cần viết ứng dụng của bạn để có hiệu quả trong việc truy xuất dữ liệu, tức là, không bao giờ truy xuất nhiều hơn nhu cầu của người dùng hoặc có thể làm việc cùng một lúc. Điều này sẽ hiệu quả trong bất kỳ môi trường nào, bao gồm cả kết thúc Jet/ACE. Không có gì kỳ diệu về nó. Trường hợp duy nhất mà bạn có thể gặp phải trường hợp cạnh là nếu bạn đang lập kế hoạch chạy trên Internet mở, với băng thông tương đối rất thấp ở đó (so với mạng LAN). Trong trường hợp đó, bạn có thể làm nhiều hơn, nhưng tôi khuyên bạn nên chống lại việc tối ưu hóa sớm - làm cho nó hiệu quả và sau đó sửa những gì không đủ nhanh. –

+0

@David: Tôi đang chuyển một ứng dụng MS ACcess hiện có rất lớn. Tôi cần phải chiến lược trong những thay đổi mà tôi thực hiện, không có thời gian hoặc ngân sách để sửa đổi mọi truy vấn và nguồn dữ liệu. – RedFilter

+0

Tôi thậm chí không bắt đầu đề nghị sửa đổi mọi thứ. Nếu đó là một ứng dụng Access được thiết kế tốt, nó có thể sẽ hoạt động rất tốt. Nếu không, nó sẽ đòi hỏi rất nhiều công việc. Nguyên tắc truy xuất chỉ một số lượng hạn chế các bản ghi làm cho một ứng dụng nhanh chóng, hiệu quả không có vấn đề nếu kết thúc trở lại là Jet/ACE hoặc một cơ sở dữ liệu máy chủ. –

Trả lời

5

tôi đã không sử dụng nó bản thân mình, nhưng đây là một câu hỏi SO:

Trong một trong những ý kiến ​​SQL Server đã được đề cập một cách rõ ràng.

+0

Cảm ơn bạn đã liên kết. –

0

Bạn có thể đang hoạt động dưới một quan niệm sai lầm. MS-Access hỗ trợ cái gọi là "các kết nối không đồng nhất" (tức là các bảng từ nhiều back-end có thể được bao gồm trong cùng một truy vấn, ví dụ: kết hợp dữ liệu từ Oracle và SQLServer và Access và bảng tính Excel). Để hỗ trợ tính năng này, Access áp dụng bộ lọc WHERE khoản tại ứng dụng khách ngoại trừ trong trường hợp có truy vấn "chuyển tiếp" đối với một back-end thông minh. Trong SQL Server, việc lọc xảy ra trong công cụ đang chạy trên máy chủ, vì vậy SQL Server thường gửi các bộ dữ liệu nhỏ hơn nhiều cho máy khách.

Câu trả lời cho câu hỏi của bạn cũng phụ thuộc vào ý bạn là "từ xa". Nếu bạn pit Access và SQL Server với nhau trên cùng một mạng, SQL Server chạy trên máy chủ sẽ chỉ tiêu tốn một phần nhỏ băng thông mà Access thực hiện, nếu tệp MDB Access nằm trên một máy chủ tệp. (Tất nhiên nếu MDB nằm trên PC cục bộ, không có băng thông mạng được tiêu thụ.) Nếu bạn so sánh Truy cập trên LAN so với SQL Server qua băng thông rộng qua đám mây, thì bạn so sánh một đường ống danh nghĩa 100 mbit/giây với DSL hoặc băng thông cáp, tức là chống lại có lẽ 20 mbit/sec danh nghĩa cho cáp tốc độ cao, một phần năm của băng thông ở mức tốt nhất, có lẽ ít hơn nhiều.

Vì vậy, bạn phải cụ thể hơn về những gì bạn đang cố gắng so sánh. Bạn có so sánh các máy khách Access trên máy tính cục bộ tiêu thụ một MDB truy cập cư trú trên máy chủ tệp đối với một số loại dữ liệu khách hàng khác tiêu thụ từ một máy chủ SQL đang cư trú trên một máy chủ khác trên cùng một mạng không? Không. Bạn sẽ tiếp tục sử dụng Access làm ứng dụng khách? Truy vấn của bạn có được truyền qua không?

+0

@Thời gian: Đoạn đầu tiên của bạn không chính xác. Mệnh đề 'WHERE' của các truy vấn không đối nghịch của tôi đối với SQL Server đang được chạy trên SQL Server trong trường hợp không có các từ khóa Access-specific được sử dụng. Đoạn thứ hai của bạn cũng không chính xác: đối với các truy vấn chạy từ Access với SQL Server, băng thông ít được tiêu thụ chỉ trong trường hợp mệnh đề 'JOIN' và' WHERE' có thể chạy trên SQL Server vì không có từ khóa Access = specific, như 'IIF'. Nếu có từ khóa truy cập cụ thể, toàn bộ tập dữ liệu được kéo xuống Access để có thể chạy các từ khóa ở đó. – RedFilter

+0

Liệu tập dữ liệu đầy đủ có được kéo xuống hay không phụ thuộc vào các chức năng truy cập cụ thể được sử dụng.Trong mệnh đề SELECT, nó không có nhiều vấn đề, vì tất cả các tiêu chí WHERE và JOIN sẽ được thực hiện trên máy chủ, và sau đó các hàm được xử lý trong SELECT chỉ trên resultset đã lọc. Nhưng nếu bạn sử dụng các hàm Access-specific trong mệnh đề WHERE hoặc JOIN hoặc ORDER BY, bạn có thể hoặc không kéo xuống toàn bộ bảng - phụ thuộc vào việc Jet/ACE có thể tìm ra cách tách riêng các yếu tố hạn chế nhất định trước Access hay không chức năng cụ thể. –

+0

@ David: vâng, đây là một điểm quan trọng. – RedFilter

0

Có một ứng dụng phần mềm cho Windows thực hiện điều đó (mô phỏng băng thông thấp, độ trễ và tổn thất nếu cần). Nó không miễn phí mặc dù. Phiên bản dùng thử có giới hạn mô phỏng 30 giây. Đây là trang chủ của sản phẩm đó: http://softperfect.com/products/connectionemulator/

0

@RedFilter: Bạn nên chỉ định phiên bản Access bạn đang sử dụng. Tài liệu này từ năm 2006 cho thấy rằng câu chuyện về những gì Access mang đến cho khách hàng trên toàn bộ dây phức tạp hơn liệu truy vấn có chứa "Từ khóa truy cập cụ thể" hay không.

http://msdn.microsoft.com/en-us/library/bb188204(SQL.90).aspx

Nhưng truy cập có thể nhận được nhiều hơn và phức tạp hơn về việc sử dụng tài nguyên máy chủ với mỗi phiên bản mới hơn.

tôi sẽ đứng bởi những lời khuyên đơn giản của tôi: nếu bạn muốn giảm thiểu tiêu thụ băng thông, trong khi vẫn sử dụng truy cập như GUI, pass-through truy vấn cố gắng hết sức, bởi vì sau đó nó là bạn, chứ không phải Access, người sẽ kiểm soát lượng dữ liệu đi xuống dây.

Tôi vẫn nghĩ câu hỏi/cách tiếp cận ban đầu của bạn là sai lầm: nếu tệp Access MDB của bạn được đặt trên mạng LAN ở nơi đầu tiên (phải không?) Bạn không cần mô phỏng ảnh hưởng của độ trễ mạng. Bạn cần xem xét các câu lệnh SQL Access tạo ra, thay vì giới thiệu một số yếu tố "độ trễ mạng" tùy ý và không đổi. Để so sánh một GUI truy cập bằng MDB nằm trên một máy chủ LAN chống lại một giao diện người dùng truy cập tăng lên chống lại một máy chủ SQL back-end, bạn cần phải đánh giá những gì truy cập dữ liệu xuống trên dây cho khách hàng từ máy chủ back-end. Truy cập "upsized" thậm chí có thể là một con heo ở máng băng thông trừ khi bạn sử dụng các truy vấn pass-through. Nhưng một client được viết đúng cho một back-end SQL-Server sẽ luôn phân tích nhiều hơn với băng thông mạng hơn Access truy cập vào MDB nằm trên một máy chủ LAN, ceteris paribus.

+0

MDB truy cập hiện tại back-end hiện có trên mạng LAN. Tôi hiện đang tìm kiếm các truy vấn. Phiên bản Truy cập là năm 2003. Điều đáng nói là các truy vấn chuyển tiếp là chỉ đọc và ngoài ra, một số truy vấn của tôi yêu cầu tham số đầu vào. Ý kiến ​​của tôi là cách nhanh nhất để xác định những tắc nghẽn nào cần được cố định là làm như vậy theo kinh nghiệm. – RedFilter