Webware for Python

Sorry.  I was testin that out and it must've gotten committed by
mistake.

Jay

Dave wrote:
> 
> Sorry I haven't been keeping up too well lately, but what is the purpose
> of the WK_URI stuff in modpHandler?
> The handler works fine if I comment-out all of the WK_URI stuff, but if
> I leave it in, URLs with query parameters stop working. It seems that
> WebKit is trying to translate the URL into a filename without stripping
> the parameters.
> 
> Dave.
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> http://lists.sourceforge.net/mailman/listinfo/webware-discuss

I spoke too soon.  It should be fine right now.  THe reason WK_URI is
needed is because if you try to retrieve the root file, ie:
"http://localhost/PATH-YOU-SET-UP/" it won't work.

I had that problem with parameters, and fixed it.  I thought.  Would you
make sure you have the most recent modpHandler and Application?

Jay


Dave wrote:
> 
> Sorry I haven't been keeping up too well lately, but what is the purpose
> of the WK_URI stuff in modpHandler?
> The handler works fine if I comment-out all of the WK_URI stuff, but if
> I leave it in, URLs with query parameters stop working. It seems that
> WebKit is trying to translate the URL into a filename without stripping
> the parameters.
> 
> Dave.
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> http://lists.sourceforge.net/mailman/listinfo/webware-discuss

I haven't benchmarked them lately on Windows 98, but I can do that.

I forget if Geoff commented on this before. If not, maybe he can benchmark 
these too?

Is there any chance people can post actual numbers?

-Chuck


At 01:32 PM 8/31/00 -0400, Dan Green wrote:
>Ok, just recovered from a Windows re-install ... luckily the OpenBSD box is
>untouched. Anywho, I just tried out Jay's latest changes to
>AsyncThreadedAppServer, and it's now easily on par with the regular
>ThreadedAppServer .. so if it scales better, I'd say use it. This is only
>speaking for OpenBSD, of course, but there's a good chance FreeBSD/NetBSD will
>behave in the same manner. Anyone tested on NT yet?
>
>--
>Dan Green
>_______________________________________________
>Webware-discuss mailing list
>Webware-discuss@...
>http://lists.sourceforge.net/mailman/listinfo/webware-discuss

Chuck Esterbrook wrote:

> I haven't benchmarked them lately on Windows 98, but I can do that.
>
> I forget if Geoff commented on this before. If not, maybe he can benchmark
> these too?
>
> Is there any chance people can post actual numbers?
>
> -Chuck

I just tried using stress.py on the new AsyncThreadedAppServer on NT (running the
app server on the same machine as stress.py).  Here are my results:

AsyncThreadedAppServer:

sequential requests: 66.58 pages/sec
5 parallel requests: 57.13 pages/sec
50 parallel requests: 57.39 pages/sec
varying from 5 to 50 parallel requests: 58.47 pages/sec

ThreadedAppServer:

sequential requests: 78.88 pages/sec
5 parallel requests: 67.84 pages/sec
50 parallel requests: 66.48 pages/sec
varying from 5 to 50 parallel requests: 68.58 pages/sec

They are both plenty fast for my needs, but ThreadedAppServer seems slightly faster
under all conditions tested here.  Not that you'd notice the difference as a user.
(Before the fixes, AsyncThreadedAppServer was noticeably _much_ slower than
ThreadedAppServer.)

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

Thanks for testing this out.

Now, the original reason I wrote that was because when I was stressing
AppServer very heavily, Threaded would flake out.  Would you guys try it
with, say 100 to 200 simultaneous requests?

Thanks-  Jay


Geoff Talvola wrote:
> 
> Chuck Esterbrook wrote:
> 
> > I haven't benchmarked them lately on Windows 98, but I can do that.
> >
> > I forget if Geoff commented on this before. If not, maybe he can benchmark
> > these too?
> >
> > Is there any chance people can post actual numbers?
> >
> > -Chuck
> 
> I just tried using stress.py on the new AsyncThreadedAppServer on NT (running the
> app server on the same machine as stress.py).  Here are my results:
> 
> AsyncThreadedAppServer:
> 
> sequential requests: 66.58 pages/sec
> 5 parallel requests: 57.13 pages/sec
> 50 parallel requests: 57.39 pages/sec
> varying from 5 to 50 parallel requests: 58.47 pages/sec
> 
> ThreadedAppServer:
> 
> sequential requests: 78.88 pages/sec
> 5 parallel requests: 67.84 pages/sec
> 50 parallel requests: 66.48 pages/sec
> varying from 5 to 50 parallel requests: 68.58 pages/sec
> 
> They are both plenty fast for my needs, but ThreadedAppServer seems slightly faster
> under all conditions tested here.  Not that you'd notice the difference as a user.
> (Before the fixes, AsyncThreadedAppServer was noticeably _much_ slower than
> ThreadedAppServer.)
> 
> --
> 
> - Geoff Talvola
>   Parlance Corporation
>   gtalvola@...
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> http://lists.sourceforge.net/mailman/listinfo/webware-discuss

Terrific.  I just haven't found time for this.  Please send me your
patches.

Jay

Dave wrote:
> 
> I have just completed a patch to make curly-braces {} work in
> PSP pages.  It was fairly easy to tie in due to the very clean and
> rational PSP code! It still needs more testing but it seems fairly
> robust so far.  Basically, it eliminates reliance on indentation in PSPs
> but the code is still line oriented in that the newline is still the
> statement separator and the block-opening curly-brace must appear as the
> last non-comment character on a line. Closing braces can appear just
> about anywhere allowing the following:
> 
> <%@ page indentType="braces" method="writeHTML"  %>
> 
> <table>
> <% for x in range(10) { %>
>   <TR>
>   <% for y in range(10) {
>       if y%2 { %>
>          <TD bgcolor='red'>red
>       <% } else { %>
>          <TD bgcolor='blue'>blue
>       <% } %>
>   </TD>
>   <% } %>
>   </TR>
> <% } %>
> 
> If anyone is interested in this it consists of a minor patch to
> Generators.py,ParseEventHandler.py, and ServletWriter.py plus a new 4k
> file BraceConverter.py which I can email (sending to the list doesn't
> seem appropriate even though it is small)
> 
> In the course of this, I also removed a break statement from
> ParseEventHandler.py:165 which was preventing the page directive from
> processing more than one attribute.
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> http://lists.sourceforge.net/mailman/listinfo/webware-discuss

Denis wrote:

> Hi,
>
> I discovered Webware yesterday. I've just tried the samples,
> read rapidly some code and searched the mail archives.
>
> I found a few messages about databases, but it doesn't look
> like there is an actual "right" solution.
> Where should we make the db connection and how to reach it
> from a page ?

The easiest way is to create the db connection when needed, use it, and
throw it away.  This would be inefficient but it might be good enough
depending on your requirements.

On Windows, if you are using ADO or ODBC you can set things up so that
your database connections are automatically pooled.  In other words, you
write your code as though you are creating and destroying connections,
but ADO or ODBC will secretly pool the connections for you.  Since I'm
using ADO on Windows, this is a nice easy solution.

If you're not on Windows and you need better performance, you'll need to
write your own code to manage a db connection pool.  WebKit doesn't have
this yet, but it would certainly be a great addition...

Or a simpler approach that may or may not suit your needs would be to
create one db connection per thread.  The latest version of WebKit from
CVS allows you to write a plug-in that contains initThread() and
delThread() methods for code that is executed when a thread is
created/destroyed.  When the thread is created, you could create a db
connection and assign it to threading.currentThread().connection; then
in your web pages you could simply use
threading.currentThread().connection anywhere you needed a connection.
If you don't mind keeping a bunch of connections open all the time, this
solution might be reasonable.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

At 10:01 PM 8/31/00 +0200, Denis wrote:
>Hi,
>
>I discovered Webware yesterday. I've just tried the samples,
>read rapidly some code and searched the mail archives.
>
>I found a few messages about databases, but it doesn't look
>like there is an actual "right" solution.
>Where should we make the db connection and how to reach it
>from a page ?

Geoff answered this question pretty well in his reply...


>I'd like to understand the whole thing (Webware). I'd like
>to read the code, but I'm rapidly lost. Where should I start
>reading to understand your design ?
>Would you have some UML of it ? (or just some good drawings)

Start with the CVS (https://sourceforge.net/cvs/?group_id=4866), because 
after you run the new install.py, you will have a class hierarchy document 
for each framework in HTML. That's a good place to get an idea of the classes.

Much of what a Webware user deals with is embodied in WebKit and it's core 
classes HTTPRequest, Page, HTTPResponse and Transaction. Then follow their 
subclasses. Application and AppServer are also interesting classes.

Also, be sure to read WebKit/Documentation/WebKit.html.

We don't have any diagrams right now.


>We could make a deal : I get the explanations I need from you
>and to thank you, I try to turn them in a "develloper guide".
>(As far as I can with my bad English, my mother language is
>French ; but someone could help with the translation).

Given that [a] you're interested in diagrams (which we all are) and [b] 
your English is bad, I think your best contribution could be diagramming. I 
know someone else (Dan I think) also had an interest in this, so you may 
wish to announce your intentions right before hand to avoid duplicating work.

We could use a diagram of the whole process of a transaction including some 
of  the key Python messages and classes involved.

A tutorial would be great, too.  :-)


>I would love to see Webware go on because I prefer your
>approach to Zope's one. Last year, I started to code myself
>and I had transaction, request, reply, ... classes too.
>In such a pattern, I feel like doing Python ; in Zope, I
>feel like doing Visual Basic.

Glad to have you on board. Feel free to keep asking more questions.


-Chuck