Tcl Web Service with Authorization kills Tcl

newtophp2000@yahoo.com wrote:
> On Mar 31, 8:28 pm, "tom.rmadilo" <tom.rmad...@gmail.com> wrote:
>
> I must add that I too find it a pleasant environment to write web
> applications.  Very easy too.
>
>
> 
>
> In terms of speed, no user has complained yet.  Indeed, it seems to be
> faster than some alternative technologies.

TclHttpd was measured as faster than apache and most (if not all) of the
Java Servers by Brent Welch when he as at Sun.  Doing the same set of
measurements it came out slower than AOLserver.  His report was that it was
not hard to measure it as faster than Apache, but you needed really hot disk
and networks to see that it was slower than AOLserver.

It is also reported that WUB is faster than TclHttpd -- but it is also a bit
of a different beast (as I understand it WUB is a framework for creating
"web" applications, not an out of the box web server like TclHttpd -- Colin
please correct me if I misspoke).

Thus of the "full" web servers, TclHttpd is normally considered one of the
faster -- it is just that Tom is looking at it from the perspective of the
"fastest" server and sees it as slow.  Of course on the flip side, IMHO
TclHttpd is an easier server to get started working with -- but then again I
may be biased since I've got copyright notices inside of it.

P.S. -- I'm looking forward to working with WUB sometime in the future.


--
+--------------------------------+---------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

tom.rmadilo wrote:
> On Apr 1, 1:56 pm, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote: 
>
> Hmmm, when did you send me WS::Standalone? I would love to test this
> out.

About two ws ago, I'll resend.  If you do not get it today -- email me
directly.

> BTW, I can pull in the svn code from google, is this still the best
> place to get updates?

Ah, I have work on my machine which I've not test or documented enough to
commit there.


--
+--------------------------------+---------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

tom.rmadilo wrote:
> On Apr 1, 1:56 pm, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote: 
>
> My performance test was done with a GET (of documentation), so there
> was no writing the XML document to disk. Also, the return document is
> never written to disk. I never was able to run a POST, because my code
> used [fcopy], which didn't work.
[...]

When you say [fcopy] didn't work, what exactly was the error? I know
that there has been some recent effort to fix a bug with async fcopy and
the -size option. I've used [fcopy] many times, both synchronous and
async and never experienced a problem, but then I've also avoided using
the -size option so far. Could you post some example code of what you
were trying to do and how it failed? A basic:

fcopy $sock $file

should work fine, as should an async:

fcopy -command cleanup $sock $file

-- Neil

On Apr 2, 6:07 am, Neil Madden <n...@cs.nott.ac.uk> wrote:
> tom.rmadilo wrote: 

> When you say [fcopy] didn't work, what exactly was the error? I know
> that there has been some recent effort to fix a bug with async fcopy and
> the -size option. I've used [fcopy] many times, both synchronous and
> async and never experienced a problem, but then I've also avoided using
> the -size option so far. Could you post some example code of what you
> were trying to do and how it failed? A basic:

Neil,

I did more research on this issue and I think I have resolved it. I
have a Tcl only AOLserver replacement layer, it works great for simple
tcl pages, but would be unsuitable as a generic web server
replacement. Anyway, AOLserver does not handle the POSTed data
automatically (this obviously helps if you have a huge file to upload,
it can go straight to disk).

My mistake was thinking that I had to do the same thing in tclhttpd.
In fact, all this POSTed data gets put into a global variable. So, my
[fcopy] was sitting around waiting for more bytes to read on the input
channel, which had already been drained.

Here is my startup.tcl file, the change I made was to replace the
'accept' proc which handles the interface between AOLserver and the
web service code:

# For using tWSDL/TWiST with tclhttpd

namespace eval ::twist {

variable pageroot
variable initialized 0
variable home
variable startFile [info script]
}

proc ::twist::workingDirectory { } {

return [pwd]
}

proc ::twist::getStartFile { } {

variable startFile

return $startFile
}

proc ::twist::receive {
sock
url
} {

fconfigure $sock -translation binary
set in $sock
set out $sock
set sockList [list $in $out]

upvar #0 Httpd$sock HTTPDATA

if {![::ns_conn start $sockList]} {
return -code error "::ns::conn::receive: Sock error in startup"
}

::ns::conn::request $HTTPDATA(line)

::ns::conn::listToSet $HTTPDATA(headerlist) $::ns::conn::headers
::ns::conn::host

# Assume success
set status 200

set targetFile [ns_url2file [ns_conn url]]

# Either file exists or is directory with index.tcl
# If not, return file not found.
if {![file exists $targetFile]} {

set status 404

} elseif {[file isdirectory $targetFile]} {

set targetFile [file join $targetFile index.tcl]

if {![file exists $targetFile]} {
set status 404
}
}

if {"$status" ne "200"} {
ns_return $status text/plain "Issues $status"
return -code return
}

# File exists
source $targetFile


}

Stderr "Sourced twist file startup.tcl"

set twsdlHome [file normalize [file join [file dirname [info script]]
twsdl]]

source [file join $twsdlHome init.tcl]

# Replacment proc for tclhttpd
proc ::wsdl::server::accept { why } {

log Notice "Accepting Connection with $why"

foreach {server service port binding address} $why {break}

# 0. Get POSTed Data:
set headerSet [ns_conn headers]
set length [ns_set iget $headerSet "Content-length"]
set tmpFile [ns_tmpnam]
log Notice "Using tmpFile = $tmpFile"
set fp [ns_openexcl $tmpFile]
fconfigure $fp -translation binary

# Changes for tclhttpd:
set sockin $::ns::conn::sockin

upvar #0 Httpd$sockin HTTPDATA

set inXML $HTTPDATA(query)

puts $fp $inXML

# Finish changes for tclhttpd
close $fp

# 0.1 Package File and Headers:
set headerLength [ns_set size $headerSet]

for {set i 0} {$i < $headerLength} {incr i} {
lappend headers [ns_set key $headerSet $i] [ns_set value $headerSet
$i]
}

set requestID [::request::new $headers $tmpFile $why]

# 2. Let Binding handle the request
set responseList [[set ::wsdb::bindings::$
{binding}::handleRequest] $requestID]

ns_return [lindex $responseList 0] [lindex $responseList 1]
[lindex $responseList 3]
}

::ns::info::setOption home $twsdlHome
::ns::info::setOption pageroot [file join $twsdlHome packages wsapi]

::Url_PrefixInstall /twist ::twist::receive

# End startup.tcl

After these changes I reran the apache bench to post the SOAP request.
Performance appears to be 70-90/sec, which is what I was expecting to
see.

Now if I can just figure out how to use threads in tclhttpd. How is
thread code initialized for a particular custom service?

tom.rmadilo wrote:
>...
>
> Now if I can just figure out how to use threads in tclhttpd. How is
> thread code initialized for a particular custom service?

On the command line you specify how many threads to use.  The thread
specific initialization goes in httpdthread.tcl.  It is fairly well commente
d.

Do not hesitate to yell if you need more directions.

Also -- did you get the standalone code?

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

tom.rmadilo schrieb:

> Application servers are very hard to write. If you don't write them
> correctly, you get questions like yours.

Maybe, but maybe the author of this code has just not thought that
somebody wants to use it for sending more than status 200 or 302? And
maybe the way I changed the code in Direct_Url just works fine and
resolves the issue?

> Tclhttpd is first of all: slow.

Might be for you, following the thread further on. But I find it *very*
fast... at least for my playground applications.
However, it would be interresting to know how it performs under
pressure, e.g. how it handles a hundret requests at the same time. Is
there some data or experiences? Also it would be interresting to hear
about security issues...


> But unfortunately, you have to write
> code which is tied to the server.

That's true, yes. And I would like to have a layer like that of Tclhttpd
.tml templates and procedure handlers in AOLserver or Apache.
I like this way of mixing Tcl code into HTML a lot, it's so more natural
than <% %> or <? ?>.


Eckhard

On Apr 2, 2:48 pm, EL <eckhardnos...@gmx.de> wrote:
> tom.rmadilo schrieb:
> 
>
> Maybe, but maybe the author of this code has just not thought that
> somebody wants to use it for sending more than status 200 or 302? And
> maybe the way I changed the code in Direct_Url just works fine and
> resolves the issue?
> 
>
> Might be for you, following the thread further on. But I find it *very*
> fast... at least for my playground applications.
> However, it would be interresting to know how it performs under
> pressure, e.g. how it handles a hundret requests at the same time. Is
> there some data or experiences? Also it would be interresting to hear
> about security issues...
> 
>
> That's true, yes. And I would like to have a layer like that of Tclhttpd
> .tml templates and procedure handlers in AOLserver or Apache.
> I like this way of mixing Tcl code into HTML a lot, it's so more natural
> than <% %> or <? ?>.
>
> Eckhard

EL,

Please note that I have always said that if it works, and you are
happy, that is perfect, I can't argue with success and happiness.

Also, note that I have corrected my statements about speed, please
read my most recent post. Tclhttpd appears to be only a little slower
than the tcl socket model (one thread), very much within what I was
expecting.

Finally note that apache is much worse than tclhttpd from an API
standpoint. AOLserver is just a little better than tclhttpd.

If you really like mixing Tcl code and html, maybe check out my tic-
tac-toe templating system:

http://junom.com/document/twt/view/www/

This templating system works with just tclsh.

On Apr 2, 12:53 pm, "Gerald W. Lester" <Gerald.Les...@cox.net> wrote:
> tom.rmadilo wrote: 
> 
>
> On the command line you specify how many threads to use.  The thread
> specific initialization goes in httpdthread.tcl.  It is fairly well commented.[/co
lor]

> Do not hesitate to yell if you need more directions.

Thanks, if this comes up, I will start a new thread.

> Also -- did you get the standalone code?

Yes, and I'll start a new thread on this as well. I'm getting way OT.