| Thread overview | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
October 15, 2011 FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
 Attachments:
| Hello! Does anyone know if there's a D2 binding or implementation for fastcgi as of yet? Thanks! Jeremy Sandell | |||
Permalink
ReplyOctober 15, 2011 Re: FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Jeremy Sandell | Den 15-10-2011 03:14, Jeremy Sandell skrev: > Hello! > > Does anyone know if there's a D2 binding or implementation for > fastcgi as of yet? > > Thanks! > Jeremy Sandell Adam Ruppe has a cgi module with some fastcgi in it afaik: http://arsdnet.net/dcode/cgi.d /Jonas | |||
October 17, 2011 Re: FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Jeremy Sandell Attachments:
| I'm working on a SCGI implementation for my job. SCGI is quite easy to
handle and well-supported by servers.
The only missing part is multipart POST (used for file post).
get, post, cookie, headers (etc..) just work.
I have to ask permission to publish my code, btw it's a very easy
protocol to implement.
Il giorno ven, 14/10/2011 alle 21.14 -0400, Jeremy Sandell ha scritto:
> Hello!
>
>
>
> Does anyone know if there's a D2 binding or implementation for
> fastcgi as of yet?
>
>
> Thanks!
> Jeremy Sandell
| |||
October 17, 2011 Re: FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Andrea Fontana | On 2011-10-17 10:14, Andrea Fontana wrote: > I'm working on a SCGI implementation for my job. SCGI is quite easy to > handle and well-supported by servers. > The only missing part is multipart POST (used for file post). > > get, post, cookie, headers (etc..) just work. > > I have to ask permission to publish my code, btw it's a very easy > protocol to implement. What about the rest of the HTTP methods? > Il giorno ven, 14/10/2011 alle 21.14 -0400, Jeremy Sandell ha scritto: >> Hello! >> >> >> Does anyone know if there's a D2 binding or implementation for fastcgi >> as of yet? >> >> >> Thanks! >> Jeremy Sandell -- /Jacob Carlborg | |||
October 17, 2011 Re: FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | I handle request on different threads. I do some pre-processing on scgi data and I fill a struct: request.get[] request.post[] request.cookie[] request.headers[string] then I call a virtual function (to override on subclasses) like: do(request, output); where user fill output struct in a way like: output.data ~= "<html><body><h1>hello world</h1></body></html>"; output.status = 200 output.cookies = bla bla and then if is method != "head" i send headers + data, else just "headers". btw 99% of usage is get, post, head. == Quotato dall`articolo Jacob Carlborg (doob@me.com) > On 2011-10-17 10:14, Andrea Fontana wrote: > > I'm working on a SCGI implementation for my job. SCGI is quite easy to > > handle and well-supported by servers. > > The only missing part is multipart POST (used for file post). > > > > get, post, cookie, headers (etc..) just work. > > > > I have to ask permission to publish my code, btw it's a very easy > > protocol to implement. > What about the rest of the HTTP methods? > > Il giorno ven, 14/10/2011 alle 21.14 -0400, Jeremy Sandell ha scritto: > >> Hello! > >> > >> > >> Does anyone know if there's a D2 binding or implementation for fastcgi > >> as of yet? > >> > >> > >> Thanks! > >> Jeremy Sandell | |||
October 17, 2011 Re: FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Andrea Fontana | On 2011-10-17 16:01, Andrea Fontana wrote: > I handle request on different threads. I do some pre-processing on > scgi data and I fill a struct: > > request.get[] > request.post[] > request.cookie[] > request.headers[string] > > then I call a virtual function (to override on subclasses) like: > > do(request, output); > > where user fill output struct in a way like: > > output.data ~= "<html><body><h1>hello world</h1></body></html>"; > output.status = 200 > output.cookies = bla bla > > and then if is method != "head" i send headers + data, else just > "headers". > > btw 99% of usage is get, post, head. Yes, but if you want to write a web site that is RESTful you need the other HTTP methods as well, at least PUT and DELETE. BTW, what about creating something like Rack but for D. Rack is a low level interface in front of the web server which web frameworks can be built on top. http://rack.github.com/ -- /Jacob Carlborg | |||
October 18, 2011 Re: FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| On Mon, Oct 17, 2011 at 2:11 PM, Jacob Carlborg <doob@me.com> wrote:
> On 2011-10-17 16:01, Andrea Fontana wrote:
>
>> I handle request on different threads. I do some pre-processing on scgi data and I fill a struct:
>>
>> request.get[]
>> request.post[]
>> request.cookie[]
>> request.headers[string]
>>
>> then I call a virtual function (to override on subclasses) like:
>>
>> do(request, output);
>>
>> where user fill output struct in a way like:
>>
>> output.data ~= "<html><body><h1>hello world</h1></body></html>";
>> output.status = 200
>> output.cookies = bla bla
>>
>> and then if is method != "head" i send headers + data, else just "headers".
>>
>> btw 99% of usage is get, post, head.
>>
>
> Yes, but if you want to write a web site that is RESTful you need the other HTTP methods as well, at least PUT and DELETE.
>
> BTW, what about creating something like Rack but for D. Rack is a low level interface in front of the web server which web frameworks can be built on top.
>
> http://rack.github.com/
>
> --
> /Jacob Carlborg
>
Yes, this is exactly why I was wondering whether FastCGI had been implemented (though SCGI works for me as well) - so that I could write something on top of it, in much the same way I would using (for example) WSGI in Python.
I also agree with you re: supporting all of the HTTP methods. Just because the most common ones are GET, POST, and HEAD doesn't mean we should leave out the others; both PUT and DELETE are quite useful.
Best regards,
Jeremy Sandell
| |||
October 18, 2011 Re: FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Jeremy Sandell | I've been having trouble with my news postings, so forgive me if I said this before. But my cgi.d module supports FastCGI via the C library, with the same D interface as normal CGI or an embedded server: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff Just compile with -version=fastcgi to use that. | |||
October 18, 2011 Re: FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Jeremy Sandell Attachments: | On 18.10.2011 19:24, Jeremy Sandell wrote:
> On Mon, Oct 17, 2011 at 2:11 PM, Jacob Carlborg <doob@me.com <mailto:doob@me.com>> wrote:
>
> On 2011-10-17 16:01, Andrea Fontana wrote:
>
> I handle request on different threads. I do some pre-processing on
> scgi data and I fill a struct:
>
> request.get[]
> request.post[]
> request.cookie[]
> request.headers[string]
>
> then I call a virtual function (to override on subclasses) like:
>
> do(request, output);
>
> where user fill output struct in a way like:
>
> output.data ~= "<html><body><h1>hello world</h1></body></html>";
> output.status = 200
> output.cookies = bla bla
>
> and then if is method != "head" i send headers + data, else just
> "headers".
>
> btw 99% of usage is get, post, head.
>
>
> Yes, but if you want to write a web site that is RESTful you need
> the other HTTP methods as well, at least PUT and DELETE.
>
> BTW, what about creating something like Rack but for D. Rack is a
> low level interface in front of the web server which web frameworks
> can be built on top.
>
> http://rack.github.com/
>
> --
> /Jacob Carlborg
>
>
> Yes, this is exactly why I was wondering whether FastCGI had been implemented (though SCGI works for me as well) - so that I could write something on top of it, in much the same way I would using (for example) WSGI in Python.
>
> I also agree with you re: supporting all of the HTTP methods. Just because the most common ones are GET, POST, and HEAD doesn't mean we should leave out the others; both PUT and DELETE are quite useful.
>
> Best regards,
> Jeremy Sandell
Adam D. Ruppe has a wrapper for libfcgi at github. I started implementing fcgi, but it's basically just a very, very limited ugly-hack prototype. Doubt you'll get much use of it, but I'll attach it here anyway.
| |||
October 18, 2011 Re: FastCGI binding or implementation? | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | Tale time, only tangentially on topic. Today, I was coincidentally switching one of my work apps from standard CGI to Fast CGI. Almost trivial. Set up Apache, then build the program with -version=fastcgi. Done. Well, not 100% done. I had a piece of static data in the app that worked correctly before but now means subsequent requests were out of it. Changed that to an instance variable, and boom, works perfectly. * If you are using Fast CGI, avoid static variables. The next thing is speed. From principles, there's very little reason for FastCGI to actually be faster than normal CGI - the startup costs are insignificant next to the total app runtime and network lag. (Startup is maybe 5 ms on the live server, with runtime close to 50ms and ping to the user another 100ms. The "cost" of CGI is roundoff error in the actual deployment.) My benchmarks supported this for the kind of loads we had before. But now, the number of concurrent users is picking up. The CGI still performed very well, though every so often, users complained about lag on some resources. I ran a benchmark comparing cgi to fast cgi with a very large number of concurrent users. It showed better availability and about a 15% speed boost under this load. Since Apache restarts it when it segfaults, reliability ought not to be affected, though it's too soon to say for sure. So, I changed the makefile to say "-version=fastcgi" and soon realized I must search for static variables - found just one, so easy fix, and we're up on fastcgi. ... but that 15% in the benchmark hasn't translated to a big change in the live environment yet. Been several hours now, and we've been trying to force the availability issue, and failed so far. Looks like a win, but not a very big one. Speed on the whole - unaffected. The difference is roundoff error once you factor in network lag and such again. So, how can we speed up the application? The key here is client side caching. Using my cgi.d, there's a function: cgi.setCache(true); which tells it simply to cache the response forever. It makes an expiration date long in the future. Set that for any content which changes infrequently - css, javascript, images, any kind of (conceptually) pure or static data, etc. Now, your code doesn't run again and the user doesn't hit the network again. What was 150ms is now < 1ms. The users will feel the difference. You might set even data that changes often to cache for a few minutes. Odds are the user doesn't need it to revalidate on the server every minute. cgi.d's setResponseExpires can help here, just set it a little bit in the future. If the user hits a link to go back to a page then, it will load from cache most the time, making navigating the site feel snappy. Until the time expires, then it's wait again, but IMO some cache is better than none. Remember: you can cache AJAX responses too. What if the resource actually does change? You'll want to change the link. When compiling, there's a __TIMESTAMP__ special token. A quick and dirty method is to use that __TIMESTAMP__ on your resource URLs in your html so every time you recompile, it invalidates the user's cache. <script src="/myapp/functions.js?{$timestamp}"></script> A better way might be to hash the content at compile time, but I haven't written code that can do this well enough for real work yet. * Caching makes a much bigger difference than just about any other technique. You'll still want fast code for the cold cache users, but as they browse your site, a good cache policy can shave full seconds off the experience. The fastest code is running no code at all. | |||
Copyright © 1999-2021 by the D Language Foundation