We have an environment running that uses Apache, Passenger and rails. The system is handling most request normally, yet certain requests do not make it to the rails application. For instance, a request to /books is successful, but /books/1 hits apache and passenger, but does not even make it to rails.
We set the apache log level to debug and the passenger log level to 3 so that we could monitor all incoming requests. We could see each request coming through and even the /books/1 request is being handled by passenger. But it never gets to rails.
Is there any way to determine where the request goes between Passenger and rails or where debugging information might live? Has anyone ever seen any problems with passenger spawning or queuing? We have spawning set to conservative. Also, we have had some permission/ownership problems in the past, so I am not ruling this out yet.
Thanks in advance
First guess: is that it's reading from your cache at public/books/1.html. This fits all the symptoms. If there is a public/books/1.html file when you go to request books/1 Apache will serve the request by sending just that file.
Second guess: alternate configuration is mucking about with how Apache is serving the route.
Related
I'm pretty new to Ruby On Rails webdevelopment, and I've got the following question:
In my Javascript I launch multiple calls to my controller at once with the use of AJAX, however I'm under the impression these requests get handled one by one, which results in a very slow experience (as some of the requests are quite intense and can take a while to process). I'd expect the server to spawn a separate thread for each request. As far as I'm aware I'm using WEBrick as the server on which my application is running. Online I found some posts indicating that WEBrick is by definition single threaded, so I'm out of luck, however some other posts claim it supports multithreading, but it is prohibited by a mutex in Rails. Most posts seem to refer rails 4.1-4.2, I'm currently running 5.0.1.
Use puma instead of webrick in development and unicorn in production and you will be alright.
We currently have a rails 3 app (in the process of upgrading to rails 4) and I want to start using the ActionController::Live to play with Server Sent Events for some real time updates to our users.
My question is does this new functionality work with Phusion Passenger out of the box? Everything I read is using puma, rainbows or thin. I love how easy Passenger is for our deployment, I'd even be tempted to buy the enterprise version but not if it's going to require me configuring everything to get this working. If I have to configure everything I might as well go with an open source option.
Server Side Events works great on Phusion Passenger. I wrote a demo for you. Check out https://github.com/phusion/passenger-ruby-server-side-events-demo
Hongli Lai,
Phusion CTO
Phusion Passenger developer
I would like to post a Rails 4 solution i got to work seamlessly using passenger and redis..
i use ajax to response to publish events from redis you can just send data payload.
Do ensure is you rails enviornment file development.rb/production.rb
config.cache_classes = true
config.eager_load = true
You don't need puma, unicorn, goliath for SSE to work passenger serves fine.
Solution here
This has been asked before, but never answered particularly exhaustively.
Let's say you have Rails running on one of the several web servers that support it, such as WEBrick, Mongrel, Apache and Nginx (through Passenger Phusion). The server receives two concurrent GETs, what happens? Is this clearly documented anywhere?
Basically I'm curious:
Is a new instance or rails is created by the server every time?
Does it somehow try to re-use existing instances (ruby processes with Rails already loaded in it?) to handle the request?
Isn't starting a new ruby process and re-loading Rails in it pretty slow?
Thanks! Any links to exhaustive clarifications would be greatly appreciated.
Some use workers (apache, phusion, unicorn), some don't. If you don't
use workers, it really depends wherever your application is threadsafe
or not. If you are, more than one request may be served at a time,
otherwise there's Rack::Lock which blocks that. If there are workers
(separate processes), each of them does a request then goes back to
the pool where the master assigns it a new request. Read
on
I have inherited the maintenance of a legacy web-application with an "interesting" way to manage concurrent access to the database.
The application is based on ruby-on-rails 2.3.8.
I'd like to set up a development environment and from there have two web browser make simultaneous requests, just to get the gist of what is going on.
Of course this is not going to work if I use Webrick, since it services just one http request at a time, so all the requests are effectively serialized by it.
I thought that mongrel could help me, but
mongrel_rails start -n 5
is actually spawning a single process and it seems to be single-threaded, too.
What is the easiest way of setting my development environment so that it responds to more than one request at a time? I'd like to avoid using apache and mod_passenger because, this being development, I'd like to be able to change the code and have it reloaded automatically on the next request.
In development mode, mod_passenger does reload classes and views. I use passenger exclusively for both development and deployment.
In production, you can (from the root of the rails app):
touch tmp/restart.txt
and passenger will reload the app.
Take a look at thin
http://code.macournoyer.com/thin/
I issue a simple GET request to my server, and it's coming back after ~1.2 seconds on average (using firebug NET tab, the "waiting for reqponse" part- not even the whole reponse time)
My ping to the server is 0.250
Using Passenger with rails 2.3.3, in the rails log the request is taking ~0.023
My server is on GoDaddy, so I checked their homepage with firebug also- the "waiting for reqponse" time for their page is ~0.320
Worst case should be around 0.4... so where did I lose the other 0.8 seconds?
What else can I check?
Edit:
Seems like it's unrelated to rails-
An image request (that only apache responds to, doest hit the rails at all) takes ~1.2 seconds also
GoDaddy may have a reverse-proxy between you and your HTTP server.
They may be doing something like sending you the response headers right away, then possibly serving you the contents of the response from cache.
So, from the standpoint of your HTTP server, the response is transmitted. Then it goes to GoDaddy's reverse-proxy, then finally to your web browser.
Try setting PassengerPoolIdleTime to 0 in your Servers or VHosts configuration.
Maybe your server is shutting down the application instances to fast and spawns a new instance with every request which usualy takes quite long.
Take a look at the documentation for more information on this setting:
http://modrails.com/documentation/Users%20guide%20Apache.html#PassengerPoolIdleTime
Where your files are hosted from for GoDaddy is not the same as where their homepage is hosted from.
Have you checked other pages you have hosted on the same server? Possibly due to database connections or "slow" connections like that can cause the page to take awhile before it's sent back to the client.
Doesn't sound like it is your problem, but the ISP's.
Can you do a wget to an internal ip/port to your rails app directly (or apache) from the same server?
That will tell you if the probaby is in the app stack or further upstream.
If you can, you can use apache tool, called ab "apache benchmark" to help.
The key is having a ssh access to your computer.