Seaside as backend of apache

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> In the image transcript I can also see that /seaside/ is concatenating more
> than once.
>
>     any clue on what is wrong?

I think you forgot to set #serverPath (Seaside 2.7 and later) or
#baseUrl: (older versions of Seaside) in your application
configuration. I don't think you need to specify ProxyPassReverse,
however since I always use RewriteRules for proxying I am not entirely
sure.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

However, another possiblity would be to use FastCGI. There exists a package on
SqueakMap and squeaksource.com: fcgi. Unfortunately Apache doesn't seem to
support fastcgi by its newest version 2.2 (although there is a development
package), but with e.g. Lighttpd you can get enormous speed advantages. The
reason for this is, that you bypass the WAKom, which isn't known as to be
very fast... ;) I plan to implement the scgi protocol in this package, too.
This way, even the usage of apache shouldn't be any obstacle anymore...
Greets,
Martin
Am Montag 12 März 2007 20:44:21 schrieb Lukas Renggli:

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 3/12/07, Martin Beck <[hidden email]> wrote:
> However, another possiblity would be to use FastCGI. There exists a package on
> SqueakMap and squeaksource.com: fcgi. Unfortunately Apache doesn't seem to
> support fastcgi by its newest version 2.2 (although there is a development
> package), but with e.g. Lighttpd you can get enormous speed advantages.

Can you document these speed advantages?  I've never had the sense
that Comanche/WAKom was much of a bottleneck, but I'd love to see
numbers.

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hey, I just came across lighttpd today as well, is it really that much
better than Apache performance-wise? Pretty much the only things we use
are rewrites, SSL, proxying and mod_deflate.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
seem
> to
> > support fastcgi by its newest version 2.2 (although there is a
> development
> > package), but with e.g. Lighttpd you can get enormous speed
advantages. _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hello,

current FastCGI timings:
on my machine using apache benchmark WAKom allows me to have around 74
requests per second on the example counter (in deployment mode).
Using the FastCGI instead of WAKom it comes to 97 requests per second.

I still think there is a much higher speedup possible because there is a
very high amount of time (around 35%) spent in the primitive socket calls.


97.1% {1620ms} FCGIProtocolVersion1>>requestLoop
  50.1% {836ms} FCGIProtocolVersion1>>answerRequest
    |49.3% {822ms} WAFCGI(WAKom)>>process:
    |  45.7% {762ms} WAFCGI(WAKom)>>handleRequest:
    |    45.5% {759ms} WAApplication>>handleRequest:
    |      45.2% {754ms} WAApplication(WARegistry)>>handleRequest:
    |        45.2% {754ms} WAApplication>>handleDefaultRequest:
    |          43.5% {726ms} WASession(WAExpiringHandler)>>handleRequest:
    |            43.5% {726ms} WASession>>incomingRequest:
    |              43.5% {726ms} WASession>>responseForRequest:
    |                42.3% {706ms} WASession>>performRequest:
    |                  42.3% {706ms} WASession>>start:
    |                    41.9% {699ms} WARenderLoopMain>>start:
    |                      41.4% {691ms} WARenderLoop>>run
    |                        41.4% {691ms} WARender>>go
    |                          41.3% {689ms} WARender>>render
    |                            21.3% {355ms} WASession>>respond:
    |                              |17.7% {295ms}
WASession>>actionUrlForContinuation:
    |                              |  16.2% {270ms}
WASession>>actionUrlForKey:
    |                              |    15.9% {265ms}
WAApplication(WARegistry)>>urlForRequestHandler:
    |                              |      14.7% {245ms}
WAApplication(WARegistry)>>ensureKeyForHandler:
    |                              |        14.7% {245ms}
WAApplication(WARegistry)>>registerRequestHandler:
    |                              |          11.1% {185ms}
WAApplication(WARegistry)>>unregisterExpiredHandlers
    |                              |            |5.6% {93ms}
Dictionary>>add:
    |                              |            |  |3.4% {57ms}
Dictionary(Set)>>findElementOrNil:
    |                              |            |  |  3.4% {57ms}
Dictionary>>scanFor:
    |                              |            |3.2% {53ms}
WASession(WAExpiringHandler)>>isActive
    |                              |            |  2.4% {40ms}
WASession(WAExpiringHandler)>>timeoutSeconds
    |                              |          2.5% {42ms} WAExternalID
class>>new:
    |                              |            2.5% {42ms}
WAExternalID>>initialize
    |                              |              2.1% {35ms} Character>>to:
    |                            19.7% {329ms} WARender>>buildResponse
    |                              16.8% {280ms}
WACounter(WAPresenter)>>renderWithContext:
    |                                |16.7% {279ms}
WACounter>>renderContentOn:
    |                                |  14.5% {242ms}
WARenderCanvas(WAHtmlCanvas)>>heading:
    |                                |    14.5% {242ms}
WAHeadingTag(WATagBrush)>>with:
    |                                |      14.2% {237ms}
WAHeadingTag(WATagBrush)>>openTag
    |                                |        14.1% {235ms}
WAHtmlStreamDocument>>openTag:attributes:
    |                                |          14.1% {235ms}
WAHtmlStreamDocument>>bodyStream
    |                                |            14.1% {235ms}
WARenderedHtmlRoot(WAHtmlRoot)>>writeOn:
    |                                |              13.2% {220ms}
WARenderedHtmlRoot(WAHtmlRoot)>>writeHeadOn:
    |                                |                8.5% {142ms}
WARenderedHtmlRoot>>writeStyle:on:
    |                                |                  |6.4% {107ms}
WARenderingContext>>urlForDocument:mimeType:
    |                                |                  |  6.4% {107ms}
WARenderingContext>>urlForDocument:mimeType:fileName:
    |                                |                  |    5.1% {85ms}
WAApplication(WARegistry)>>urlForRequestHandler:
    |                                |                  |      4.7%
{78ms} WAApplication>>baseUrl
    |                                |                  |        2.3%
{38ms} WAApplication(WAEntryPoint)>>baseUrl
    |                                |                  |          2.2%
{37ms} WAUrl>>addToPath:
    |                                |                  |          
2.2% {37ms} ByteString(String)>>findTokens:
    |                                |                4.2% {70ms}
WARenderedHtmlRoot>>writeScript:on:
    |                                |                  3.1% {52ms}
WARenderingContext>>urlForDocument:mimeType:
    |                                |                    3.0% {50ms}
WARenderingContext>>urlForDocument:mimeType:fileName:
    |                                |                      2.1% {35ms}
WAApplication(WARegistry)>>urlForRequestHandler:
    |                              2.2% {37ms} WARender>>buildDocRoot
  41.8% {697ms} FCGIProtocolVersion1>>readRecord:
    |41.7% {696ms} FCGIProtocolVersion1>>readAnyRecord
    |  41.7% {696ms} FCGIProtocolVersion1>>readFrom:
    |    37.0% {617ms} FCGIHeader>>readFrom:
    |      |36.8% {614ms} SocketStream>>uint8
    |      |  36.8% {614ms} SocketStream>>next
    |      |    36.2% {604ms} SocketStream>>receiveData
    |      |      35.6% {594ms}
Socket>>receiveDataSignallingClosedInto:startingAt:
    |      |        35.4% {590ms} Socket>>waitForData
    |      |          35.4% {590ms} Socket>>waitForDataIfClosed:
    |    4.2% {70ms} FCGIParamRecord>>readFrom:
    |      3.7% {62ms} ReadStream class(PositionableStream class)>>on:
    |        3.7% {62ms} ReadStream(PositionableStream)>>on:
    |          3.7% {62ms} ReadStream(PositionableStream)>>reset
  4.8% {80ms} SocketStream>>flush
    4.8% {80ms} Socket>>sendData:count:
      4.4% {73ms} primitives

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/3/13, Avi Bryant <[hidden email]>:
> On 3/12/07, Martin Beck <[hidden email]> wrote:
> > However, another possiblity would be to use FastCGI. There exists a package on
> > SqueakMap and squeaksource.com: fcgi. Unfortunately Apache doesn't seem to
> > support fastcgi by its newest version 2.2 (although there is a development
> > package), but with e.g. Lighttpd you can get enormous speed advantages.
>
> Can you document these speed advantages?  I've never had the sense
> that Comanche/WAKom was much of a bottleneck, but I'd love to see
> numbers.

What I can image is that if keep-alive works with fcgi (compared to
Kom) that this makes a difference.

Philippe

> Avi
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

With lighttpd 1.4 keep-alive works for fcgi, and it is used in the current  
package. This allows that multiple sequential requests get handled through  
a single socket. Currently the requests are always processed sequencially  
over this one socket. The fcgi protocol also allows multiplexing requests  
but this is not implemented yet.

Dominic

Am 14.03.2007, 17:44 Uhr, schrieb Philippe Marschall  
<[hidden email]>:


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside