-4

Pls read no further if you're squeamish or pious about django!...

It turns out one of the several reasons you shouldn't use django "runserver" development server in production is it's horrible with memory, storing everything it sends or receives indefinitely. Other than that though it works just fine for what my client needs. Seemingly when I change a file and runserver automatically restarts all that memory is freed. So is there an easy way for me to replicate that functionality within the app's code or can I trigger it somehow? A somehow that's less awful than appending a CRLF to a file that it's watching ;) Sorry for even mentioning that Django puritans! BTW dev platform is linux64, deployment is Win64.

Zulu
  • 8,765
  • 9
  • 49
  • 56
Roger Heathcote
  • 3,091
  • 1
  • 33
  • 39
  • 4
    "Doctor, doctor, it hurts when I hit my head with a hammer!" – Gareth Rees Mar 26 '13 at 12:35
  • Thanks for the downvote Gareth, and for sharing the gift of your humour. It is a great honor indeed to be in the presence of somebody who has never used a kludge or bent a rule; long may dogma triumph over pragmatism! – Roger Heathcote Mar 27 '13 at 13:35
  • 2
    Pragmatism: A word meaning "I am ashamed of my actions and wish to cover for this by claiming that they are necessary" – hso Mar 06 '14 at 15:34
  • Dogmatism: positiveness in assertion of opinion especially when unwarranted or arrogant. – Roger Heathcote Mar 08 '14 at 15:35
  • What's ironic is you're insisting using `runserver` is the 'proper' answer as you try and figure out automated restarts because its memory usage is getting out of control. Anyone who comes to this answer with a similar problem, try looking here: http://flask.pocoo.org/docs/deploying/wsgi-standalone/ Other viable options not mentioned in that doc are CherryPy and Waitress – Dan Passaro Aug 14 '14 at 20:01
  • Actually it turns out it manages it just fine without restarting. A large chunk of memory is used initially but it never seems to run out and machine performance is never degraded. System has been running fine for 1.5yrs now and has never required any manual freeing of memory. The original caveats still apply though, and I would strongly caution anyone to avoid hacks like this for anything multiuser, heavy duty or in any way high value or widely deployed! – Roger Heathcote Aug 17 '14 at 15:31

2 Answers2

4

Sadly you're going to ignore this but it bears mentioning for anyone else considering this.

The runserver is not suitable for a production environment. This isn't a "puritan" issue. It's just completely unsuitable for that use and to not set up a real server is just lazy.

The runserver is not stable. Several error types are not handled appropriately and result in the server crashing or becoming stuck.

The runserver cannot serve more than a single request at a time. This includes static file requests. Try having 2-3 people using a runserver host at the same time. Have fun with that.

The runserver has not had any security audits done. It likely has large exploitable holes and no effort has been made to detect or eliminate them.

John
  • 5,166
  • 27
  • 31
  • I know all that John. I mentioned the "many" reasons in my post, tagged it with "anti-pattern" and I specifically asked the pious not to respond. The app is, and will always be single user, low traffic, local and domestic. If it ever crashes I WANT the debugging info right there so I can remote in and see it. This app needs a full power webserver like pac-man needs a SGI workstation. Don't assume you know my needs better than I do, and please try to contain your righteous zeal, it's as distasteful in programming as it is in religion and politics. Now - I must get back to my thought crime! – Roger Heathcote Mar 05 '13 at 08:26
1

Just try to use touch settings.py

sneawo
  • 3,543
  • 1
  • 26
  • 31
  • Good idea, though I'd like to avoid the dependency if I can - the destination platform is windows so I'd need to install a third party touch command. I'll see if I can replicate it by opening it with 'a' and then closing it again. Thanks. – Roger Heathcote Feb 21 '13 at 20:09