Thank you Graham. Thanks to Jason who has been very generous of his time and explained the matter very thoroughly and gave me practical working examples. Great community ! Kind regards to all, René
On Tuesday, August 5, 2014 6:55:33 AM UTC+2, Graham Dumpleton wrote: > > Great. And thanks again. > > Graham > > On 05/08/2014, at 1:14 PM, Jason Garber <[email protected] <javascript:>> > wrote: > > Hi Graham, > > I was able to spend a couple of hours with Rene covering all the points > from nginx to apache to mod_wsgi to the application object and real world > usage of threads and processes and load and such. > > So I think he is in good shape for now. > > Thanks! > Jason > Hi Rene > > Do I need to comment further on this, or did you get all the answers you > were after? > > Jason, thanks for stepping in and dealing with this. Being at a conference > at the time and so quite busy, was much appreciated. > > Graham > > On 04/08/2014, at 4:32 AM, Jason Garber <[email protected] <javascript:>> > wrote: > > My apologies to the list as I did not realize you were all copied. Will > go off-list now. > > JG > On Aug 3, 2014 9:29 AM, "Jason Garber" <[email protected] <javascript:>> > wrote: > >> Hi Rene, >> >> I will be a bit later today as the family and I are going out now. I >> will contact you when I return - likely around 2:00 my time (+/-) >> >> Thanks! >> Jason >> On Aug 3, 2014 9:27 AM, <[email protected] <javascript:>> wrote: >> >>> Thank you Jason. I registered on Skype (rene.heymans). >>> You can try around noon your time (6PM mine). >>> Till then. >>> Regards, René >>> >>> On Saturday, August 2, 2014 9:16:29 PM UTC+2, Jason Garber wrote: >>>> >>>> We can do a gotomeeting. Perhaps around lunchtime eastern on Sunday? >>>> On Aug 2, 2014 2:08 PM, <[email protected]> wrote: >>>> >>>>> Hello Jason, >>>>> >>>>> Thank you very much for your kind and swift offer. I'll do it gladly >>>>> ... but I need to set-up Skype on my station :-( and register a Skype >>>>> account. >>>>> I'm an old-timer and my only contact is Gmail. I have no G+, no >>>>> Facebook, no Twitter, ... >>>>> >>>>> What is your preferred day and time for a Skype call. >>>>> I live in the Paris-Luxembourg-Brussels time zone. For instance it is >>>>> now Saturday Aug. 2, 20:05. >>>>> >>>>> When you say privately, I suppose a one-to-one call on Skype and I >>>>> suppose I can easily find your name there. >>>>> >>>>> Have a nice Sunday and thanks again, >>>>> >>>>> René >>>>> >>>>> On Saturday, August 2, 2014 6:35:33 PM UTC+2, Jason Garber wrote: >>>>>> >>>>>> Hi Rene, >>>>>> >>>>>> I offer to do a skype call with you to review all of this as I have >>>>>> been there done that and have a crisp understanding of all the working >>>>>> parts. >>>>>> >>>>>> Contact me privately if you want to do this. >>>>>> >>>>>> Thanks, >>>>>> Jason >>>>>> On Aug 2, 2014 12:32 PM, <[email protected]> wrote: >>>>>> >>>>>>> Dear Graham & al., >>>>>>> >>>>>>> Congratulations for your software and documentation. I have however >>>>>>> some difficulties as outlined in the subject caption. >>>>>>> >>>>>>> I'm building a case study for an application on an intranet within a >>>>>>> company where the users would interact with their browser communicating >>>>>>> with the Apache2/mod_wsgi server (daemon mode + multi-threads). >>>>>>> >>>>>>> However I'm afraid I'm misunderstanding some important underlying >>>>>>> concepts of the architecture. Please allow me to give an example and to >>>>>>> give you my thoughts - which could go wrong somewhere. >>>>>>> >>>>>>> *Part 1:* >>>>>>> >>>>>>> I wrote a simple HTML page with a one field input form. >>>>>>> >>>>>>> In my `environment` dictionary, I have, among other key/value pairs, >>>>>>> the following: >>>>>>> >>>>>>> REQUEST_METHOD: POST >>>>>>> REQUEST_URI: /core/my-wsgi-app >>>>>>> mod_wsgi.callable_object: application >>>>>>> >>>>>>> The first two values come obviously from my html <form >>>>>>> action="core/my-wsgi-app" method="post">...</form>, and the third value >>>>>>> is >>>>>>> the default value in the configuration directive (WSGICallableObject >>>>>>> application). >>>>>>> >>>>>>> In my my-wsgi-app script, I have of course: >>>>>>> >>>>>>> def application (environment, start_response): >>>>>>> [my code here] >>>>>>> return [response_body] >>>>>>> >>>>>>> So all is fine and works well but there is something I don't get (I >>>>>>> mean I haven't fully assimilated), certainly in a multi-users, >>>>>>> multi-threads, ... environment. The main question is about the >>>>>>> WSGICallableObject. >>>>>>> >>>>>>> >>>>>>> The documentation (https://code.google.com/p/modwsgi/wiki/ >>>>>>> ConfigurationDirectives#WSGICallableObject) says "*The >>>>>>> WSGICallableObject directive can be used to override the name of the >>>>>>> Python >>>>>>> callable object in the script file which is used as the entry point >>>>>>> into >>>>>>> the WSGI application.*" [underlining is mine]. For me the WSGI >>>>>>> application is the whole application: when finished the target >>>>>>> application >>>>>>> I'm case studying could serve one hundred users, delivering thousands >>>>>>> of >>>>>>> pages built dynamically over hundreds of SQL tables, ... Am I right in >>>>>>> thinking than one entry point would be fit for such purpose. The size >>>>>>> of >>>>>>> the application is such that I already opted for a daemon configuration >>>>>>> with multi-threads (I do not wish to have users waiting in a single >>>>>>> queue >>>>>>> because one of them is building a page that takes seconds to assemble). >>>>>>> >>>>>>> Having one single callable object seems to give me these only 4 >>>>>>> options: >>>>>>> >>>>>>> 1) Have only one single REQUEST_URI, say /core/my-wsgi-app, where >>>>>>> only one callable object (function, class, ...) is used under the one >>>>>>> and >>>>>>> same name (application). In such case that callable object is the one >>>>>>> and >>>>>>> only full single entry point to the overall application (thousands of >>>>>>> pages >>>>>>> built dynamically) and I must care for checking, authorisation, >>>>>>> parsing, >>>>>>> dispatching, ... and finally assembling the response and returning it. >>>>>>> I'm >>>>>>> wondering if this single script/callable-object could become a >>>>>>> bottleneck. >>>>>>> It is the concern I've just expressed. Of course, Python can handle >>>>>>> hundreds of function calls and instance calls. This option makes me >>>>>>> doubt I >>>>>>> fully understand the mechanism. I call this option N to 1. >>>>>>> >>>>>>> 2) Have various REQUEST_URI (even one per page if need be) and in >>>>>>> each called script, there would be one callable object with the same >>>>>>> name >>>>>>> ("application" as defined in the WSGICallableObject directive). In >>>>>>> that case, I could create a callable instance of a base class but that >>>>>>> instance should bear the application name and use the two positional >>>>>>> arguments passed by mod_wsgi. This option, if used exclusively, seems >>>>>>> to me >>>>>>> like a normal "CGI static serving", i.e. one request activates one >>>>>>> script >>>>>>> (the whole logic and dynamism is in the script). This point too makes >>>>>>> me >>>>>>> doubt I understand the real nature of WSGI. I call this option N to N. >>>>>>> >>>>>>> 3) One could combine option 1 and 2 to create more dynamism without >>>>>>> risking the potential (?) bottleneck of option 1 when used alone. I >>>>>>> call >>>>>>> this option N to M (<<N) >>>>>>> >>>>>>> 4) There seems to be a possibility to define the WSGICallableObject >>>>>>> per directory. My understanding is that the REQUEST_URI belonging to a >>>>>>> directory (and its sub-directories) would use that callable object >>>>>>> name. >>>>>>> This means for instance that any URI of the form /core/section-1/abc >>>>>>> would >>>>>>> have a callable object Application_1, while any URI under >>>>>>> /core/section-N/... would have a callable object Application_N. I >>>>>>> haven't >>>>>>> tried this directive yet so I may misunderstand its role. >>>>>>> >>>>>>> This is my overall understanding but I'm afraid I'm missing >>>>>>> something fundamental [please note that I'm not an English speaker and >>>>>>> I >>>>>>> might have missed subtleties in the documentation which is quite >>>>>>> dense]. I >>>>>>> tried to picture this in a diagram but I'm not sure I got it right: >>>>>>> >>>>>>> M (html requests) -> 1 (http server) -> N x P (mod_wsgi daemons x >>>>>>> threads) -> X? (Python instance(s) / one per daemon ? I don't know) -> >>>>>>> M >>>>>>> (calls to one object in one URI or to many objects - named the same - >>>>>>> in >>>>>>> many URI ? ) and back to the user via the same route. >>>>>>> >>>>>>> I assume that one user html request generates ultimately one call to >>>>>>> a callable object (give or take) : that's why I use M in toth cases. Is >>>>>>> this assumption correct ? My dilemma is that I can't understand the >>>>>>> spread >>>>>>> of the load between the 2 extremes: one URI containing the >>>>>>> `application` >>>>>>> callable object (that is eventually called hundreds of times per >>>>>>> second) or >>>>>>> many hundreds URI each containing a callable object named `application` >>>>>>> that all get called much less frequently. >>>>>>> >>>>>>> *Part 2:* >>>>>>> >>>>>>> As a consequence of this hazy understanding of mine, I wonder why >>>>>>> can't the name of the callable object be chosen on demand ? >>>>>>> >>>>>>> If I refer to PEP3333 (http://legacy.python.org/dev/peps/pep-3333/) >>>>>>> I understand that: >>>>>>> " >>>>>>> *A server or gateway must invoke the application object using >>>>>>> positional (not keyword) arguments. (E.g. by calling result = >>>>>>> application(environ, start_response)*" >>>>>>> >>>>>>> So my guess is that, still referring to the example at the top, one >>>>>>> thread in mod_wsgi loads (I wouldn't call this an import) the >>>>>>> /core/my-wsgi-app script and calls application(environment, >>>>>>> start_response) >>>>>>> that has been defined in it. Is this the correct mechanism ? >>>>>>> >>>>>>> Could we imagine that mod_wsgi would sometime call my_App (arg1, >>>>>>> arg2), some other time call your_App (req, resp) or call Small_app (in, >>>>>>> out) where my_App, your_App, Small_app would be defined because >>>>>>> mod_wsgi >>>>>>> would be able to set dynamically the WSGICallableObject . Imagine >>>>>>> that in the WSGIImportScript script file, we would have: >>>>>>> >>>>>>> def my_App (param1, param2): >>>>>>> [code here] >>>>>>> return [my_Response] >>>>>>> >>>>>>> def your_App (param1, param2): >>>>>>> [code here] >>>>>>> return [your_Response] >>>>>>> >>>>>>> def Small_app (param1, param2): >>>>>>> [code here] >>>>>>> return [Small_response] >>>>>>> >>>>>>> all the functions would be ready to be called. >>>>>>> >>>>>>> I suppose that in any case we are limited: >>>>>>> >>>>>>> A) by the HTTP protocol (URI given via the action attribute, the >>>>>>> POST, GET, OPTIONS, ... from the method attribute and the key/value >>>>>>> pairs >>>>>>> from the various input fields); and >>>>>>> >>>>>>> B) by directives we could give to configure mod_wsgi. I guess it >>>>>>> is not the role neither the intend to build some "user logic" within >>>>>>> mod_wsgi. >>>>>>> >>>>>>> *Conclusions:* >>>>>>> >>>>>>> 1) Am I correct in my understanding of mod_wsgi as expressed here >>>>>>> above (Part 1) ? Beware that I could be out of my depth, i.e. talking >>>>>>> about >>>>>>> something I don't properly understand. In that case please correct me >>>>>>> or >>>>>>> complement my view. >>>>>>> >>>>>>> 2) Do we need to dynamically choose the callable object name for the >>>>>>> sake of dynamism and multiplicity ? >>>>>>> >>>>>>> -> If not, the current set-up is enough. In which case is the >>>>>>> preceding point ( 1) ) complete and correct ? >>>>>>> >>>>>>> -> If yes, how to do it simply and elegantly ? >>>>>>> >>>>>>> => Idea 1: create an extra key/value pair (e.g. >>>>>>> wsgi_callable_object=my_application). It seems cumbersome to me. >>>>>>> >>>>>>> => Idea 2: if the URI were to have the form >>>>>>> /core/my-wsgi-app/_my_application then mod_wsgi could provide: >>>>>>> REQUEST_URI: /core/my-wsgi-app >>>>>>> mod_wsgi.callable_object: my_application >>>>>>> in the 'environment` dictionary because it would strip >>>>>>> the trailing part beginning with an underscore provided it is told to >>>>>>> do so >>>>>>> by a directive; >>>>>>> otherwise it would behave as now and deliver: >>>>>>> REQUEST_URI: /core/my-wsgi-app/_my_applicat >>>>>>> ion >>>>>>> mod_wsgi.callable_object: application >>>>>>> >>>>>>> *Thanks:* >>>>>>> >>>>>>> I do realize this is an unusual post (maybe it should find its way >>>>>>> in the group working on the documentation) but I would be very happy if >>>>>>> some of you could answer / feedback to me. In any case I do thank you >>>>>>> all >>>>>>> in advance. >>>>>>> >>>>>>> René >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "modwsgi" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "modwsgi" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> Visit this group at http://groups.google.com/group/modwsgi. >>> For more options, visit https://groups.google.com/d/optout. >>> >> > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
