Tôi kết hợp một trang web D7 với một tiểu nhóm Minelli. Trên đường đi, tôi đã thử nghiệm rất nhiều với các chủ đề khác nhau, các mô-đun khác nhau. Ở đâu đó, tôi đã phát triển một vấn đề hiệu năng kỳ lạ và bây giờ tôi không thực sự biết chủ đề / mô-đun / cấu hình nào gây ra vấn đề đó.

Vấn đề là khi tôi lần đầu tiên truy cập trang web, phải mất khoảng 15 giây trước khi trang đầu tiên hiển thị. Sau đó tôi có thể di chuyển xung quanh trang web và nó rất nhạy. Nếu tôi để nó trong một giờ hoặc lâu hơn, sau đó quay lại với nó, yêu cầu đầu tiên lại rất chậm.

Tôi đã xóa bộ nhớ cache để không phải là vấn đề. Ngoài ra, tôi đã vô hiệu hóa các chủ đề và mô-đun mà tôi không sử dụng. Tôi đã chuyển trang web sang cơ sở hạ tầng mới nhưng vấn đề theo nó!

Tôi sẽ đi đâu tiếp theo?

Có ba điều mà tôi sẽ kiểm tra.

Thứ nhất, nếu bạn đang ở trên một trang sản xuất và không chỉnh sửa các tệp PHP, thì bạn nên đảm bảo rằng APC đã được bật, có đủ bộ nhớ và có một TTL dài (bạn có thể đi cùng một ngày hoặc không bao giờ hết hạn nếu bạn muốn). Bạn cũng có thể xem xét cài đặt apc.stat=0. Các tài liệu APC có tất cả thông tin bạn cần để thiết lập TTL. Để chọn dung lượng bộ nhớ, bạn nên dán tệp apc.php ở đâu đó được bảo vệ và theo dõi việc sử dụng bộ nhớ và thống kê khuấy. Điều chỉnh bộ nhớ APC để tỷ lệ bỏ lỡ của bạn rất thấp. Sự chậm chạp ban đầu có thể là do APC đã đầy và hết (IIRC, APC bỏ toàn bộ bộ đệm khi nó đầy thay vì sử dụng LRU hoặc các chiến lược bộ đệm nâng cao hơn).

Thứ hai, hãy chắc chắn rằng bạn đã điều chỉnh MySQL một cách thích hợp. Bạn có thể sử dụng mysqltuner để điều chỉnh kích thước bộ đệm của mình. Sự chậm chạp ban đầu của bạn có thể là do tải bảng từ đĩa và / hoặc bộ nhớ cache truy vấn bị mất. Mặc dù không hoàn hảo, mysqltuner sẽ giúp bạn đi đúng hướng.

Thứ ba, hãy chắc chắn rằng bạn có một chiến lược định kỳ Drupal thực sự . Cá nhân, tôi sẽ vô hiệu hóa cron tự động trên "admin / config / system / cron" và thiết lập một crontab để chạy mỗi đêm. Bạn cũng có thể dùng thử Elysia Cron nếu bạn thực sự cần kiểm soát chi tiết hơn đối với mọi thứ. Bằng cách này, bạn có thể thực hiện các tác vụ cần thiết chạy thường xuyên khi bạn cần, nhưng để các tác vụ bình thường chạy qua đêm. Sự chậm chạp ban đầu của bạn có thể là từ việc chạy cron xảy ra mỗi giờ. Bạn có thể xác nhận điều này bằng cách xem xét khi cron chạy trên "admin / báo cáo / dblog" và cố gắng khớp với sự chậm chạp của bạn.

Ivanhoe123 có lẽ đúng: Drupal 7 đi kèm với 'mans cans nghèo' được bật theo mặc định. Nói tóm lại, điều đó có nghĩa là cron (thỉnh thoảng) được chạy trước khi Drupal kết xuất lại trang, trì hoãn mọi thứ.

Luôn cố gắng sử dụng một công việc định kỳ thực sự trên các trang web sản xuất. Để biết thêm chi tiết kỹ thuật, hãy xem http://drupal.org/cron hoặc nói chuyện với công ty lưu trữ của bạn.

Để tắt nó, hãy truy cập admin / config / system / cron và chọn 'Never'.

Các Devel mô-đun cung cấp cơ sở dữ liệu khai thác gỗ để kiểm tra xem bạn có bất cứ thắc mắc dài chạy.

Nếu điều này không giúp lấy XHProf hoặc XDebug và tìm mã có tội. XHProf (một trình lược tả) vẽ cho bạn một bản đồ đẹp về tất cả các chức năng đang được thực thi trên máy chủ và nó cho bạn biết những chức năng nào đang tiêu tốn nhiều thời gian thực hiện nhất. Mặt khác, khi XDebug (trình gỡ lỗi) được cấu hình với IDE như Eclipse ( xem video ), nó cho phép bạn đi sâu vào mọi chức năng đang được thực thi TRỰC TIẾP. Trình hồ sơ sẽ cho bạn một ý tưởng về những gì đang được thực hiện; trong khi trình gỡ lỗi sẽ cho bạn thấy tại sao nó được thực thi.

Chỉ từ hương vị của câu hỏi, tôi nghĩ ngay đến ba (3) điều

• Công cụ lưu trữ MySQL / CPU
• Bộ nhớ đệm cơ sở dữ liệu
• Khóa bảng

Công cụ lưu trữ MySQL

Nếu bạn không sử dụng bất kỳ tìm kiếm / lập chỉ mục FULLTEXT nào, tôi thực sự khuyên bạn nên chuyển đổi tất cả dữ liệu MyISAM của mình sang InnoDB. MyISAM không được thiết kế để tận dụng nhiều CPU và nhiều lõi. InnoDB đã được tăng cường đáng kể cho việc sử dụng nhiều CPU cũng như đọc / ghi siêu phân luồng.

Dưới đây là một số bài đăng tôi đã thực hiện về điều này trong DBA StackExchange và trong trang web này liên quan đến việc điều chỉnh MySQL cho Hiệu suất InnoDB

• Sep 20, 2011: Đa lõi và hiệu suất MySQL
• Sep 12, 2011: Có thể khiến MySQL sử dụng nhiều hơn một lõi
• Jun 07, 2011: Làm cách nào để chuyển đổi cơ sở dữ liệu từ MyISAM sang InnoDB?
• May 26, 2011: Giới thiệu về hiệu suất cơ sở dữ liệu đa luồng so với đa luồng
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367

Bộ nhớ đệm cơ sở dữ liệu

Một lập luận mạnh mẽ khác để chuyển đổi tất cả dữ liệu MyISAM sang InnoDB là cách MySQL lưu trữ dữ liệu / chỉ mục. MyISAM Storage Engine chỉ lưu trữ các chỉ mục. InnoDB lưu trữ dữ liệu và chỉ mục . Để giải quyết vấn đề này, bạn có thể phân bổ đủ bộ nhớ cho Nhóm đệm InnoDB để chứa một trong những điều sau đây (tùy theo mức nào nhỏ hơn)

• Tất cả Dữ liệu và Chỉ mục của InnoDB (Lý tưởng nếu bạn có đủ RAM cho HĐH; loại bỏ sự chậm trễ tiếp theo)
• 75% RAM đã cài đặt (trong trường hợp bạn có thêm dữ liệu / chỉ mục InnoDB mà RAM; giảm thiểu độ trễ)

Nếu bạn đang sử dụng MySQL 5.1, bạn có thể thiết innodb_max_dirty_pages_pct = 0. Điều này sẽ làm tăng đĩa I / O, nhưng InnoDB Buffer Pool sẽ bị xóa đủ để cho phép dữ liệu cũ và mục lục để xoay ra mà không đĩa I / O dâng. Plugin InnoDB của MySQL 5.5 và MySQL 5.1 không cần điều chỉnh này vì nó có cơ chế xóa vùng đệm mặc định tốt hơn.

Nếu sử dụng InnoDB không có vấn đề gì, bạn có thể cần phải sử dụng memcached hoặc véc ni. Điều này cho phép nhà phát triển ra lệnh dữ liệu được lưu trong bộ nhớ cache trong RAM máy chủ. Đương nhiên, điều này sẽ đòi hỏi sự tăng cường phát triển để làm cho ứng dụng của bạn ghi nhớ / nhận biết vecni.

Khóa bảng

• InnoDB thực hiện khóa cấp hàng, cho phép giao dịch và đọc không chặn .
• MyISAM chỉ thực hiện khóa toàn bộ bảng cho mọi CHERTN, CẬP NHẬT và XÓA .

Phần kết

Bạn không thể tránh sự chậm trễ ban đầu sau khi khởi động lại MySQL. Tuy nhiên, một khi bạn tăng cường MySQL bằng cách sử dụng các đề xuất / thông tin đã nói ở trên, bạn sẽ không còn gặp phải sự chậm trễ tiếp theo.

Tôi sẽ sử dụng các công cụ như YSlow hoặc Fireorms, v.v. để xác định chính xác những gì đang xảy ra khi bạn tải trang nói và khi bạn tải trang nói ngay sau đó. Kiểm tra xem đó có phải là sự cố bộ đệm không và hơn nữa, hãy kiểm tra xem nó hoạt động như thế nào khi bạn truy cập trang với tư cách là người dùng ẩn danh và sau đó là người dùng được xác thực. So sánh điều này với các cài đặt hiệu suất của bạn trong Drupal.

Nếu đó không phải là sự cố bộ đệm, thì hãy sử dụng nhật ký truy vấn của Devel cũng như nhật ký của MySQL để xem những gì đang xảy ra trong cơ sở dữ liệu. Ngoài ra, nếu bạn có opcode hoặc bộ đệm tăng cường hiệu năng tương tự trên máy chủ, hãy thử tắt một số số và sau đó bật lại.

Âm thanh như cron đang chạy.

Kiểm tra cài đặt của bạn ở đây: admin / config / system / cron

Tôi gần như bỏ Drupal cho dự án cuối cùng của mình vì điều này.

Phải có nhiều hơn một nguyên nhân. Tôi vẫn chưa tìm thấy giải pháp 'khắc phục tất cả' hoạt động mỗi khi sự cố này xảy ra.

Syslog và Ubuntu / Debain

Lần đầu tiên tôi chạy trong thời gian tải 15 giây không liên tục là trong khi chạy drupal trên các hệ thống dựa trên Debian / Ubuntu (dành riêng, không chia sẻ). Vô hiệu hóa mô-đun Syslog là giải pháp cho tôi.

Như @BetaRide đã nói, sử dụng xDebug hoặc một số trình lược tả PHP khác là cực kỳ khai sáng.

Vẫn còn một vấn đề - Một cách giải quyết

Đối với các cài đặt khác của tôi, tôi vẫn thua lỗ.

Vấn đề này đáng chú ý hơn trên máy chủ phát triển của tôi và cài đặt Drupal lưu lượng truy cập thấp của tôi.

Như một giải pháp thay thế, tôi đã thiết lập một công việc định kỳ để tải trang chủ của trang web cứ sau 60 giây cũng như tập lệnh cron của Drupal cứ sau 300 giây. Điều này rõ ràng là không tối ưu, nhưng tôi thà quên hoặc cuộn tròn trải nghiệm thời gian tải 15 giây thay vì khách truy cập của con người.

Nhiều người cho rằng vấn đề này có thể liên quan đến việc chặn các quá trình nền đồng bộ , đặc biệt liên quan đến các công việc cron nặng .

Nếu đúng, tồn tại một cặp mô-đun lớn đang được phát triển tích cực bởi gielfeldt * có thể cắt bỏ vấn đề này ngay lập tức, hoặc ít nhất, có thể đưa ra một số manh mối và giúp các nhà xây dựng trang web chẩn đoán và xử lý các thủ phạm cụ thể trong trường hợp của họ. Cả hai đều thay thế chặn các quy trình đồng bộ bằng các lệnh hoặc lệnh không đồng bộ không chặn và cả hai đều cung cấp các báo cáo có liên quan có thể xác định các quy trình rắc rối:

• Quá trình nền và các mô-đun đi kèm của nó cho phép hàng đợi các quy trình nền của Drupal được xử lý không đồng bộ, do đó chúng không chặn. Điều này có thể ngăn chặn vấn đề. Ngoài ra, với mô-đun Apache Process Process được đóng gói trong nhà phát triển mới nhất, có một báo cáo UI cơ bản nhưng được cải thiện với các tính năng để giám sát, mở khóa và kiểm tra thời gian bắt đầu và tiến trình của các quy trình này. Điều này có thể xác định quá trình vấn đề.
• Ultimate Cron xây dựng trên Quá trình nền để cho phép các tác vụ được kích hoạt cron có các scehdules không đồng bộ riêng biệt, mỗi tác vụ có thể được theo dõi và dừng trong UI. Ngoài việc tuyệt vời để phân tách các nhiệm vụ thực hiện nhiệm vụ nặng nề từ việc dọn dẹp trên không thường xuyên, nó còn cung cấp cho bạn một báo cáo với thông tin thuận tiện như thời lượng chạy của từng tác vụ được kích hoạt theo từng cron, khi chúng chạy lần cuối, trạng thái hiện tại, vv Điều này cũng có thể loại bỏ việc chặn và / hoặc xác định các quy trình vấn đề.

Cả hai đều là các mô-đun rất hữu ích; đối với vấn đề này, chúng có thể được sử dụng để kiểm tra lý thuyết (âm thanh rất hợp lý) rằng các tắc nghẽn được gây ra bởi các quá trình chặn đồng bộ hoặc chạy cron. Về tiềm năng, họ có thể giải quyết vấn đề bằng cách chạy các đồng bộ này thay vì đồng bộ, và họ cũng có khả năng đưa ra manh mối về việc các quy trình cụ thể đang gây ra sự cố. (được cảnh báo rằng tài liệu của họ đang tiến hành rất nhiều ...

Tuy nhiên, nếu chúng không thể được cấu hình để trợ giúp, điều đó cho thấy có nhiều vấn đề hơn là chỉ xử lý nền đồng bộ. FWIW, tôi chưa bao giờ gặp sự cố đặc biệt này trên một trang web kể từ khi các mô-đun này hoạt động chính xác (chưa chạm gỗ) - nhưng tôi đã thấy nó trên các trang web của mình trước đây, cũng như trên các trang web Drupal trực tiếp.

Ngoài ra, hãy lưu ý đến các mô-đun trình cắm thêm có liên quan khác hiện đang được phát triển - ví dụ: trong các trường hợp cường độ cao phức tạp, Ultimate Cron Queue Scaler , cho phép điều chỉnh theo ngưỡng, có thể giúp giảm các vấn đề về hiệu suất liên quan đến cron.

* không liên kết, tôi chỉ là một người dùng rất ấn tượng với công việc của họ

Vì điều này đang đánh tôi một lần nữa nên tôi bắt đầu điều tra vấn đề. Tôi chắc chắn có thể xác nhận rằng

1. một cuộc gọi drupal_cron_run()được kích hoạt bởi cron lõi của poorman thêm ~ 5s vào thời gian yêu cầu trên máy dev của tôi. Điều này có thể được kiểm tra bằng uncommenting các bài kiểm tra xung quanh các cuộc gọi đến drupal_cron_run()trong modules/system/system.moduletrongsystem_run_automated_cron()
2. xóa tất cả bộ nhớ cache thêm ~ 2 giây vào thời gian yêu cầu trên máy dev của tôi. Điều này có thể được kiểm tra bằng cách thực hiện drush cc allvà tải lại trang.

Điều này có nghĩa là thiết lập cron thành không bao giờ và thêm một cuộc gọi đến cron thông qua crontab làm cho tình hình tốt hơn rất nhiều. Đánh vào một số trang thường được sử dụng ngay sau đó để nạp lại bộ đệm sẽ một lần nữa làm mất trải nghiệm người dùng.

Tôi không chắc chắn về bộ nhớ đệm. Tôi chưa chạm vào cài đặt bộ đệm mặc định cho trang web này. Tôi nghĩ rằng drupal đang xây dựng lại tất cả các bộ nhớ cache theo thời gian có thể được kích hoạt bởi cron, nhưng tôi không chắc cách này được thực hiện. Nhưng độ trễ 7 giây là khá nhiều những gì tôi thấy khi tôi nhấn trang sau vài giờ.

Các vấn đề như thế này có thể khiến bạn phát điên và khi tôi gặp tình huống tương tự sẽ giúp tìm ra nguyên nhân gây ra sự cố xảy ra từng bước một và sau đó kiểm tra nó như một người dùng ẩn danh và đăng nhập. (phương pháp lớp hành tây)

Bạn đề cập đến việc bạn bắt đầu nhận thấy vấn đề sau khi chơi với một vài chủ đề và mã hóa tùy chỉnh của riêng bạn. Tôi không biết trang web của bạn phức tạp như thế nào cũng như logic đằng sau nó, nhưng các bước sau sẽ giúp bạn tìm ra vấn đề:

1. Trong máy chủ của bạn, hãy tạo một thư mục hoặc một tài khoản khác (điều này có thể tốt hơn) nơi bạn sẽ thực hiện cài đặt Drupal sạch với cùng phiên bản bạn đang sử dụng trên trang web của mình. Sau đó, không thêm bất kỳ mô-đun hoặc chủ đề kiểm tra thời gian để trang web đáp ứng yêu cầu đầu tiên và yêu cầu sau. Nếu tất cả đều hoạt động tốt, bạn có thể bỏ qua các vấn đề về cấu hình máy chủ, nếu nó hoạt động giống như hiện tại của bạn thì bạn có lỗi cấu hình với máy chủ web hoặc cơ sở dữ liệu của bạn.

2. Nếu kết quả từ bước 1 là tốt và máy chủ phản hồi nhanh và các yêu cầu sau cũng nhanh như vậy, thì chỉ cài đặt chủ đề từ trang web hiện tại của bạn vào trang web cài đặt sạch và kiểm tra lại. Nếu mọi thứ vẫn phản hồi nhanh, thì chủ đề của bạn không phải là vấn đề và bạn nên tiếp tục bước 3 nếu không bạn phải bắt đầu gỡ lỗi chủ đề của mình * 1.

3. Nếu sau các thử nghiệm ở bước 2, trang web vẫn nhanh chóng bắt đầu chuyển các mô-đun trong trang web hiện tại của bạn và đảm bảo kiểm tra thời gian phản hồi sau khi thêm và bật từng mô-đun * 2.

4. Nếu sau khi thêm chủ đề và mô-đun, trang web vẫn phản hồi nhanh chóng bắt đầu thêm cấu hình, tạo loại nội dung, nhập chế độ xem, menu cài đặt, v.v. Đừng quên kiểm tra phản hồi của trang sau khi thêm từng trang.

5. Thiết lập và cấu hình đã sẵn sàng và trang web vẫn còn nhanh, giờ đây sẽ mang lại dữ liệu. Các nút nhập, thuật ngữ phân loại, nhận xét, v.v ... Tôi biết tôi phải nghe như một bản ghi bị hỏng, nhưng luôn kiểm tra sau khi hoàn thành mỗi bước.

* 1 Kiểm tra chủ đề: quá trình này có thể khó khăn trong một chủ đề siêu phức tạp, dưới đây là một vài gợi ý:

1. Nếu bạn liên kết với bất kỳ thư viện js hoặc css bên ngoài, hãy thử sử dụng một bản sao cục bộ của cùng một.

2. Trong tệp template.php của bạn, hãy kiểm tra chức năng có thể có các vòng lặp dài hơn hoặc vô tận cũng như chức năng tiền xử lý và / hoặc chức năng móc chủ đề.

3. Kiểm tra tệp mẫu khác (page.tpl.php, v.v.) và tìm cách xử lý PHP thô của mảng và đối tượng.

4. Nếu sử dụng "Lượt xem" và xem tệp mẫu, thì hãy kiểm tra.

5. Luôn kiểm tra lại các đường dẫn, tối ưu hóa hình ảnh, tập tin js và css. Đôi khi các tệp js có thể có một số chiều cao nặng khi sử dụng nhiều đoạn mã trong một tệp.

* 2 Mô-đun thử nghiệm : mô-đun thử nghiệm hơi khác một chút vì việc sử dụng thao tác nặng với PHP được cho phép. Dưới đây là một số gợi ý:

1. Các mô-đun được cộng đồng hỗ trợ (CCK, Lượt xem, v.v.) có các vấn đề xếp hàng trên drupal.org kiểm tra chúng để xem liệu có bất kỳ vấn đề nào về vấn đề của bạn không và liệu có khả năng có thể có một bản vá để khắc phục nó không.

2. Mô-đun mã hóa tùy chỉnh của riêng bạn, nếu bạn đã mã hóa, bạn phải sửa nó, phải không?. Kiểm tra kỹ mã hóa của bạn và kiểm tra việc sử dụng các chức năng đối với api.drupal.org, bạn có thể đang sử dụng chức năng quá mức thay vì móc nối.

3. Internet chia sẻ mô-đun mã tùy chỉnh, làm như trong bước 2, nhưng lần này bạn cũng có thể liên hệ với người viết mô-đun ban đầu và cho anh ấy / cô ấy biết về vấn đề.

4. Nếu trang web của bạn là bản nâng cấp (D5 -> D6 -> D7), hãy kiểm tra di chuyển hoặc nâng cấp tập lệnh (thường là trong tệp module.install), bạn có thể cần thêm "chỉ mục" trên cấu hình bảng mới để làm cho truy vấn SQL chậm X nhanh hơn .

5. Nếu bạn cảm thấy bạn có tầm nhìn đường hầm về vấn đề, hãy bước ra ngoài một chút và thực hiện một số hoạt động khác hoàn toàn không liên quan và sau đó quay lại sau để xem xét lại vấn đề.

6. Nếu bạn ping điểm vấn đề trên một phần của mã, nhưng không thể đưa ra đầu hoặc đuôi về cách khắc phục, hãy thử giải thích phần đó là siêu sao để làm gì với một người không biết cách lập trình hoặc cách thức hoạt động của Drupal sẵn sàng để được bất ngờ.

Lưu ý: Đừng lo lắng nếu sau khi xây dựng lại trang web của bạn, tất cả bắt đầu hoạt động giống như một nét quyến rũ là một trong những tính năng tốt nhất mà máy tính có.

Kiểm tra kỹ xem bạn đã xóa bất kỳ mô-đun nào mà không gỡ cài đặt chúng. Điều này gây ra sự chậm trễ vì Drupal cố gắng tìm các tệp nhưng chúng không còn ở đó nữa.

Xóa tham chiếu trong bảng biến nếu các mô-đun không còn tồn tại nữa.

Một APM Web như newrelic là công cụ tốt nhất để theo dõi các vấn đề về hiệu suất. Tôi đã có các trang web gọi một hoặc hai dòng mã đã làm những việc khó khăn, tải các mảng không cần thiết vào những thời điểm kỳ lạ và làm những việc khác khá vô hình cho đến khi chúng tôi theo dõi chúng bằng APM.

Có người đề cập rằng GoDaddy sẽ chậm. Nhiều công ty lưu trữ dựa trên đám mây cũng sẽ có sự chậm trễ ban đầu này vì các dịch vụ như AWS có nó. Nó rẻ hơn khi các máy chủ được khử vũ khí tự động và những máy chủ đó sẽ cần một hoặc hai giây để 'thức dậy'.

Chẳng hạn, Pagodabox có 3-4 giây cho byte đầu tiên, cho đến khi máy chủ vui vẻ thức dậy. Trên thực tế, Pagodabox đã kiếm tiền để giữ cho máy chủ luôn hoạt động và vì vậy bạn có thể trả thêm tiền để 'caffienate' trang web của mình.

Ngoài ra, một CDN có thể giúp bạn ra ngoài. Web / db sever của bạn sẽ không được tải xuống với việc phục vụ các trang hoặc hình ảnh được lưu trong bộ nhớ cache. Một hướng dẫn tốt ở đây: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

Và ... WebPageTest làm tôi hạnh phúc. http://www.webpagetest.org/ So sánh thời gian tải trên khắp hành tinh và với các trình duyệt web khác nhau miễn phí. Sử dụng điều này để có được kết quả trong thế giới thực cho bất kỳ thay đổi nào bạn đang thực hiện.

vấn đề có thể ở bất cứ đâu.

1. Đảm bảo bạn chưa bật chế độ gỡ lỗi trên bất kỳ chủ đề hoặc mô-đun nào. Ví dụ, trong nhiều chủ đề có một tùy chọn để tạo lại đăng ký chủ đề.
2. Nếu bạn đang chạy trên lưu trữ được chia sẻ như Godaddy, thì 15 giây cho yêu cầu lần đầu tiên là bình thường.
3. Chuyển đổi trang web hoặc trang trước của bạn thành codebase bằng mô-đun Xuất Drush CTools . Điều này sẽ loại bỏ bất kỳ cuộc gọi cơ sở dữ liệu nào và trang web của bạn sẽ chạy hoàn toàn từ php.
4. Nếu bạn vẫn gặp sự cố, hãy sử dụng cài đặt Devel bằng cách bật query logvà page timertùy chọn tại admin/config/development/devel. Xem cái nào trong hai cái cần nhiều thời gian hơn để tạo toàn bộ trang.
5. Khởi động lại máy chủ của bạn nếu không có gì hoạt động.
6. Trường hợp xấu nhất cài đặt XHProf để xem mọi thứ đang sai ở đâu.

Vì vậy, đây là cách tôi khắc phục sự cố cho cài đặt của mình. Đó không phải là một giải pháp thực sự vì tôi không thể tìm ra nguồn gốc chính xác của vấn đề (nếu có), nhưng đó là một giải pháp tốt

1) Tổng hợp CSS (cài đặt bộ đệm). Điều này làm giảm một nửa độ trễ

2) Đặt cron thành không bao giờ (và chạy bên ngoài) - Lưu ý: Tôi đã "cố gắng khởi động cron khi nó đang chạy". Tôi nghĩ rằng nó đã cố gắng khởi động cron mỗi lần ra mắt nhưng vì nó thất bại, trang cron không đề cập đến nỗ lực mới nhất, mà là thành công mới nhất.

3) Thiết lập công việc định kỳ gọi trang chủ bằng Lynx cứ sau 30 phút

Tất cả điều này trên một máy chủ lưu trữ được chia sẻ. Nó không tối ưu nhưng nó hoạt động

Tôi khuyên bạn nên sử dụng bộ đệm phía trước dọc theo các dòng của mô-đun Boost (giả sử bạn đang lưu trữ chia sẻ) hoặc Varnish. Điều này sẽ hoạt động tốt nhất nếu truy cập trang web của bạn chủ yếu là ẩn danh và nội dung trang, phần lớn, không động (nghĩa là các trang không thay đổi nhiều).

Các giải pháp này lưu các trang được kết xuất trong lần truy cập đầu tiên và sau đó phục vụ html được kết xuất trước thay vì đi qua bootstrap đầy đủ của Drupal, xây dựng trang và các quy trình theo chủ đề, tiết kiệm rất nhiều thời gian, đặc biệt là trên các trang web bận rộn mà còn trên các trang web như bạn mô tả "đi ngủ" và mất quá nhiều thời gian để thức dậy.

Hạn chế thực sự duy nhất là (ít nhất là đối với Boost) bạn sẽ cần xóa bộ nhớ cache khi nội dung trang thay đổi. Nếu bạn muốn đảm bảo trang web được lưu trữ đầy đủ với nội dung hiện tại, bạn có thể chạy tất cả cc và sau đó cuộn tròn hoặc wget đối với trang web đầy đủ theo định kỳ thông qua cron.