2011-07-04 21 views
6

Gần đây, khách hàng của chúng tôi đã bắt đầu phàn nàn về hiệu suất kém trên một trong các máy chủ của chúng tôi. Điều này chứa nhiều triển khai CMS lớn và rất nhiều trang web nhỏ sử dụng Sitefinity. Nhóm Hosting của chúng tôi hiện đang cố gắng tìm ra các tắc nghẽn trong môi trường của chúng tôi, vì có một số vấn đề lớn với thời gian tải. Tôi đã được giao nhiệm vụ chỉ định một danh sách lớn những thứ cần tìm kiếm, được chia thành các phần khác nhau (IIS, ASP.NET, Web cụ thể). Tôi nghĩ sẽ tốt hơn khi tìm hiểu xem có bao nhiêu phiên bản CMS Sitecore chúng tôi có thể chạy trên một máy chủ theo tài liệu của Sitecore e.d. Chúng tôi muốn có thể theo dõi và tìm ra nơi mà nút cổ chai của chúng tôi là vào thời điểm này. Một số trang web của chúng tôi tải rất chậm, các trang web khác tải rất nhanh. Hầu hết các triển khai Sitecore của chúng tôi chạy trên máy chủ này có hiệu năng back-end kém và có thời gian tải khủng khiếp sau khi biên dịch. Giải pháp Sitecore của chúng tôi chạy trên máy chủ Win 2008 64 với Microsoft SQL Server 2008 dành cho db. Tôi hiểu rằng có thể thuận tiện để chỉ định thông tin chi tiết hơn về thiết lập của chúng tôi, nhưng tôi hy vọng chúng tôi có thể nhận được một số thông tin cơ bản hữu ích về cách theo dõi và tìm thấy tắc nghẽn e.d.Danh sách kiểm tra cho hiệu năng ASP.NET/Cơ sở dữ liệu

Công cụ/gợi ý/mẹo nào & các mẹo bạn có?

+0

Hầu hết người dùng của bạn sử dụng khoảng 15% những gì Sitecore hoặc Sitefinity cung cấp đây là lý do bạn không nên lưu trữ các ứng dụng web lớn đó. Đây là lý do tại sao họ biên dịch chậm. Bạn nên kiểm tra xem có mối quan hệ giữa thời gian biên dịch và yêu cầu được thực hiện cho cùng một ứng dụng hay không. – eugeneK

+0

Ý bạn là gì khi sử dụng khoảng 15% những gì Sitecore cung cấp? Không có mối liên quan giữa thời gian biên soạn và các yêu cầu được thực hiện cho cùng một ứng dụng. Tôi nghĩ rằng tôi biết bạn đang đi đâu, nhưng chúng tôi sử dụng các dịch vụ Keep còn sống để ngăn ứng dụng web chuyển sang chế độ ngủ. Ứng dụng không được biên dịch trên cơ sở thường xuyên. – Younes

Trả lời

5
  • do KHÔNG sử dụng quá nhiều hồ bơi asp.net khác nhau, được gọi và dành riêng cho bể bơi. Đặt thêm các trang web trên cùng một hồ bơi.
  • Thêm bộ nhớ, hoặc ngừng không sử dụng các chương trình/dịch vụ trên máy chủ
  • Kiểm tra nếu bạn có bộ nhớ giới hạn về hồ bơi ứng dụng mà làm cho hồ bơi tiếp tục tự động khởi động lại.
  • Trên cơ sở dữ liệu, hãy đặt Chế độ khôi phục thành đơn giản.
  • file cơ sở dữ liệu Shrink, và cơ sở dữ liệu reindex, từ bên trong chương trình
  • sau tất cả những gì Defrag đĩa của bạn

Kiểm tra bộ nhớ với process explorer.
Để kiểm tra những gì bắt đầu bằng máy chủ của bạn, hãy sử dụng autoruns nhưng hãy cẩn thận để không dừng bất kỳ dịch vụ quan trọng nào và máy tính không bao giờ bắt đầu lại. Không ngừng các dịch vụ từ tự động chạy, sử dụng trình quản lý dịch vụ để thay đổi loại thành thủ công. Ngoài ra nhiều dịch vụ phục vụ sql họ không cần phải chạy nếu bạn không bao giờ sử dụng chúng.

Một số mẹo khác

  • Move các tập tin tạm thời/và có thể asp.net xây dựng thư mục vào một đĩa khác nhau
  • Xóa tất cả các file từ thư mục tạm thời (cd% temp%)

Hãy chắc chắn rằng bộ nhớ vật lý miễn phí không phải là số không, bằng cách sử dụng quá trình exporer. Nếu nó gần bằng không, thì máy chủ của bạn cần bộ nhớ, hoặc cần dừng các chương trình không sử dụng để chạy.

Để đặt nhiều trang web trong cùng một hồ bơi, bạn cần phải thay đổi quyền của các trang web trong nhóm chia sẻ mới. Nó không khó, chỉ mất một thời gian và tổ chức để biết những gì trang web chạy theo những gì hồ bơi. Bây giờ hãy nói rằng bạn có 10 trang web, tốt hơn nên sử dụng 2 hồ bơi khác nhau và phát tán các trang web trên cơ sở hồ bơi này trên tải trọng của mỗi trang web.

1

Không thể nói cho Sitefinity, nhưng sẽ đi kèm với một số mẹo cho Sitecore.

  • Sử dụng bộ nhớ đệm Sitecores bất cứ khi nào có thể, đặc biệt. trên XSLTs (vì chúng có xu hướng đơn giản hơn bố trí & sublayouts và do đó Sitecore caching không phá vỡ chúng, như Sitecore caching không để asp.net postbacks), điều này sẽ chỉ giúp nếu rederings & sublayouts vv được truy cập rất nhiều. sử dụng /sitecore/admin/stats.aspx?site=website để kiểm tra nội dung không được lưu trong bộ nhớ cache
  • Sử dụng sơ đồ Sitecores, mở một mục trong hồ sơ và xem các lớp con nào vv đang dành thời gian
  • Chỉ sử dụng XSLT cho các nội dung đơn giản nhất, nếu nó trở nên phức tạp hơn và tôi sẽ đi cho sublayouts (điều khiển asp.net), đây là một chút thiên vị như tôi không thích XSLT, nhưng kinh nghiệm chỉ ra rằng .ascx là nhanh hơn
  • sử dụng Nội dung của IIS hết hạn trên các tệp tĩnh (prob tất cả/sitecore và nếu bạn có một số hình ảnh, javascript & tệp CSS), đây là dành cho IIS 6: msdn link
  • Kiểm tra thời gian truy cập cơ sở dữ liệu với Sitecore Databasetest.aspx (o ne cho Sitecore 6 là tốt hơn rất nhiều so với cái đơn giản mà hoạt động trên Sitecore 5 & 6) Sitecore SDN link

Và đó là những gì tôi có thể nghĩ ra từ đỉnh đầu của tôi.

2

Không có câu trả lời ngay lập tức để điều chỉnh hiệu suất Sitecore. Nhưng đây là một số mẹo quan trọng:

1) CACHING

Caching là mọi thứ. Các tham số bộ nhớ cache Sitecore mặc định hiếm khi chính xác cho bất kỳ ứng dụng nào. Nếu bạn có rất nhiều bộ nhớ, bạn nên tăng kích thước bộ nhớ cache:

http://learnsitecore.cmsuniverse.net/en/Developers/Articles/2009/07/CachingOverview.aspx

http://sitecorebasics.wordpress.com/2011/03/05/sitecore-caching/

http://blog.wojciech.org/?p=9

Thật không may đây là điều mà các nhà phát triển cần phải nhận thức khi triển khai cài đặt, không phải cái gì quản trị viên hệ thống nên quan tâm đến ...

2) DATABASE

Cơ sở dữ liệu là nút cổ chai cuối cùng để kiểm tra. Tôi hiếm khi chạm vào cơ sở dữ liệu. Tuy nhiên, việc thực hiện DB có thể được tăng lên với các thiết lập thích hợp:

thuộc tính cơ sở dữ liệu để cải thiện hiệu suất:

http://www.theclientview.net/?p=162

Bài viết này trên phân mảnh chỉ số này rất hữu ích:

http://www.theclientview.net/?p=40

1

Sitecore có lỗ hổng lớn, sử dụng của nó HƯỚNG DẪN cho các khóa chính (trong số các kiểu dữ liệu kém được lựa chọn khác), điều này sẽ phân đoạn bảng từ lần chèn đầu tiên và nếu bạn có cơ sở dữ liệu Sitecore được sử dụng nhiều, phân đoạn có thể lớn hơn 90% trong vòng một giờ.Đây không phải là một cơ sở dữ liệu được thiết kế tốt và khuyên bạn nên xem xét các sản phẩm khác cho đến khi chúng khắc phục được điều này, nó đang khiến chúng tôi đau đầu về hiệu năng (thời gian và tiền bạc). Chúng tôi đang ở trạng thái chờ, chúng tôi không thể thêm nữa RAM không thể xây dựng lại các chỉ mục thường xuyên hơn

0

Ngoài ra, đặt IIS của bạn để tái chế app_pool CHỈ mỗi ngày một lần vào một thời điểm cụ thể. Tôi thường đặt tôi vào 3 giờ sáng. Bằng cách này, các ứng dụng không bao giờ đi vào giấc ngủ, tái chế hoặc vv. Tốt nhất để giảm thời gian quay lên.

Ngoài ra, định cấu hình IIS thành 'luôn chạy' thay vì 'khi khởi động'. Bằng cách này, khi các ứng dụng khởi động lại, nó biên dịch lại ngay lập tức và một lần nữa, đã sẵn sàng để gầm lên.

Sitefinity thực sự là một phần mềm tuyệt vời (hy vọng các mẹo của tôi ở trên không nhận được dấu hiệu và không chứng thực sản phẩm của tôi). haha

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