2010-01-25 3 views
11

Sau khi yêu cầu this question, Tôi bắt đầu sử dụng Sinatra như một cách để phục vụ các trang web.Tại sao trang web tội lỗi của tôi lại quá chậm?

Tối nay, một người bạn của tôi và tôi bắt đầu kiểm tra tốc độ của máy chủ.

Các tập tin để đăng nhập vào trông giống như:

require 'rubygems' 
require 'sinatra' 
require 'haml' 

enable :sessions #for cookies! 

get '/' do 
    haml :index 
end 

Và index.haml trông giống như:

%title 
    First Page 

%header 
    %h2 First Page 

Anh ấy ngồi trên một máy tính xách tay gần đây, như là tôi, với 802.11n của Apple bộ định tuyến giữa hai chúng tôi. Cả hai chúng tôi đang chạy Windows 7. Tôi cũng đã thử những tập tin tương tự trên một máy tính xách tay chạy Ubuntu 9.10 x64 với Sinatra và tất cả các tập tin có liên quan được cài đặt từ apt-get.

Sinatra mất 7 giây để phân phát một yêu cầu trang duy nhất, bất kể hệ điều hành máy chủ, Windows hoặc Linux. Tôi thấy rằng here tác giả đã quản lý để nhận hơn 400 yêu cầu/giây được xử lý. Đưa cái gì? (hoặc điều này có nên xảy ra với SuperUser hay không?)

+0

Nó có thể là máy chủ mà cấu hình của bạn đang sử dụng. Có sự khác biệt lớn giữa WEBrick, Thin và Mongrel chẳng hạn. Làm thế nào để bạn cháy lên ứng dụng Sinatra của bạn? – daddz

+0

Từ dòng lệnh; về cơ bản, chúng tôi chạy 'ruby TestServer.rb' và sau đó kết nối với cổng 4567. Tôi là tổng số n00b cho điều này, vì vậy nếu có hướng dẫn về loại điều này, hãy biết. – mmr

Trả lời

9

tôi sẽ dành bất kỳ ý kiến ​​nào về thời điểm bạn nên tối ưu hóa ứng dụng web của mình.

Thiết lập các cấu hình khác nhau trong ứng dụng Sinatra của bạn để phát triển và sản xuất vì một số đề xuất này, bạn sẽ không bao giờ muốn sử dụng. Trong thực tế, bạn có lẽ nên đi trước và thiết lập và môi trường tương tự như cách bạn sẽ triển khai trong sản xuất. Bạn sẽ không triển khai bằng cách chỉ cần chạy ruby app.rb. Bạn muốn đặt apache hoặc nginx trước Mongrel của bạn. Mongrel sẽ phục vụ các tệp tĩnh của bạn, nhưng điều đó thực sự chỉ được khuyến khích cho chế độ phát triển. Trong triển khai, một máy chủ web sẽ làm tốt hơn rất nhiều cho việc đó. Tóm lại, môi trường triển khai của bạn sẽ nhanh hơn môi trường phát triển độc lập của bạn.

Tại thời điểm này, tôi sẽ không lo lắng về Mongrel so với Thin. Nếu Thin nhanh gấp hai lần - nó không phải là - sau đó 7 giây của bạn sẽ trở thành 3.5. Điều đó có đủ tốt không?

Một số điều cần thử ...

Tôi biết tôi vừa nói với bạn để thiết lập môi trường triển khai, nhưng có thể nó không phải là phía máy chủ. Bạn đã thử chạy YSlow hoặc PageSpeed trên các trang của mình chưa? I/O sẽ mất nhiều hơn 7 giây đó (Tuyên bố từ chối trách nhiệm: Tôi cho rằng không có gì sai khi thiết lập mạng của bạn) so với máy chủ. YSlow - Firebug thực sự - sẽ cho bạn biết mỗi phần của trang của bạn mất bao lâu để truy cập trình duyệt.

Một trong những điều mà YSlow bảo tôi phải làm là đặt tiêu đề Expires về phía trước trên tài sản tĩnh của tôi, mà tôi biết nhưng tôi đã rời khỏi tối ưu hóa cho đến cuối. Đó là khi tôi nhận ra rằng có ít nhất 3 different places that I could specify that header. Tôi thuyết phục bản thân mình rằng làm điều đó trong nginx là đúng nơi để đặt nó.

Nếu bạn hài lòng với những kết quả đó, bạn có thể xem máy chủ. Tắt đầu của tôi, vì vậy không đầy đủ

  1. Bật phản hồi gzip.
  2. Kết hợp các bảng định kiểu của bạn để chỉ có một yêu cầu trên mỗi trang. Có thể có một số Rack Middleware cho điều này, nếu bạn không làm điều đó bằng tay.
  3. Bộ nhớ cache. Tôi đang cố gắng Rack::Cache.
  4. Sử dụng sprites để giảm số lượt tải xuống hình ảnh bạn sử dụng.
  5. Giảm bớt Javascript của bạn. Một lần nữa, có thể thông qua Rack Middleware.

Rack Middleware gọn gàng, nhưng nó sử dụng CPU. Do đó, việc rút gọn Javascript của bạn sẽ thêm bước mới vào luồng công việc của bạn, nhưng trên máy chủ, nó nhanh hơn Middleware. Đó là một sự cân bằng.

Xin lỗi, nếu điều này thật là rườm rà.

+0

Cảm ơn bạn đã phản hồi kỹ lưỡng! Bạn đã đánh mất tôi ở 'tiêu đề hết hạn về phía trước về phía trước', sau đó, tôi học được chiều sâu của sự thiếu hiểu biết của tôi. Tôi nghĩ có rất nhiều việc phải làm. – mmr

+0

Đó là thuật ngữ tôi nhận được từ Yahoo! Trang web YSlow. http://developer.yahoo.com/performance/rules.html. Nó chỉ có nghĩa là để đặt tiêu đề hết hạn cho một số điểm xa trong tương lai. Giống như 20 năm, nói. – dbrown0708

+2

Tôi chọn đây là câu trả lời hoàn toàn vì nó dẫn đến việc học hỏi rất nhiều về tối ưu hóa khi tôi đã qua Hello World.Sửa chữa, trong trường hợp này, là để biến gỡ lỗi trong webrick. – mmr

4

Hãy thử sử dụng Thin làm máy chủ. Tôi nhận thấy sự gia tăng hiệu suất so với WEBrick và Mongrel.

gem install thin 

Khi bạn chạy ứng dụng của bạn sử dụng ruby TestServer.rb bạn sẽ thấy như sau:

Sinatra/0.10.1 đã đưa ra những giai đoạn trên 4567 phát triển với sao lưu từ Thin

+0

Phiên bản Sinatra tôi nhận được từ đá quý là 0.9.4; Tôi có nên nhận được một số phiên bản mới, gần đây nữa không? – mmr

+0

Tôi nhận phiên bản 0.10.1 từ github. gem install sinatra-sinatra --source = http: //gems.github.com – Trevor

+0

cũng giống như một lưu ý phụ, mỏng không hoạt động trên các cửa sổ không có nmake (nghĩa là, không có phiên bản 64-bit của windows). Mongrel nên làm việc tốt. – mmr

5

Tôi gặp sự cố này khi chạy Sinatra bằng shotgun nhưng không phải khi chạy ứng dụng của tôi trực tiếp (tức là, ruby -rubygems app.rb). Điều này là bởi vì shotgun dĩa và tải lại các ứng dụng cho mỗi yêu cầu.

Tôi tìm thấy một số thread in Sinatra's mailing list đã thảo luận vấn đề này và những người ở đó đã khuyên sử dụng rerun thay vì shotgun. Tôi vui mừng nói rằng nó đã giải quyết vấn đề này cho tôi.

+0

Cảm ơn bạn! Chỉ cần cài đặt lại chạy và ứng dụng đang tải bình thường trở lại. Tôi đã tìm ra shotgun sẽ làm chậm mọi thứ, nhưng không phải là nó đã tải lại ứng dụng cho mọi yêu cầu (bao gồm tất cả các tài sản, đã giết hiệu suất ngay cả khi chỉ thử nghiệm ở chế độ dev). –

1

Tôi đang chạy Sinatra bên trong VMWare Fusion with Vagrant. Ứng dụng của tôi đang chạy chậm (khoảng mười giây để phục vụ yêu cầu). Sau đó, tôi tìm thấy viên ngọc này:

Webrick is very slow to respond. How to speed it up?

Dường như WEBrick là (theo mặc định) cấu hình để đảo ngược tra cứu dns trên mọi yêu cầu, và điều đó đã làm chậm nó xuống.