[racket] How to reduce my Racket web server's memory usage?

Hi Jay,

On 2/3/2015 8:10 AM, Jay McCarthy wrote:
>>> On Mon, Feb 2, 2015 at 5:06 PM, George Neuner <gneuner2 at comcast.net> 
>>> <mailto:gneuner2 at comcast.net> wrote:
>>>> there are 43 servlets and counting, plus several auxiliary threads 
>>>> and a large(ish) connection pool. Probably the number of servlets 
>>>> will double before I'm done. 
>>> That sounds like a lot of servlets. I think I would try to consolidate.
>>
>> Are you thinking that there might be problems with having many 
>> servlets?  The only issue I've seen was a one time situation where 
>> the application clearly was running background tasks but stopped 
>> responding to http requests.
>
> No, I don't think there's a problem. It just seems mentally exhausting 
> to my feeble mind :)

<gripe>
In general I don't like browser interfaces - particularly for database 
applications which often have complex 2-way communication patterns with 
the server.  Although there are exceptions, in general browser apps are 
unwieldy and inefficient, and they require added middleware components 
to get anything done.  Even if the middleware does nothing else but 
relay communication to/from the database, it still is needed to protect 
the database against (simple) hacking of the browser application code.

I'd always prefer to deliver a proper (compiled) desktop client for a 
database app, but platform independence is an issue.  Java is a 
non-starter in many businesses, and Racket is mostly unknown :-( (I use 
it wherever I can), and thus I'm writing server middleware to support a 
(cooperatively developed) browser application.
</gripe>


>>>      Does switching to the web language impact using serve/servlet
>>>     and dispatch-rules? 
>>     You can still use those, although there is only a benefit when
>>     you are using continuations via send/suspend and
>>     send/suspend/dispatch.
>
>     I'm sorry, but I'm not following.
>
>
> The Web language only makes using the functions send/suspend and 
> send/suspend/dispatch different. If you don't use those two functions, 
> there is no reason to use the Web language.

Got it!    I misunderstood you to mean that serve/servlet and dispatch 
were only useful if you use continuations ... which, naturally, didn't 
make any sense.


> I think what I would do is write one server that is started with 
> serve/servlet where the servlet function (NB: An annoying thing about 
> the web-server is that in the old days a "servlet" was a file that 
> provided a (-> request response) function but now I think of it as 
> just the function because things like serve/servlet allow those to 
> come from anywhere) that implemented a simple dispatching to the other 
> logical servlets. Something like this:
>
> (require
>  (prefix-in servlet1: "servlet1.rkt")
>  (prefix-in servlet2: "servlet2.rkt"))
>
> (define (meta-servlet req)
>   (match (request-uri req)
>    [(list "servlet1" _ ...) (servlet1:start req)]
>    [(list "servlet2" _ ...) (servlet2:start req)]))
>
> (module+ main
>  (serve/servlet meta-servlet))
>
> This would mean that from the WS's perspective there is exactly one 
> servlet, so you would never have multiple instances, namespaces, or 
> anything like that.

Perhaps I'm missing something - maybe a terminology problem: perhaps 
what I'm calling "servlets" you are thinking of simply as "threads" in 
the server?  Your example looks very similar to what I'm doing now with 
dispatch-rules per some program example you pointed me to several months 
ago.

    (define-values (main-dispatch main-url)
      (dispatch-rules
        :
        <lots of rules>
        :
      ))
     :
    (serve/servlet main-dispatch... )

I know that this permits overlapped handling of multiple requests and so 
multiple instances of any given dispatched function can be running 
concurrently (in separate threads).  Which is what I want. I certainly 
don't want to do anything that would jeopardize concurrent request 
handling.  If anything, I'll need to go to multiple cores at some point.

George

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20150203/bc21a6a3/attachment.html>