Pyramid in Production
75 views
Skip to first unread message
Theron Luhn
Mar 8, 2012, 1:35:47 PM3/8/12
to pylons-...@googlegroups.com
Hello all.
I'm about to dive into a pretty big Pyramid project. Before I start, I'm trying to figure out how I'll be running it in production on a VPS or dedicate server. Should I stick with the Apache that comes preinstalled on the server and use mod_wsgi, or leave behind Apache entirely and use Gunicorn? Or something else? Here are some details on my project:
There will be the website frontend. It'll be pretty basic and won't see much traffic. Then there will be the main application, which will see heavy traffic. Each client will have a unique subdomain to access the main app, the main app using the URL to determine the client. There may be a few complimentary applications, such as an employee backend and such, all of which will only see light traffic.
I'll have 4 or so IPs, so it's definitely an option to run each application on its own WSGI server. I have root access, so anything goes ;)
Thanks,
Theron
Jonathan Vanasco
Mar 8, 2012, 1:57:04 PM3/8/12
to pylons-discuss
Not talking about Pyramid / WSGI layer itself...
Assuming that these are just "skinning" a platform for customers, I
would keep away from running each application on a separate IP and try
to handle them via virtualhosts. The rationale for this is:
1. It's easier to step & repeat for new clients
2. If you hit bottlenecks, you can scale out all of one component at
the same time
3. In terms of server maintenance, you'll have different types of
exact setups for machines.
You probably are planning for this already, but i'll mention anyways
-- you'll also want to have Varnish and/or Nginx running in front of
your setup. That'll take care of issues from slow-connections and
offload any static serving from whatever WSGI server you choose.
Assuming that these are just "skinning" a platform for customers, I
would keep away from running each application on a separate IP and try
to handle them via virtualhosts. The rationale for this is:
1. It's easier to step & repeat for new clients
2. If you hit bottlenecks, you can scale out all of one component at
the same time
3. In terms of server maintenance, you'll have different types of
exact setups for machines.
You probably are planning for this already, but i'll mention anyways
-- you'll also want to have Varnish and/or Nginx running in front of
your setup. That'll take care of issues from slow-connections and
offload any static serving from whatever WSGI server you choose.
Theron Luhn
Mar 8, 2012, 7:50:28 PM3/8/12
to pylons-...@googlegroups.com
Each customer is using an identical platform, just with different database. My thought was to use a single application and, using the URL to determine the customer, connect to the customer's database. It would make setup extremely easy to automate, which is one of the goals for the project, as well as saving memory. However, feel free to advise against this.
Nginx does seem like the way to go. Any suggests on a WSGI server to use with it?
Best Regards,
Theron Luhn
Web Developer, Panthr
Tel: 608.205.4223
Email: the...@madebypanthr.com
Web: www.madebypanthr.com
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Krishnakant Mane
Mar 8, 2012, 11:18:49 PM3/8/12
to pylons-...@googlegroups.com, Jonathan Vanasco
I would absolutely recommend nginx for production use.
It does the load balancing pritty well and I had myself asked for advice
on the approach and reverse proxy with paist has given me the best
performance.
Happy hacking.
Krishnakant.
It does the load balancing pritty well and I had myself asked for advice
on the approach and reverse proxy with paist has given me the best
performance.
Happy hacking.
Krishnakant.
On 09/03/12 00:27, Jonathan Vanasco wrote:
> Not talking about Pyramid / WSGI layer itself...
>
> Assuming that these are just "skinning" a platform for customers, I
> would keep away from running each application on a separate IP and try
> to handle them via virtualhosts. The rationale for this is:
> 1. It's easier to step& repeat for new clients
Giacomo Bagnoli
Mar 9, 2012, 3:10:47 AM3/9/12
to pylons-...@googlegroups.com
On Thu, 2012-03-08 at 16:50 -0800, Theron Luhn wrote:
> Each customer is using an identical platform, just with different
> database. My thought was to use a single application and, using the
> URL to determine the customer, connect to the customer's database. It
> would make setup extremely easy to automate, which is one of the goals
> for the project, as well as saving memory. However, feel free to
> advise against this.
>
>
> Nginx does seem like the way to go. Any suggests on a WSGI server to
> use with it?
> Each customer is using an identical platform, just with different
> database. My thought was to use a single application and, using the
> URL to determine the customer, connect to the customer's database. It
> would make setup extremely easy to automate, which is one of the goals
> for the project, as well as saving memory. However, feel free to
> advise against this.
>
>
> Nginx does seem like the way to go. Any suggests on a WSGI server to
> use with it?
we use uWSGI (http://projects.unbit.it/uwsgi/) behind varnish.
uWSGI serves static files and the pyramid apps. Varnish talks directly
to uWSGI via HTTP.
If you use nginx for proxying/balancing/static files/whatever you can
set it up to use the uwsgi protocol (nginx has the handler included
since 0.8.40 IIRC)
Giacomo
Reply all
Reply to author
Forward
0 new messages