2011-11-01 25 views
9

Tôi đang xây dựng trang web cho công việc và một trong những tính năng quan trọng hơn là lưới nội dung đa phương tiện hiển thị dữ liệu. Theo mặc định, nó chỉ hiển thị 20 mục trên mỗi trang, nhưng chúng tôi có ~ 200 mục trong cơ sở dữ liệu có thể được lọc, sắp xếp và tìm kiếm.Một số phương pháp hay nhất cho tương tác giữa khách hàng và máy chủ là gì?

Nhóm bán hàng và tiếp thị của chúng tôi cũng yêu cầu tính năng "liệt kê tất cả" để họ có thể hiển thị tất cả dữ liệu ở một nơi và cuộn qua chứ không phải trang thông qua dữ liệu.

Flexigrid data

toàn bộ hệ thống này được xây dựng sử dụng ASP.Net MVC ở phía máy chủ, jQuery và Flexigrid về phía khách hàng, và sử dụng JSON để trao đổi dữ liệu giữa hai qua AJAX.

Tôi đã nhận được phần chuyển dữ liệu thực sự khá chắc chắn. Một trang gồm 20 kết quả cần 800ms cho toàn bộ yêu cầu (POST một yêu cầu tới máy chủ qua Flexigrid và nhận phản hồi). Đó là quá trình xử lý phía máy khách mất nhiều thời gian.

Tôi có thể giảm tải một số xử lý phía máy khách cho máy chủ. Nhưng điều này sẽ làm cho hoạt động phía máy chủ mất nhiều thời gian hơn và làm cho kích thước của tài liệu trở lại lớn hơn nhiều. Không phải là vấn đề trong các tình huống có kết nối Internet tốc độ cao ... nhưng điều đó không nhất thiết phải xảy ra.

Tùy chọn khác mà tôi có là tải xuống càng nhiều dữ liệu càng tốt và thay đổi phần lớn xử lý dữ liệu cho khách hàng. Điều này làm giảm thời gian yêu cầu xuống về cơ bản không (chỉ tìm nạp các phần tử thay đổi thay vì toàn bộ tập dữ liệu). Nó sẽ hoạt động khá tốt trên các máy có CPU nhanh và nhiều RAM, nhưng đó cũng không nhất thiết phải là trường hợp.

Kể từ ít nhất một người gắn cờ này là "không phải là một câu hỏi thực sự," hãy để tôi làm rõ ...

  • Những gì tôi có thể có thể làm gì để giảm bớt các vấn đề thời gian xử lý client-side, không nhúc nhích quá nhiều xử lý đến máy chủ mà tôi kết thúc với một vấn đề thời gian truyền dữ liệu?
  • Một số phương pháp hay nhất khi cân bằng xử lý phía máy khách với xử lý phía máy chủ là gì?
  • Có tốt hơn khi gặp lỗi ở phía máy chủ hoặc ứng dụng khách không?
  • Tôi có thể sử dụng một số công cụ nào để tối ưu hóa tốt hơn các trao đổi này để mọi thứ không tiếp tục bị xáo trộn?

Trả lời

2

Bạn đang xử lý ở phía khách hàng mất quá nhiều thời gian? Việc xử lý một đối tượng JSON (thậm chí là một đối tượng rất lớn) không nên quá chuyên sâu.

Rất nhiều lần tra cứu DOM khi viết phía máy khách dữ liệu của bạn có thể làm chậm mọi thứ. Việc giảm tra cứu DOM có thể giúp hiệu suất rất nhiều. Tôi tin rằng thực hành tốt để cân bằng máy chủ & xử lý phía máy khách là lỗi trên máy chủ. Vì máy chủ nằm dưới sự kiểm soát của bạn nên bạn luôn có thể chọn nâng cấp máy chủ của mình. Việc giữ phần lớn quy trình xử lý trên máy chủ cũng sẽ giúp mọi thứ dễ dàng hơn cho các thiết bị di động và máy tính cũ hơn.

Bạn nên sử dụng AJAX & khả năng của ứng dụng khách theo cách nâng cao trải nghiệm người dùng. Tải và xử lý dữ liệu theo yêu cầu của người dùng. Bằng cách tải chỉ những gì họ yêu cầu bạn có thể giảm tải trên máy chủ của bạn & khách hàng.

Nếu bạn cũng yêu cầu cùng một loại dữ liệu lặp đi lặp lại, bạn có thể xem cả hai máy chủ & lưu vào bộ đệm phía máy khách. Bằng cách sử dụng bộ nhớ đệm, bạn có thể giảm thời gian yêu cầu và/hoặc băng thông.

+0

Máy chủ gửi đối tượng JSON cho khách hàng. Đối tượng JSON sau đó được nạp vào Flexigrid. Flexigrid tự đọc đối tượng vào một bảng, sau đó thực hiện một số hoạt động 'document.createElement()' đắt tiền để định dạng bảng để hiển thị. Nó chuyển đổi đối tượng thành một bảng HTML rất chuyên sâu. – EAMann

+0

Cũng đọc phản hồi chi tiết của tôi bên dưới ... – EAMann

1

Khi nó quay ra, vấn đề là nhiều hơn với các công cụ JavaScript ở phía khách hàng hơn so với dữ liệu tôi đang làm việc. Tôi đã dành phần lớn thời gian chuẩn bị cho quá trình và thời gian hoạt động khác nhau.

Mọi thứ đều chạy nhanh trong Chrome. Mọi thứ đều chạy khá nhanh (không nghĩ nhanh như Chrome) trong Firefox. Độ trễ hiệu năng thực sự là Internet Explorer.

Khi tôi tải toàn bộ tập dữ liệu - tất cả 200 hàng - Flexigrid cố gắng thực hiện một số chế biến sau trên mọi ô trong bảng. Như bạn có thể thấy trong ảnh chụp màn hình, mỗi hàng có 29 ô ... vì vậy chúng tôi đang xem xét một loạt các hoạt động định dạng tổng cộng 5800 lần.

Tôi có thể kéo một số hoạt động đắt hơn (tức là tạo đối tượng jQuery) ra khỏi vòng lặp cấp thấp hơn để chúng chỉ chạy một lần cho mỗi hàng, nhưng cuối cùng tôi vẫn chạy vào IE vấn đề hiệu năng.

Để cung cấp cho bạn một số tiêu chuẩn thực tế, tôi đặt mã để nhổ ra tổng thời gian trước khi nó chạm sự kiện nhất định:

  • populate cháy khi trình duyệt đầu tiên gửi đi những yêu cầu XHR
  • addData cháy sau khi yêu cầu đã trở lại và trước khi đối tượng JSON được phân tích cú pháp
  • addCellProp kích hoạt sau khi phân tích cú pháp dữ liệu ban đầu và lặp qua từng ô trong bảng
  • .210 cháy khi mọi thứ được finsihed

chế biến 20 dòng dữ liệu (mặc định):

------------------------------------------------------ 
| browser | populate | addData | addCellProp | done | 
------------------------------------------------------ 
| Chrome | 0  | 84  | 123   | 286 | 
| IE9  | 0  | 151  | 309   | 799 | 
| IE8  | 0  | 226  | 481   | 1105 | 

Chế biến các thiết lập đầy đủ dữ liệu (179 hàng trên máy tính này):

------------------------------------------------------ 
| browser | populate | addData | addCellProp | done | 
------------------------------------------------------ 
| Chrome | 0  | 318  | 669   | 1963 | 
| IE9  | 0  | 157  | 1813  | 9428 | 
| IE8  | 0  | 229  | 2188  | 13335 | 

Nhất hoạt động tốn kém là giữa addCellPropdone. Tôi đã trải qua và làm cho mã hiệu quả nhất có thể, nhưng chỉ có quá nhiều bạn có thể làm khi bạn đang chạy qua nhiều lần lặp lại của một tập dữ liệu, đặc biệt khi thao tác DOM.

Tôi đã sửa đổi Flexigrid (mặc dù nhiều đề xuất không) để chạm vào DOM càng ít càng tốt và điều đó thực sự đã thúc đẩy mọi thứ lên một chút. Khi tôi bắt đầu nghiên cứu này, IE9 sẽ mất từ ​​20 đến 30 giây để đạt được sự kiện done.

Sự thật không may ở đây là không phải tất cả nền tảng đều được tạo bằng nhau và IE dường như không phải là công cụ tốt nhất để làm việc với dữ liệu trong màn hình theo cách này.

Cách tiếp cận tốt hơn có thể là tạo và thao tác bảng HTML ở phía máy chủ và gửi toàn bộ nội dung (đánh dấu và tất cả) tới trình duyệt khi được yêu cầu cho người dùng IE thay vì tùy thuộc vào IE để tạo đánh dấu Đối tượng JSON.

+0

Việc đánh giá trình duyệt chéo cho mỗi sự kiện thực sự mang tính thông tin. Nó thực sự giúp cho vay rõ ràng đến gốc rễ của vấn đề. Định dạng phía máy chủ cho người dùng IE giống như một ý tưởng vững chắc. –

+0

Tôi đã đi qua và viết lại những thứ để toàn bộ bảng được gửi trong yêu cầu AJAX. Trong hệ thống ban đầu, chỉ có dữ liệu được gửi và JS đã được sử dụng để xử lý nó và điền vào một bảng. Một mặt, tôi hiện đang gửi thông tin 10x trong phản hồi XHR. Mặt khác, trang tải nhanh gấp 10 lần trong IE. – EAMann

0

Tôi có thể làm gì để giảm bớt các vấn đề thời gian xử lý phía máy khách mà không cần di chuyển quá nhiều đến máy chủ mà tôi kết thúc với một vấn đề thời gian truyền dữ liệu?

Dữ liệu có nằm trong cơ sở dữ liệu không? Nếu hạn chế dữ liệu ở đó. Đây là những gì db là tốt. Tôi sử dụng flexigrid và giữ tất cả phân loại phân trang và lọc ở đó. Db chỉ trả về dữ liệu cần thiết được sắp xếp và lọc theo yêu cầu. Tất cả các máy chủ phải làm là trả lại nó và tất cả các khách hàng đã làm là render nó.

Một số phương pháp hay nhất khi cân bằng xử lý phía máy khách với xử lý phía máy chủ là gì?

Giữ ánh sáng phía khách hàng nhất có thể

Tốt hơn là bạn nên đặt ở bên cạnh máy chủ hoặc máy khách?

Có máy chủ có quyền lực nhiều hơn nữa

gì một số công cụ tôi có thể sử dụng để tối ưu hóa tốt hơn những trao đổi để mọi thứ không tiếp tục đi xiên?

Công cụ dành cho nhà phát triển IE sử dụng tab mạng để xem những gì sắp tới trên dây

+0

Đó không phải là vấn đề. Phân trang, sắp xếp và lọc * là * tất cả được thực hiện trên máy chủ. Nhưng khi tập dữ liệu là hơn 200 hàng của 30 cột trở lên, hiển thị phía máy khách sẽ làm chậm * đáng kể * trên IE. Nó có rất nhiều việc phải làm với các trình xử lý sự kiện kém mã hóa trong Flexigrid, không quá nhiều dữ liệu. – EAMann

+0

Nếu dữ liệu bị hạn chế phía máy chủ thì khách hàng sẽ không bao giờ nhận được một tập dữ liệu lớn như vậy. ví dụ. khách hàng sẽ chỉ nhận được một trang dữ liệu. Khi người dùng nhấp vào trang tiếp theo, các cuộc gọi linh hoạt sẽ quay trở lại máy chủ và truy cập trang tiếp theo. Trừ khi bạn muốn hiển thị hơn 200 hàng trên một trang ??? –

+0

Phân trang được thiết lập theo mặc định để giới hạn ở 5, 10, 15 hoặc 20 kết quả trên một trang. Nhưng như tôi đã gọi trong câu hỏi ban đầu, nhóm bán hàng/tiếp thị đặc biệt yêu cầu tùy chọn "xem tất cả" để hiển thị tất cả dữ liệu trên một trang. Đó là hiệu suất khi thực hiện "xem tất cả" mà tôi đã cố gắng gỡ lỗi. – EAMann

Các vấn đề liên quan