Production sites running TurboGears 2.0
cd34
Is the site Forward Facing or a backend?
How is the site deployed? (mod_wsgi, mod_python, apache2, proxy,
paster, etc)
What templating engine is used? (Genshi, Mako, Jijna, etc)
How have web designers reacted to the constraints placed with the
templating engine you used?
Are static files served by TG2?
How much daily traffic are you seeing? (hundreds, thousands, tens of
thousands)
What type of hardware/hosting? (virtual, virtual machine, dedicated,
cluster, etc)
What implementation issues have you run into?
What steps have been taken to plan for the thundering herd?
In particular, I notice shootq as a TG2 production site, but, they
appear to run cakephp on the forward facing site and I assume they are
using TG2 for the backend. Any input as to why the application
development uses two frameworks?
I looked over 1000corks which is running TG1 based on the post in this
group earlier and possibly runs with CherryPy exposed rather than
running behind another webserving engine and uses Amazon S3 for some
of the images.
I have seen some input regarding using TG2 for facebook and I am
wondering what sort of hardware and environment I'm going to have to
deploy to run the application based on some real-world experience. I
don't need to know the url of the sites, but, would like to get a
little real-world data so that I can plan accordingly.
Antoine Pitrou
> How is the site deployed? (mod_wsgi, mod_python, apache2, proxy,
> paster, etc)
> What templating engine is used? (Genshi, Mako, Jijna, etc)
> How have web designers reacted to the constraints placed with the
> templating engine you used?
> Are static files served by TG2?
the mod_wsgi daemons).
> How much daily traffic are you seeing? (hundreds, thousands, tens of
> thousands)
easily handle 10x more ("uptime" says load average: 0.00, 0.00, 0.00).
> What type of hardware/hosting? (virtual, virtual machine, dedicated,
> cluster, etc)
the application and the PostgreSQL database.
> What implementation issues have you run into?
application. "yolk" will help you know what can be ugraded
(easy_install -U is crap).
> What steps have been taken to plan for the thundering herd?
Mark Ramm
page views a day, it's not yet in production but some performance
testing has been done.
We will deploy with nginx load balancing mog-wsgi instances that serve
up the dynamic content. It's a bit more complicated than this, but
basically nginx will serve up static content, and we're expecting to
be able to easily handle this traffic with a couple of quad core web
server boxes. We could probably get away with one, but we want to
have load balancing for redundancy not just for performance.
We're not using ToscaWidgets, the transaction manager, and have been
using mongodb for data storage. We had some previous templates
written in Jinja, so we're using that for templates, otherwise we'd
either use Mako or genshi, but without any match tags.
There's a bit of caching in the app, but it's not actually necessary
for the current loads, but might be nessisary for the "thundering
hoards."
I'm looking forward to being able to talk about this more, but you'll
have to wait a few more weeks for details.
--Mark Ramm
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Mark Ramm
Oh and there's http://civx.csh.rit.edu/ which is all TG2 hotness ;)
Bryan Koroleski
reports" application since last July. Right now, it still runs on the
alpha 1 release.
> Is the site Forward Facing or a backend?
able to tell the difference between the Python-served pages and the
PHP-served pages unless you looked at the server headers.
> How is the site deployed? (mod_wsgi, mod_python, apache2, proxy,
> paster, etc)
Getting things working under a 64-bit system was not a priority when
we originally deployed, and mod_proxy was the quickest way to deploy.
> What templating engine is used? (Genshi, Mako, Jijna, etc)
after the SQLAlchemy and Genshi changes came through. We switched to
the alpha because of auth/auth issues.
> How have web designers reacted to the constraints placed with the
> templating engine you used?
designer created the site's design with XHTML and CSS, and developers
turned that into the templates needed. Right now, there are both
Genshi and Smarty templates for the site, which means differences pop
up from time to time.
> Are static files served by TG2?
> How much daily traffic are you seeing? (hundreds, thousands, tens of
> thousands)
fifty hits per day.
> What type of hardware/hosting? (virtual, virtual machine, dedicated,
> cluster, etc)
the application runs on.
> What implementation issues have you run into?
gave up on that after a few hours. I'm sure the Routes stuff works a
lot better than it did in the first alpha release. Not being able to
configure Genshi's html rendering mode was also a huge pain. Trying to
write your own repoze.who plugins for custom identity sources can be
difficult as well, but I still like repoze.who more than the old
identity system.
Deploying the application on OS X Server was painful to say the least.
This had a little to do with the order in which things were installed,
a little to do with the fact that we decided not to use virtualenv,
and a lot to do with Apple's crazy python deployment.
> What steps have been taken to plan for the thundering herd?
I do cache a lot of stuff. The queries we run for our reports can be
pretty big.
Jonathan LaCour
We have been using TG 2.0 at ShootQ (shootq.com). The marketing
website is PHP based, but the application is all TG 2.0. Its a very
large and sophisticated application that we still think is very easy
to use :)
> Is the site Forward Facing or a backend?
Forward facing with thousands of users.
> How is the site deployed? (mod_wsgi, mod_python, apache2, proxy,
> paster, etc)
We use paste behind nginx on our application servers, which are
then behind a hardware load balancer which also provides SSL
acceleration.
> What templating engine is used? (Genshi, Mako, Jijna, etc)
Genshi for most of the application with Mako for performance
sensitive areas.
> How have web designers reacted to the constraints placed with the
> templating engine you used?
We love Genshi, and wouldn't use anything else if it performed
faster. I would like to see this become a big focus of TG in the
future. A faster version of Genshi!
> Are static files served by TG2?
No, they are served by nginx.
> How much daily traffic are you seeing? (hundreds, thousands, tens
> of thousands)
Tens of thousands of requests.
> What type of hardware/hosting? (virtual, virtual machine,
> dedicated, cluster, etc)
We are hosted on Joyent accelerators, which are essentially highly
optimized Solaris Zones.
> What implementation issues have you run into?
At the time we started, there was no transaction manager in TG 2.0.
In addition, we use MySQL master-slave replication for redundancy
and load balancing. We ended up rolling our own WSGI middleware
which:
1. Wraps all POST and DELETE requests in a transaction
automatically,
and routes all SQL to the MySQL master.
2. Routes all non-transactional (read) requests to a MySQL slave.
3. Allows us to flag certain requests as requiring the next
request to certain URIs to read from the MySQL master. This
is implemented as a decorator and a utility function. This is
so that writes quickly followed by reads don't suffer from
replication delay.
This is all possible thanks to WSGI and Elixir/SQLAlchemy making it
very easy to do.
In addition, we ran into issues early on with static resources being
served up too frequently and how to deal with this. We ended up
rolling our own little helper functions to generate URIs for our
static resources that include a "revision stamp" from our source
control repository. We then utilize nginx to force this content to
be cached by the browser. This makes it so that most of our static
content is requested only once by the browser until we manually
force it to be fetched again by changing the "stamp".
> What steps have been taken to plan for the thundering herd?
We make use of memcached, have a highly redundant infrastructure,
and have multiple instances of the application on each application
server, plus multiple application servers behind a hardware load
balancer.
We can scale horizontally by adding application servers and MySQL
slaves, and vertically by "turning up" the resources available to
our virtualized servers. In addition, most services run on their own
server (we have over 9 servers we currently run on).
We make use of memcached to cache intensive data like reports, and
have written a monitoring system that alerts us when resource usage
on our servers exceed a certain threshold. In addition, this system
has an OS X dashboard widget we implemented that allows us to see
the current status of all processes and resource usage across our
servers at a glance.
We also make use of Amazon S3 to keep user-generated content out of
our systems and our database, which allows us to scale up to many
hundreds of thousands of users without any concern.
> In particular, I notice shootq as a TG2 production site, but, they
> appear to run cakephp on the forward facing site and I assume
> they are using TG2 for the backend. Any input as to why the
> application development uses two frameworks?
We do this exact thing because, honestly, a marketing website
is very content driven, and its really not a great use case for
TurboGears in my opinion. There's a great deal of immediacy to PHP,
and being able to quickly push an update to the website without
having to restart the paste processes is a big win.
> I have seen some input regarding using TG2 for facebook and I
> am wondering what sort of hardware and environment I'm going to
> have to deploy to run the application based on some real-world
> experience. I don't need to know the url of the sites, but,
> would like to get a little real-world data so that I can plan
> accordingly.
Take a look at Joyent. They offer free accelerators for Facebook
applications, last I checked. They are nice, as long as you aren't
doing heavy I/O.
Best of luck to you!
--
Jonathan LaCour
http://cleverdevil.org
http://shootq.com
Iain Duncan
>
> I know quite a bit about tg2 app that will serve 25 million dynamic
> page views a day, it's not yet in production but some performance
> testing has been done.
>
> We will deploy with nginx load balancing mog-wsgi instances that serve
> up the dynamic content. It's a bit more complicated than this, but
> basically nginx will serve up static content, and we're expecting to
> be able to easily handle this traffic with a couple of quad core web
> server boxes. We could probably get away with one, but we want to
> have load balancing for redundancy not just for performance.
>
> We're not using ToscaWidgets, the transaction manager, and have been
> using mongodb for data storage. We had some previous templates
> written in Jinja, so we're using that for templates, otherwise we'd
> either use Mako or genshi, but without any match tags.
If you don't mind me asking, what did you decide to use instead of
ToscaWidgets and what were your reasons?
Thanks
Iain
Sergei Beilin
It's in an early beta stage, but new modules are deployed into
production every week.
This project is my team's (and my own) first TG2 project. We started
only in January and never had no experience with TG, Elixir or even
Pylons or any other Python framework before.
> Is the site Forward Facing or a backend?
> How is the site deployed? (mod_wsgi, mod_python, apache2, proxy,
> paster, etc)
> What templating engine is used? (Genshi, Mako, Jijna, etc)
> How have web designers reacted to the constraints placed with the
> templating engine you used?
> Are static files served by TG2?
small PNGs.
> How much daily traffic are you seeing? (hundreds, thousands, tens of
> thousands)
not more. Plus some JSON requests.
> What type of hardware/hosting? (virtual, virtual machine, dedicated,
> cluster, etc)
in a software mirror; it also acts as a mailserver (MTA+LDA+IMAP),
which makes most of load. It runs Linux 2.6.24 and Python 2.5. The
database server is much faster, it's a dual Xeon with hardware SATA
mirror, running Windows Server and MySQL 5.1.
> What implementation issues have you run into?
> What steps have been taken to plan for the thundering herd?
--
Sergei
Uwe C. Schroeder
TG1. I did some testing with TG2 and I think the general concepts around
these questions can be applied to both versions.
On Friday 29 May 2009, cd34 wrote:
> What are some sites using TurboGears 2.0 in a production setting?
>
> Is the site Forward Facing or a backend?
Facing forward.
> How is the site deployed? (mod_wsgi, mod_python, apache2, proxy,
> paster, etc)
Currently nginx as load balancer distributing the load on 4 cherrypy
instances. For TG2 this would be paste, which is faster than cherrypy V2 used
in TG1
> What templating engine is used? (Genshi, Mako, Jijna, etc)
Genshi.
> How have web designers reacted to the constraints placed with the
> templating engine you used?
Web designers? Hehe. Ok, I'm not a web-designer, but I wrote all the stuff
myself. I doubt a web-designer will face a lot of issues. The design is
generally something you put into place and then have someone who can program
set up the templates. Genshi templates are very easy and require only basic
programming skills - hey, even my wife can handle that and she's not a
programmer (although she has a decent understanding of HTML and CSS)
> Are static files served by TG2?
No. Static files are served by nginx with a separate subdomain for images (the
site is image-heavy). Subdomains for things like images are generally a good
idea, because most browsers have a limitation towards how many concurrent
connections they use for one domain (usually a max of 4). If you have images
or videos served from a second domain you can get browsers to open more
concurrent connections. Broadband gives most users the bandwidth to do that,
so in the end your page loads faster for a better user-experience.
> How much daily traffic are you seeing? (hundreds, thousands, tens of
> thousands)
Depending on the day it goes up to 80.000 pages a day with about 60 hits per
page.
> What type of hardware/hosting? (virtual, virtual machine, dedicated,
> cluster, etc)
Dedicated servers.Two dual dual-core (4 cores total) machines with 4GB memory
each. Another two virtual dedicated servers for image and ad-serving.
> What implementation issues have you run into?
Not a lot with TG1. Porting to TG2 will take a bit of a rewrite, particularly
in the area of SA (their API changed, so using the newer version requires
rewriting all queries) and identity handling. Neither of the two should be an
issue if you start out with TG2.
> What steps have been taken to plan for the thundering herd?
The setup allows to just plug in more servers. The website is unlikely to grow
suddenly, it's more a "permanent growth over time" kinda site. Particularly
with the recent change to avoid Genshi "match" tags (suggested by Mark Ramm),
we now can handle roughly 100.000 pages a day. The moment we hit 80.000 a day
on a permanent basis we'll just add another server and load-balance with
nginx or pull the database onto another dedicated server.
In a TG2 setting I'd do some stress testing with mod_wsgi. It's supposed to be
faster from what I read.
Be aware that TG (either version) is memory hungry like many other similar
app-engines/frameworks. So plan on as much memory as you can get within your
budget. We started with 2GB memory per machine but had to upgrade to 4GB
after a couple of months. Also consider your database in that calculation.
Budget permitting I'd opt for a separate database server that is directly LAN
connected to a second NIC of the servers. That way you'd have one machine
just to handle database. In a combined setup (as we currently use), you have
to up the memory to allow for decent database performance - that also depends
on what database you use (we use postgresql for many reasons, consistent
performance being one of them, having many features that you can trust your
payroll with being another. Mysql never was a choice for us. It's faster in
simple read-operations, but IMHO lacks seriously when it comes to data
integrity and error checking. But that's a discussion for a database list)
percious
> Is the site Forward Facing or a backend?
> paster, etc)
> What templating engine is used? (Genshi, Mako, Jijna, etc)
> How have web designers reacted to the constraints placed with the
> templating engine you used?
> Are static files served by TG2?
by permissions. I also serve up custom tarballs.
> How much daily traffic are you seeing? (hundreds, thousands, tens of
> thousands)
> What type of hardware/hosting? (virtual, virtual machine, dedicated,
> cluster, etc)
> What implementation issues have you run into?
> What steps have been taken to plan for the thundering herd?
nginx.
>
> In particular, I notice shootq as a TG2 production site, but, they
> appear to run cakephp on the forward facing site and I assume they are
> using TG2 for the backend. Any input as to why the application
> development uses two frameworks?
Just wanted to add that I think that you should not have too many
challengings getting TG2 to scale. Also, although my internal website
is fairly simple, It is fairly complex, implementing: RestController,
CrudRestController, sprox, tw.dojo, tgext.admin, tw.timeline,
tw.timeplot, tw.dynforms.
I use WebTest to test all of the pages in my application. Using
WebTest in conjunction with coverage, I am able to have a pretty good
certainty that my entire app is working when it comes time to
release. I think this is one place where TG2 particularly shines.
TG2 helps you manage complexity, and it gets out of your way when you
need it to.
cheers.
-chris
Daniel Fetchinson
Only Mark can answer that question but I also don't use any widgets.
Widgets are typically used for UI elements like forms and such and I
use a javascript library for these things. This means that the web app
only sends JSON that define a UI (imagine a simple dict) and on the
client a javascript library consumes this JSON and presents the user
with the appropriate elements. I use extjs actually.
Reasons: providing a UI definition from the web app as opposed to
rendered html allows connecting to your web app with clients that are
not web browsers. For example I distribute a desktop app that users
can use to talk to the web app. This desktop app also understands the
JSON UI definition format I use so it can present the user with a UI
of its own too.
This setup makes your web app code much cleaner, more maintainable and
more extendable. I understand that widgets, tosca in particular, are
designed to not pollute your web app code and separate concerns but
having all UI stuff on the client in javascript code is even better in
my opinion. Complex web apps have javascript in them anyway. And these
days there are really fantastic javascript libraries out there that
make UI design absolutely painless, extjs is just one example, there
are tons more.
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Jim Steil
May I ask how you handle authentication with the Javascript backend? I'm interested in doing some Flex front-ends but haven't had the time to dig into the authentication integration with the TG backend.
-Jim
Florent Aide
<jonatha...@cleverdevil.org> wrote:
[...]
>> How have web designers reacted to the constraints placed with the
>> templating engine you used?
>
> We love Genshi, and wouldn't use anything else if it performed
> faster. I would like to see this become a big focus of TG in the
> future. A faster version of Genshi!
chameleon.genshi is an implementation of genshi that has speeds in the
range of mako. The only thing is that it is missing i18n support ATM.
We should concentrate on helping chameleon people to get the hooks in
place to support i18n...
Florent.
Michael Brickenstein
On 30 Mai, 01:48, cd34 <mcd...@gmail.com> wrote:
> What are some sites using TurboGears 2.0 in a production setting?
>
> paster, etc)
> templating engine you used?
Even more, most images on the site are not files but are stored in the
db and returned
by a controller method,
> thousands)
> cluster, etc)
> What implementation issues have you run into?
Michael
Jonathan LaCour
> chameleon.genshi is an implementation of genshi that has speeds
> in the range of mako. The only thing is that it is missing i18n
> support ATM. We should concentrate on helping chameleon people to
> get the hooks in place to support i18n...
I spent several infuriating hours attempting to get this to install
once, and completely gave up on it. I think it had to do with the
fact that lxml is one of the most preposterously difficult to build
libraries in the world. But, I could be misremembering.
Also, IIRC, the documentation was totally non-existent on how one
might actually use it with TG.
Florent Aide
Well... I installed it on dev machines for Windows, Linux and MacosX
so I don't share your POV. Even if I concede it is not the easiest lib
to install.
As for the TG2 support it is in the core of the renderers... and I
could provide more info and even real directions if you transformed
that into some helpful docs for us :) deal?
Florent.
Jonathan LaCour
> Well... I installed it on dev machines for Windows, Linux and
> MacosX so I don't share your POV. Even if I concede it is not the
> easiest lib to install.
Of course, not 30 seconds after I posted this, I tried to
easy_install it on my Mac, and it worked like a champ. So it looks
like things have changed since I last tried it out, at least on the
Mac. I'll have to try Solaris at some point soon as well.
> As for the TG2 support it is in the core of the renderers...
> and I could provide more info and even real directions if you
> transformed that into some helpful docs for us :) deal?
We're still using a slightly old version of TG 2.0, and are using
legacy "buffet" support to render templates. One of these days we'll
upgrade to TG 2.0 final, and I'll definitely take you up on it :)
Any ideas on how we might be able to try chameleon.genshi through
the buffet support would be helpful, of course :)
Derick Eisenhardt
widgets for the UI like Daniel's site, although we use Dojo rather
than ExtJs.
On Jun 1, 8:55 pm, Jim Steil <st...@mailbag.com> wrote:
> May I ask how you handle authentication with the Javascript backend?
> I'm interested in doing some Flex front-ends but haven't had the time to
> dig into the authentication integration with the TG backend.
the functions that call for that JSON or save it back to the server.
If a particular user doesn't have permission to pull a certain piece
of data from the server, the client-side can't really do anything
without it.
Iain Duncan
>
> Florent Aide wrote:
>
> > Well... I installed it on dev machines for Windows, Linux and
> > MacosX so I don't share your POV. Even if I concede it is not the
> > easiest lib to install.
>
> Of course, not 30 seconds after I posted this, I tried to
> easy_install it on my Mac, and it worked like a champ. So it looks
> like things have changed since I last tried it out, at least on the
> Mac. I'll have to try Solaris at some point soon as well.
I know that recently the repoze guys have been cutting out lxml
dependencies and other hard to compile issues, might have been something
like that.
Iain
Iain Duncan
Does anyone know of any good tutorials for this kind of desing? I'd love
to check out some simple code.
Iain
Mark Ramm
>> using mongodb for data storage. We had some previous templates
>> written in Jinja, so we're using that for templates, otherwise we'd
>> either use Mako or genshi, but without any match tags.
>
> If you don't mind me asking, what did you decide to use instead of
> ToscaWidgets and what were your reasons?
We're not really doing any traditional web-forms, everything is
ajax/jquery and TW introduced overhead that we did not need.
We also needed to minify/concatenate all our JS resources, use css
sprites (small images all concatenated into a single file and
displayed in the right places by css), and minified css, all of which
was easier if we controlled all that stuff.
--Mark Ramm
Jim Steil
Thanks
-Jim
Diez B. Roggisch
there is no difference between an ajax-call or a "normal" http-request,
so whatever the browser transmits to persuade your web-apps that the
request is authenticated and authorized is transmitted as well.
repoze.who usually uses cookies afaik.
Diez
Uwe C. Schroeder
Actually the sprites aren't an issue in TG1 or TG2. IMHO the issue is css and
js compression/combination. Zope does this quite nicely, but AFAIK TW in
combination with TG does not (haven't checked recently).
That would be a major point on my wishlist. At least if TW could combine and
compress js/css would already help a lot. Having some kind of plugin/entry
point to TG that allows putting all those resources together would be even
better. That would allow me to strip at least 20 requests per page...
Uwe
Daniel Fetchinson
Authentication is done in the same way as without any javascript
stuff. I.e. you decorate the methods of your controllers with the
appropriate @identity.require decorators or wrap the entire controller
in identity.SecureObject (these are the tg1 names, maybe tg2 is
different, but same concept).
The javascript client code will post an http request and one of your
methods will return JSON. If the user is not authenticated you send
some error message in the JSON response, the client code will check
this, if it's there, display an error message or redirect or whatever.
If there is no error, then the user was authenticated and the client
code can start processing the legitimate JSON response it asked for.
Daniel Fetchinson
There is no magic here. You write controllers to return html (A) and
other controllers to return JSON (B). Let's say html (A) is just a
couple of <div> elements and a reference to a static javascript source
(C). The source (C) will contain javascript code that will send http
requests to (B), get the response, process it and, for example, create
UI elements in the <div> elements of (A). Voila la, you just generated
a dynamic UI entirely from javascript client code.
The advantages are clear, controller (A) only returns a bare html
source and doesn't worry about anything else, while controller (B)
only returns JSON that defines your UI. And the client code (C) will
actually render the UI but that is only being done on the client, i.e.
the web browser, where this kind of stuff really belongs. Your
controller code is not polluted with all sorts of UI stuff, it's all
being done on the client using javascript client code.
Rodney Haynie
Daniel Fetchinson wrote:
>>> I use extjs actually.
>>>
>>> Reasons: providing a UI definition from the web app as opposed to
>>> rendered html allows connecting to your web app with clients that are
>>> not web browsers. For example I distribute a desktop app that users
>>> can use to talk to the web app. This desktop app also understands the
>>> JSON UI definition format I use so it can present the user with a UI
>>> of its own too.
>>>
>>> Daniel,
If you don't mind saying, did you use some library to "understand" the
JSON UI Definition in your desktop app? Or did you code for it.
Is the desktop app written in Python?
Thanks.
-Rodney
Daniel Fetchinson
No, I use a very simple UI definition format that I invented myself,
it's nothing fancy, in python it looks like this for forms:
fiels = [ dict( type='text', name='name', label='Your Name',
not_empty=True ), ........ ]
so it's a list of dicts, each dict defining a form entry. For example
a radio button is defined like this:
dict(
type='radio',
name='sex',
label='Sex',
value=[
dict( name='male', label='Male', checked=False ),
dict( name='female', label='Female', checked=False ) ],
not_empty=False )
These is then parsed by javascript in an obvious way, without using
any library. The desktop app is also written in python and this python
app parses the above list the same way and presents the user with the
appropriate form.
There are sophisticated xml formats for storing all sorts of
sophisticated UI's (for example wx does this I think) but this kind of
stuff is too heavy weight for me, all I need are forms, for which the
above very simple model is sufficient.
Derick Eisenhardt
> So, are you then passing a userid and password with every request? Do
> you just cache the userid and a hash of the password in a cookie or
> something?
the past couple weeks ;)
We use Repoze's built in session cookies primarily for this. Basically
a hash is generated and stored in the cookie during the session so
that the server knows you are who you say you are. Beyond this there's
also another nice feature that checks to see what your previous page
was (where you came from), and this should partially help against the
possibility of a cookie hijack to some extent. On top of all this our
site is end to end encrypted thru SSL (https). The only page that is
unencrypted is the welcome page (index), from which you can move to
the login in page. If you are not logged in, or your cookie has become
invalid you are automatically redirected to the login page.
Our project is a pretty complex accounting app (think like Quickbooks,
but a web app), so security is a very big concern for us. I think all
the other bases of what I'd have to tell you have already been covered
by other people's responses ;)
- Derick