I've got a rails app in development mode (3.1.12 ruby 1.9.2) running on a windows server via fastcgi (with heliconzoo).
If i wait a certain amount of time from page load to page load, it takes 4-6 seconds to load the page. Afterwards it's loading with normal speed independent on which computer and in every browser.
Does the app/service shutdown if nobody visits the page within a while?
What can I do to prevent this behaviour?
e: For the first entry of today the development.log says it took 500ms to load the page which is 10 times faster...But it took 5s to load actually...
Related
I'm new to JMeter and. I followed this tutorial to learn JMeter.
I tried to do a load tested under following conditions.
Number of Threads (Users) - 1000
Ramp-Up Period (in seconds) - 10
Loop Count - 5
While I'm running the test, I tried to load my website (after clear cache)But, it takes more than usual time to load the page. This issue doesn't occur when the browser has cached data.
Can someone please tell me why this is happening? Is it because of when 1000 users load my site, it may crash or something?
Any kind of explanation will be appreciated.
While running your JMeter test if you try to load your website (after clear cache), it will always take more time to load than usual.It's because you have cleared the cache and now the browser needs to render the page resources again to load your desired page.After loading is complete and if you try to load the page again without clearing cache, it will take less time to load the page this time.Browser does not fetch page resources every time, rather the browser saves it in its cache.So next time when you try to open or load that page, the browser could use those cache to open that page for you in the shortest period of time. So for the first time when a browser load a page it takes more time than loading that specific page later(without clearing cache).
Another point is , as your Jmeter test was running while you tried to load your website, it will take a longer time to load your website.Because your application was already handling some requests send by JMeter.So handling extra load will impact on your website page response time.
Ramp up time 10sec for 1000 users!!!
It is not the best practice. You have to give enough time to warm up those 1000 users. 10 sec is too small to be the ramp up time for 1000 users.So during the JMeter test period, it is obvious that your browser will take an unexpected time to load your webpage(using Browser) or end up notifying "Connection Timeout".It necessarily doesn't mean that your application is crashed. It's simply because of unrealistic test script design in JMeter.
Could you elaborate on the type of webserver software you are using e.g?
- Apache HTTPD 2.4 / Nginx / Apache Tomcat / IIS
And the underlying operating system?
- Windows (Server?) / Mac OS X / Linux
If your webserver machine is not limited by the maximum performance of your CPU, Disk etc. (check the Task Manager) your performance might be limited by the configuration of Apache.
Could you please check the Apache HTTPD log files for relevant warnings?
Depending on your configuration (httpd.conf + any files "Include"d from there) you may be using the mpm_winnt worker, that has a configurable number of worker threads which by default is 64 according to:
https://httpd.apache.org/docs/2.4/mod/mpm_common.html#threadsperchild
Once these are all busy new requests from any client (your browser, your loadtest, etc.) will have to wait for their turn.
Try and see what happens if you increase the number of threads!
I'm currently considering moving to jRuby, and I'm still unsure how everything will work, but let's consider this hypothetical situation.
A user 1 loads a page in my app which takes about 2.5 seconds, and at about 500ms in the execution a user 2 tries to open different page which takes 1 second to load.
If my estimate is correct, this is what would happen if you ran it in MRI with single process :
User 1 waits for 2,5 seconds for his page to load
User 2 waits for 3 seconds for his page to load (2 seconds waiting for user 1 to complete the loading of his page, and 1 second for his page to finish rendering)
Is my estimate correct?
And let's say if I ran the same app under jRuby this would happen :
User 1 waits 2,5 seconds for his page to load
User 2 waits for 1 or more seconds but less than 3, depending how much of the memory/cpu the request from user 1 takes
Is my other estimate correct? Of course assuming your code is thread safe. If my estimate is incorrect please correct me, or if it is correct, do I need to make sure that some config is set at rails app level or should I be careful about something else other than thread safe code?
Update
I've just done a small jRuby POC app, used the warbler gem to build a war file, and deployed a war to a Tomcat web server. I don't think my estimate was correct for jRuby, this is what I observed :
User 1 waits 2,5 seconds for his page to load
User 2 waits for 3 seconds
Which is identical to MRI, in terms of request processing, shouldn't jRuby process these in parallel?
we're talking were hypothetical things (and assumptions)
if "loads a page in my app which takes about 2.5 seconds" all users will keep loading this thing (concurrently) unless of course you do some caching or store it after the first load for other users.
the difference is that in MRI whenever Ruby code is executed (not waiting on IO such as a database or loading something from http://) 2 threads won't run concurrently, while in JRuby they will.
if you're seeing User 2 waits for 3 seconds on JRuby it means that smt is blocking multiple requests e.g. there's a Mutex somewhere along the way (e.g. Rack::Lock).
When loading my rails app in production (hosted on heroku) it takes up to 10 seconds to load. This only happens on the very first time the site is loaded. Any subsequent page views load normally. View at kurtiselliott.com
This is because Heroku will lazily spin up your dyno which essentially means that the first request will take ~10 seconds. If you leave your app idle for a little while Heroku will spin down your dyno.
See article for full explanation
https://devcenter.heroku.com/articles/dynos#dyno-sleeping
Does anyone have any experience with Rail development page display erratically slowing down and speeding up (page appears 15-20 seconds after the console says the entire page has been rendered).
My development environment is rails 3.0.17 on Mac (Lion), WEBrick 1.3.1, ruby 1.9.2, with Postgres v11 (app supplied by Heroku) for the development database.
Recently, I've noticed some very long delays loading pages... 15 to 20 seconds at times, and the delay is completely unrelated to the complexity of the page, and a given page might load fast several times, then load slow. It might be pretty bad for several minutes, then go away for an hour.
And whether the page loads slow or fast, the rails log always shows the page has rendered fairly quickly... I'll see something like "Completed 200 OK in 486ms" but then the browser might say "waiting for localhost" for another 15 seconds before displaying the page.
Does not seem to depend on the browser (FF or Safari act the same).
Dos not sem to relate to updating the code base. I cna be testing some UI elements and everything is snappy, then suddenly several pages hang for 15-120 seconds.
Still happens even after I added the gem 'rails-dev-boost' to my Gemfile in development.
I also added to my development machine gem 'http_logger' to log calls to external http requests like S3, but don't see that as a factor (the delays often happen on pages that don't access external APIs).
My layouts have a couple of external .js dependencies such as http://static.twilio.com/libs/twiliojs/1.0/twilio.min.js, but I have added that to the bottom of my layout so I would (resumably) still see the page contents quickly if that were being delayed. (Besides, it is probably cached by my browser).
Of course I have tried rebooting the machine, verified activity monitor seems normal for CPU and memory usage. It does not seem to correlate when timemachine is doing its thing.
MORE INFO: per suggestion in comment from AKG below, I used Firebug's web console and most of the time the stylesheets load in a couple of milliseocnds, but when the slowdown occurs I'm seeing delays of 8-20 seconds for most of the stylesheets... which suggests webrick is failing to serve the pages timely?
It could be that buggy/slow middleware is executing after the render is called, but before the response is sent. I recently ran into this issue with pauses of more than 1 minute in some cases, and the culprit turned out to be the Bullet gem, which is designed to help us detect N+1 queries. I removed the middleware and the issue went away!
I got the same problem a few times. I switched to Mongrel. That automatically resolved the issue. However, I got this with Rails 2.3.8.
If using in the controller:
def index
#time_start_in_controller
...
end
and at the end of view, use
<%= "took #(Time.now - #time_start_in_controller} seconds" %>
but isn't the time at the view not the true ending of rendering, because it needs to mix with the layout and so forth. What is a more accurate way (just as accurate as possible) to print out the page generation time right on the webpage?
(update: also, the console showing the log as taking 61ms, but the page definitely took 2 to 3 seconds to load, and the network I am using is super fast, at home or at work, at 18mbps or higher with a ping of maybe 30ms)
update: it is a bit strange that if I use the http performance test ab
ab -n 10 http://www.my-web-site.com:8080
it takes 3 seconds total for 10 requests. But if I use Firefox or Chrome to load the page, each page load is about 3 seconds. This is tunneling to my work's computer back to my notebook running Rails 3, but shouldn't make a difference because I run Bash locally for the above statement and use Firefox locally too.
in a typical production environment, static content (images, css, js) are handled by the web server (eg. apache, nginx etc) not you rails server. so you should check their logs as well. if you are serving static content from your rails server that could be your problem right there.
If your browser time is slow but the time taken in rails (According to the logs) is fast, that can mean many things including but not quite limited to:
network speed is slow
your dns server is slow and browser can't resolve your dns quickly (this happens with for instance if you use godaddy for your dns server they throttle dns lookups)
the requests concurrency exceeds how many threads you have in rails
one way to debug these types of performance issues is to put something in front of the rails server (for example Haproxy) and turn the logging to full. As they will show how many waiting requests there are and how long the actual request/response transferring took along with how long it took your rails thread to process.