I have a web page who sends multiple ajax get request to a django server.
The server does some internet crawling for each request it gets and returns a response to the client once it finishes.
It seems that the server replies to the requests one after another.
I'm considering to send each request to a Celery worker to make the server's responses asynchronous but I'm not sure if it will solve the problem.
Also I'm using django on heroku and not sure how to combine celery with django on heroku.
The Heroku Django tutorial app uses gunicorn as the server, as you can see here:
https://github.com/heroku/python-getting-started/blob/master/Procfile
There is no special gunicorn config in the tutorial app, so you are running with gunicorn default settings. You can see what they are here:
http://docs.gunicorn.org/en/stable/settings.html#worker-processes
You'll note that this means you have a single worker process, of the sync type (i.e. no greenlets magic to enable concurrency within the single Python process)
It does say you can scale gunicorn to use multiple processes (still on a single Heroku dyno) by setting the WEB_CONCURRENCY environment variable, on Heroku this is easily done from your local shell using the cli tools:
$ heroku config:set WEB_CONCURRENCY=4
Gunicorn docs suggest setting this to "A positive integer generally in the 2-4 x $(NUM_CORES) range." Your basic Heroku dyno will be a single core.
Related
I have a Laravel app running locally using ./vendor/bin/sail up. I also have a trivial NodeJS server (running locally as well) that waits 60 seconds on each request and returns dummy data. The Laravel app makes a request to the Node app and becomes unresponsive to client requests until the 60 seconds are up.
Is this a limitation of the Laravel dev server? Is there a setting I'm missing?
Answering my own question.
Laravel uses php artisan serve underneath sail, which in turn uses the built-in server, which by default "runs only one single-threaded process."
However, "You can configure the built-in webserver to fork multiple workers in order to test code that requires multiple concurrent requests to the built-in webserver. Set the PHP_CLI_SERVER_WORKERS environment variable to the number of desired workers before starting the server. This is not supported on Windows."
Adding PHP_CLI_SERVER_WORKERS=5 to my .env file fixed the issue.
A single Rails app running in Heroku receives the requests in two subdomains: api.domain.com and www.domain.com.
As per Heroku's Procfile documentation there is only one process type that receives the http requests (that is called "web").
Is it possible to create a second "web" process so I can scale independently the number of dynos for the 2 subdomains (for example, giving more dynos to the API subdomain).
You can't do that - only the web process receives traffic, you can't have more than 1 in an app.
You could deploy the same code to 2 Heroku apps and run one on www and the other on api.
I'm an iOS developer primarily. In building my current app, I needed a server that would have a REST API with a couple of GET requests. I spent a little time learning Ruby, and landed on using Sinatra, a simple web framework. I can run my server script, and access it from a browser at localhost:4567, with a request then being localhost:4567/hello, as an example.
Here's where I feel out of my depth. I setup an Ubuntu droplet at DigitalOcean, and felt my way around to setting up all necessary tools via command line, until I could again run my server, now on this droplet.
The problem then is that I couldn't then access my server via droplet.ip.address:4567, and a bit of research lead me to discovering I need Passenger and an Apache HTTP Server to be setup, and not with simple instructions.
I'm way in over my head here, and I don't feel comfortable. There must be a better way for me to take my small group of ruby files and run this on a server, than me doing this. But I have no idea what I'm doing.
Any help or advice would be greatly appreciated.
bit of research lead me to discovering I need Passenger and an Apache HTTP Server to be setup, and not with simple instructions.
Ignore that for now. Take baby steps first. You should be able to run your Sinatra app from the command line on the DigitalOcean droplet, and then access it via droplet.ip.address:4567. If that doesn't work something very fundamental is wrong.
When you start your app, you will see what address and port the app is listening on. Make sure it's 0.0.0.0 and 4567. If it's 127.0.0.1 or localhost that means it will only service requests originating from the same machine
After you get this working, next step is to make your Sinatra app into a service. Essentially this means the app runs in the background, and auto-starts when the system reboots. Look into Supervisor which is very simple configuration to get this running.
Later you can install Apache or Nginx to put in front of your Sinatra app. These are proxies which simply forward requests from port 80 (default HTTP port) to your sinatra app, but can do additional things such as add SSL support, load balancing, custom error pages etc. - all of which you do not need right now.
I am developing a node.js application with Socket.io and deploying same on Heroku Dyno. Socket.io is using RedisStore with its PUB/SUB. Socket.io client works perfectly fine with one dyno in heroku. But when I increase the number of dyno to more than one (say two), socket io client request does not work.
Please let me know if any specific configuration on client side is needed while setting up heroku for multiple web dyno having socket.io support.
Sorry, but heroku doesn't support sticky session and it's not supported by Socket.io
Sticky load balancing If you plan to distribute the load of
connections among different processes or machines, you have to make
sure that requests associated with a particular session id connect to
the process that originated them.
Using multiple nodes
There's a great thread in an issue on the engine.io github. Helped me understand the issue of sticky sessions, engine.io, and heroku a lot better.
Sticky Sessions are now supported by Heroku - but only if you join their development (beta) program.
In my experience Heroku works well with socket.io when combined with the Socket.io_Redis plugin and that enabled setting.
In heroku we could use the command heroku maintenance on or off... How can I do it in my AWS EC2 web services? I tried just to stop the server using sudo service nginx stop but I don't like the error page that was displayed. It says error in url. In heroku if i use the maintenance command, the error page will display "Under contruction" "Maintenance" or something like that.
How can I do it in Amazon web services? thanks
You have to do it yourself. AWS does not provide that.
Yeah, so heroku has routing magick, think of the default WebBrick server your rails app is running as running outside of rails. Idk, assuming you use passenger you would'nt really notice this but at a high level, nginx is proxying your apps' port 3000 to port 80 for certain requests. I appologize if you don't know what I mean by that.
So (YOUR APP) ---> (NGINX) -----> (Client)
the advantage here, is that nginx keeps running but during maintience mode they most likely start shooting you pages to static content. If you too run you rails app via a proxy rather than via passenger, than you solution is easy. Stop your WebBrick, mongrel, unicorn, thin (what ever app server here) and setup an error message page for bad gateway errors aka 502 route.
If you use passenger. You could write a location block, that would over ride all your routes to a maintence page and switch Passenger to off in that server block, now rather than serving your app you can serve a static maintence page.
Heroku wraps alot of technology and exposes nice tools, so you'll need to do a bit more ground work to automate your stack. But this is a place to start.