Profile

Cover photo
Graham Dumpleton
Lived in Sydney, NSW, Australia
1,720 followers|191,013 views
AboutPostsPhotosVideos

Stream

 
An introduction to getting Tornado ASYNC web applications running on OpenShift. I also highlight problems with the way that Tornado handles request content buffering and how that can cause potential memory problems. The latter issue on content buffering is relevant to any environment and not just OpenShift. Mentioned in the context of OpenShift as a PaaS due to the lower amount of memory generally available on a PaaS.
3
Mangi Marc's profile photoGraham Dumpleton's profile photo
4 comments
 
PSP is not seen as being best practice these days and you really do not want to be using it. I know of no current package that tries to emulate what it did.
Add a comment...
 
I am always posting stuff about Python, and in particular Python web hosting, WSGI, mod_wsgi and related technologies such as Apache and Docker on my blog site.

Usually I only highlight new posts on Twitter, otherwise relying on notice of the posts goings out by the Planet Python feed aggregator. I have been finding that very people come through to the posts from Twitter with most coming through Planet Python.

I don't usually post anything here on Google+ about the posts, so this time as a bit of an experiment I am seeing whether hits on the post are increased by posting here.

In the current post I am talking about issues related to setting up Apache when proxying to Python web sites using mod_wsgi actually running in Docker instances.

If interested in all the other posts I have done in the past, check out 'blog.dscpl.com.au'.
I have seen a few questions of late being posed about how to setup Apache to proxy to a Python web application running in a Docker container. The questions seem to be the result of people who have in the past previously run A...
7
2
dennis durling's profile photo
 
Yeah! A decent post!
Add a comment...

Graham Dumpleton

Shared publicly  - 
 
OH: I'm looking into Flask to do this, as its documentation seems to suggest that it was designed with Web development in mind.

I would sort of hope that a web framework was designed with web development in mind.

http://stackoverflow.com/a/13169988/128141
5
Add a comment...

Graham Dumpleton

Shared publicly  - 
I know that it has been a very long time since the last mod_wsgi release, July 2010 to be exact, but it is not deceased like its predecessor mod_python. It really has just been 'resting'. Truth is tha...
7
3
Add a comment...

Graham Dumpleton

Shared publicly  - 
 
Some would call what I do at New Relic on the Python agent magic, others would call it an evil hack. If you want to go work in Portland with New Relic and spread that magic (evil), then check out our job posting for a Python agent engineer.

http://newton.newtonsoftware.com/career/JobIntroduction.action?clientId=4028f88b20d6768d0120f7ae45e50365&id=8aa0050635c8e3690135cb01738b4639&gnewtonResize=http://newton.newtonsoftware.com/career/GnewtonResize.htm&source=
New Relic is growing our Python agent team -- a key component for our world's-best app performance monitoring tool. If you know how to pronounce Django, Gunicorn and WSGI, we're interested. If...
1
1
Add a comment...

Graham Dumpleton

Shared publicly  - 
 
The PyCon web summit is coming up in a few weeks. Questions for the panels have been requested and can be posted at:

http://www.google.com/moderator/#16/e=1c9a94

Make sure you get your questions in.

Now, I am not on any of the panels, but it doesn't mean I don't have my own opinions on some of the questions.

As such, leading into the web summit I am going to try and select various questions and post here my own thoughts about them.

The first question I choose to get things rolling is:

"Should Python standardize Request and Response classes in WSGI (or another PEP)?" (http://goo.gl/mod/CNGn)

If the question is whether we should standardise on high level feature packing request/response object such as WebOb/Werkzeug, then my answer is a definite no.

With a specification it needs to be something that is first simple, but also something that can be set and which isn't going to change very quickly and if possible rarely.

When we talk about high level request/response objects which embody a lot of feature functionality, it is inevitable that there will be calls that they evolve, sprouting new features etc.

I somewhat doubt that WebOb and Werkzeug are exactly the same as they were when first written and although we may have learnt a lot since then and may be able to do a better job this time around, one can't know how the web landscape will change and thus how those implementations will need to change.

So, keep such high level request/response objects out of the WSGI specification. If people want to separately agree to settle on using a specific 'implementation' of a request/response object, which is what you are really doing, then by all means do that, but keep that out of the WSGI specification itself.

That said, is there any need for any request/response like objects in WSGI. This is where I feel the answer could still be yes.

If this is done though, they should be very low level and the only purpose should be to help codify the protocol aspects of dealing with the WSGI interface and the mechanisms of implementing WSGI middleware and filters that so many people get wrong when they have to do it themselves. They should not be high level wrappers just to make accessing the request environ data and dealing with response headers easier.

Yes that is a bit vague, but I will have more to say about it in my state of 'WSGI 2' talk at the PyCon web summit.
1
Add a comment...
 
More craziness with Docker. This time using Apache and mod_wsgi to start and manage Docker containers.
5
2
Add a comment...
 
Here is my second post to follow up from the first one (http://blog.dscpl.com.au/2015/06/proxying-to-python-web-application.html) I did yesterday about issues when proxying using Apache to a Python web application running under Docker. In this second post I discuss issues around server redirections when also hosting static files.
1
Add a comment...

Graham Dumpleton

Shared publicly  - 
 
For PyCon AU in August this year I have had a talk accepted with the title 'How do debug tool bars for web applications work?'.

The intent it to dive into Python web application debug toolbars from Django and Flask and explain how they hook into your application and end up being displayed in your browser when making requests against the application.

I will also look at how the plugins/extensions for these toolbars collect information and the issues around that and why such systems are only recommended for development environments.

Now the point of this little post is to solicit ideas for specific things about debug toolbars that people may be interested to hear about.

Am also specifically interested to know what people don't like and your own ideas for how Python web application debug toolbars in general can be improved.

Finally, if a subset of functionality provided by a debug toolbar was safe to use in a controlled way on a production system, would you be interested in such an ability?

Any feedback will be most useful and give me lots to think about as I research the topic for my talk. It could also feed into perhaps doing some work in this area. Thanks in advance.
1
Graham Dumpleton's profile photoSimone Melo's profile photo
3 comments
 
DEUSte abençoe
Add a comment...

Graham Dumpleton

Shared publicly  - 
 
Well this statement from the 'Nginx HTTP Server' book is amusing:

"""There are all sorts of implementations on the web for mainstream programming languages and the FastCGI protocol, due to its well-acknowledged efficiency, is starting to take over server-integrated solutions such as Apache's mod_php, mod_wsgi and many others."""

Amusing because the FastCGI protocol came into existence 10 years before mod_wsgi. It reads as if FastCGI is the new kid on the block that is going to take over the world. From what I have seen over the years use of FastCGI with Python web applications is actually on the decline and not increasing.
5
Radomir Dopieralski (deshipu)'s profile photoCurtis Maloney's profile photo
3 comments
 
I mean, sure, almost everyone in the Django world is using gunicorn, uWSGI or mod_wsgi... FastCGI is what you use if your shared host gives you no choice.
Add a comment...

Graham Dumpleton

Shared publicly  - 
 
Help me test a release candidate for mod_wsgi 3.4. I would like to try and get it out ASAP so as to try to get it into Ubuntu 12.10 before the feature freeze cuts in. If I can't then there will not be a mod_wsgi in Ubuntu by default given that Ubuntu as I understand it is going to use Python 3 by default. The current mod_wsgi 3.3 will not work with Python 3.2 however.

Any feedback to the mod_wsgi mailing list or direct to me. If someone knows what has to happen to even get them to add it into the Ubuntu release this late also please let me know as I have no idea.

http://code.google.com/p/modwsgi/wiki/ChangesInVersion0304
2
7
Clint Byrum's profile photoEbrahim Karam's profile photoGraham Dumpleton's profile photo
13 comments
 
The solution in the StackOverflow post is as I understand it the correct solution. If it isn't solving the problem then use the mod_wsgi mailing list as explained in http://modwsgi.readthedocs.io/en/develop/finding-help.html to post about your issue and what you have tried.
Add a comment...

Graham Dumpleton

Shared publicly  - 
4
3
Tom Brander's profile photoChris Boesch's profile photoGraham Dumpleton's profile photo
3 comments
 
+Chris Boesch If you are doing SingPath again, this time I better remember to turn up. Those US folks really don't know what they are missing. :-)
Add a comment...
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Previously
Sydney, NSW, Australia - Kangaroo Valley, NSW, Australia - Nowra, NSW, Australia
Links
Other profiles
Contributor to
Basic Information
Gender
Male