4 ms·
I tried to argue that was an implementation detail with sacrifices no matter which direction you go. One could also argue that its problematic to deal with run
by audidude 17y ago
I tried to argue that was an implementation detail with sacrifices no matter which direction you go. One could also argue that its problematic to deal with run-away runtimes with memory issues. The GC does provide an interesting problem I didn't consider. Especially those that over-utilize OS signals. Perhaps the choice of Python was poor for this.
You can still separate it into two fundamental shifts. The first being making a fully asynchronous/event driven module/handler API. This should be done regardless of the runtime module.
The massively-scaled websites I've seen would tip with 4-8 times the sql connections. SQL Server is especially bad at this. It also makes it hard to simply throw additional hardware at the problem.
I guess you could yield on resources from a master process if you have the logic to know their status.
- peoplerock 17y ago@audidude: FYI - your server (www.audidude.com) is either being hit really hard right now or is completely down. Without access to the original post there, this noob can only assume(hope) the discussion is about the Tornado Web Server (http://www.tornadoweb.org/ http://www.tornadoweb.org/). I'm interested in alternatives to Apache, so am looking forward to you being back online. Gracias.