<div dir="ltr">Graham, <div><br></div><div>Many thanks for your awesome and honest response.</div><div>With or without the fact that you are the <a href="http://code.google.com/p/modwsgi/">mod_wsgi</a> project owner; I guess that you are also agree with the bottom line:</div>
<div>mod_wsgi seems better for Django usage within Apache web server. </div><div>If someone want to use mod_python, he might want to take a look at your <a href="http://blog.dscpl.com.au/search/label/django">blog</a>.</div>
<div><br></div><div>You are more then welcome to one of our next meeting (In Israel..)</div><div><br></div><div>Ahik<br><br><div class="gmail_quote">On Tue, Sep 22, 2009 at 2:16 PM, Graham Dumpleton <span dir="ltr">&lt;<a href="mailto:graham.dumpleton@gmail.com">graham.dumpleton@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
A few corrections.<br>
<div class="im"><br>
On Sep 21, 6:43 pm, Idan Gazit &lt;<a href="mailto:i...@pixane.com">i...@pixane.com</a>&gt; wrote:<br>
&gt; Short answer: mod_wsgi is awesome. I don&#39;t use mod_python anymore if I  <br>
&gt; can help it.<br>
&gt;<br>
&gt; Long(er) answer: mod_wsgi isn&#39;t the perfect solution but it works much  <br>
&gt; better than mod_python right now.<br>
&gt;<br>
&gt; With mod_python, each apache thread/worker process/etc must load a  <br>
&gt; copy of the python interpreter into memory.<br>
<br>
</div>No, that isn&#39;t quite what happens. Read:<br>
<br>
  <a href="http://blog.dscpl.com.au/2009/03/python-interpreter-is-not-created-for.html" target="_blank">http://blog.dscpl.com.au/2009/03/python-interpreter-is-not-created-for.html</a><br>
<br>
Overall, mod_python and mod_wsgi behave exactly the same. The only<br>
difference is that by default, mod_python uses one Python sub<br>
interpreter per virtual host, where as mod_wsgi by default allocates a<br>
sub interpreter to each mounted WSGI application.<br>
<div class="im"><br>
&gt; This has several bad side  <br>
&gt; effects:<br>
&gt;<br>
&gt; 1. If you have more than one site run off the same apache, then EVERY  <br>
&gt; instance of apache threads/workers will have a whole python  <br>
&gt; interpreter in their context.<br>
<br>
</div>Each process will have a Python interpreter for the relevant context,<br>
not each thread.<br>
<div class="im"><br>
&gt; That&#39;s quite a few megs of ram per  <br>
&gt; request, even requests for my_small_image.jpg.<br>
<br>
</div>You shouldn&#39;t be serving static files from your Python web<br>
application. When Apache is properly configured, the serving of static<br>
files doesn&#39;t go anywhere near the Python code.<br>
<div class="im"><br>
&gt; 2. If you have more than one python site on the same apache, you  <br>
&gt; cannot isolate them from one another, because the same python  <br>
&gt; interpreter is loaded for them all.<br>
<br>
</div>Wrong. By default mod_python uses one per virtual host. You can use<br>
the mod_python PythonInterpreter directive to override this and<br>
allocate a separate sub interpreter for each application instance.<br>
<br>
This isn&#39;t necessary with mod_wsgi as a separate sub interpreter per<br>
mounted WSGI application is the default already.<br>
<div class="im"><br>
&gt; What happens if you need v1.0 of a  <br>
&gt; library for this app and v1.1 for another? Can&#39;t do it with mod_python  <br>
&gt; AFAIK.<br>
<br>
</div>Use PythonInterpreter directive properly and you can do this.<br>
<div class="im"><br>
&gt; In mod_wsgi, each site can have its own private python  <br>
&gt; virtualenv.<br>
<br>
</div>Only by virtue of fact that each WSGI application by default gets a<br>
separate sub interpreter.<br>
<div class="im"><br>
&gt; There&#39;s a lot of smaller reasons for using mod_wsgi but based on those  <br>
&gt; two reasons, I would warmly recommend the usage of mod_wsgi today.  <br>
&gt; I&#39;ve found it to be stable, efficient, and much less resource-<br>
&gt; intensive than mod_python.<br>
<br>
</div>I&#39;d also suggest reading:<br>
<br>
  <a href="http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html" target="_blank">http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html</a><br>
  <a href="http://code.google.com/p/modwsgi/wiki/VirtualEnvironments" target="_blank">http://code.google.com/p/modwsgi/wiki/VirtualEnvironments</a><br>
  <a href="http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading" target="_blank">http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading</a><br>
<br>
Graham<br>
<div class="im"><br>
&gt; -I<br>
&gt;<br>
&gt; On Sep 21, 2009, at 11:19 AM, Ahik Man wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &gt; Hello,<br>
&gt;<br>
&gt; &gt; There are some articles (like the one bellow) that claimed that  <br>
&gt; &gt; mod_wsgi is better then mod_python.<br>
&gt; &gt; Is anybody having a real experience with comparison like that?<br>
&gt; &gt; Any recommendations related to mod_wsgi?<br>
&gt;<br>
&gt; &gt;<a href="http://www.technobabble.dk/2008/aug/25/django-mod-wsgi-perfect-match/" target="_blank">http://www.technobabble.dk/2008/aug/25/django-mod-wsgi-perfect-match/</a><br>
&gt;<br>
&gt; &gt; Thanks,<br>
&gt; &gt; Ahik<br>
&gt;<br>
&gt; &gt; &gt;<br>
&gt;<br>
&gt;<br>
</div>&gt;  smime.p7s<br>
&gt; 3KViewDownload<br>
<div><div></div><div class="h5"><br>
<br>
</div></div></blockquote></div><br></div></div>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google Groups &quot;PyWeb-IL&quot; group. <br> To post to this group, send email to pyweb-il@googlegroups.com <br> To unsubscribe from this group, send email to pyweb-il+unsubscribe@googlegroups.com <br> For more options, visit this group at http://groups.google.com/group/pyweb-il?hl=en<br>
-~----------~----~----~----~------~----~------~--~---<br>
<br>