hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

Philipp Klose-2
Hi list,

today I published the first version of hxfcgi to haxelib. hxfcgi gives
you the possibility to use the standart haxe Web Api (you might know
from the PHP and the Neko target) and deploy you application as a CGI or
FastCGI script on any web server. In addition to the neko target it is
now possible to use haXe cpp to create web applications, which is quite
a speed improvement.

The haxelib version currently only ships ndll files for Linux 32bit
target, but all sources and a makefile are included to build the ndll
file on you own. (Please keep in mind, if you like to target neko you
also need nekoapi.ndll according to your platform) When everything
becomes more stable we will probably ship the library with the most
common binaries.

A short description of differences and how to deploy hxfcgi could be
found on this wiki page: http://haxe.org/com/libs/hxfcgi

You should consider hxfcgi as experimental, it still need a lot of
testing. If you find a bug feel free to contribute to the project
(https://github.com/TheHippo/hxfcgi/) or simply file a issue
(https://github.com/TheHippo/hxfcgi/issues). We are looking forward for
any kind of feedback.

A special thanks to Kaahl! who implemented a most of the Api functions.

Philipp





--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

go2ghana
Am 06.05.2011 21:12, schrieb Philipp Klose:

> Hi list,
>
> today I published the first version of hxfcgi to haxelib. hxfcgi gives
> you the possibility to use the standart haxe Web Api (you might know
> from the PHP and the Neko target) and deploy you application as a CGI
> or FastCGI script on any web server. In addition to the neko target it
> is now possible to use haXe cpp to create web applications, which is
> quite a speed improvement.
>
> The haxelib version currently only ships ndll files for Linux 32bit
> target, but all sources and a makefile are included to build the ndll
> file on you own. (Please keep in mind, if you like to target neko you
> also need nekoapi.ndll according to your platform) When everything
> becomes more stable we will probably ship the library with the most
> common binaries.
>
> A short description of differences and how to deploy hxfcgi could be
> found on this wiki page: http://haxe.org/com/libs/hxfcgi
>
> You should consider hxfcgi as experimental, it still need a lot of
> testing. If you find a bug feel free to contribute to the project
> (https://github.com/TheHippo/hxfcgi/) or simply file a issue
> (https://github.com/TheHippo/hxfcgi/issues). We are looking forward
> for any kind of feedback.
>
> A special thanks to Kaahl! who implemented a most of the Api functions.
>
> Philipp
>
>
>
>
>
Hi Philipp,
this was pretty perfect timing.
While I have been experimenting with a neko version of the ming library
I noticed that frequent calls to CFFI with abstract parameters
are slow - so I tried the cpp target with a little improvement - now
with hxfcgi it is  already faster than php :)
As you can see on this comparison <http://go2ghana.net/devel/ming.php>
Now I have some questions: How can I tweak the performance with
configuration settings of fcgi?
what may cause this error message:
Terminal error Could not generate Request, File src/hxfcgi.cpp, line 101

Cordially,
Axel

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

Philipp Klose-2


On 08.05.2011 17:56, Axel Huizinga wrote:
> Hi Philipp,
> this was pretty perfect timing.
> While I have been experimenting with a neko version of the ming
> library I noticed that frequent calls to CFFI with abstract parameters
> are slow - so I tried the cpp target with a little improvement - now
> with hxfcgi it is  already faster than php :)
As said hxfcgi is kind of experimental. The main goal was to get the Web
API fully implemented. When everything is stable and compatible, I
believe there room for some speed and memory optimisations.
> As you can see on this comparison <http://go2ghana.net/devel/ming.php>
> Now I have some questions: How can I tweak the performance with
> configuration settings of fcgi?
In general you should try to do all stuff thats need to be done before
calling Web.cacheModule(). Tweaking FastCGI performances depends on your
server setup (which web server, which FastCGI manager?) Mainly it is
about how many processes are started and how long the processes are
allowed to live. FastCGI is quite small, so most improvements could be
archived by optimising your actually web application and standard web
server settings (HTTP-expire, caching, etc.)
> what may cause this error message:
> Terminal error Could not generate Request, File src/hxfcgi.cpp, line 101
That is pretty interesting. Could you provide a example how reproduce
this error? Which web server and which haXe target? This error is caused
when hxfcgi waits (really waits, everything is blocked) for a new
request from FastCGI. FastCGI responds with an error, which is a little
bit odd and should not happen at all.
>
> Cordially,
> Axel
>

Philipp

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

Philipp Klose-2
In reply to this post by Philipp Klose-2
I updated the haxelib package. It now contains a small bugfix and
binaries for Linux 32/64 bit and Mac 32/64 bit.

On 06.05.2011 21:12, Philipp Klose wrote:

> Hi list,
>
> today I published the first version of hxfcgi to haxelib. hxfcgi gives
> you the possibility to use the standart haxe Web Api (you might know
> from the PHP and the Neko target) and deploy you application as a CGI
> or FastCGI script on any web server. In addition to the neko target it
> is now possible to use haXe cpp to create web applications, which is
> quite a speed improvement.
>
> The haxelib version currently only ships ndll files for Linux 32bit
> target, but all sources and a makefile are included to build the ndll
> file on you own. (Please keep in mind, if you like to target neko you
> also need nekoapi.ndll according to your platform) When everything
> becomes more stable we will probably ship the library with the most
> common binaries.
>
> A short description of differences and how to deploy hxfcgi could be
> found on this wiki page: http://haxe.org/com/libs/hxfcgi
>
> You should consider hxfcgi as experimental, it still need a lot of
> testing. If you find a bug feel free to contribute to the project
> (https://github.com/TheHippo/hxfcgi/) or simply file a issue
> (https://github.com/TheHippo/hxfcgi/issues). We are looking forward
> for any kind of feedback.
>
> A special thanks to Kaahl! who implemented a most of the Api functions.
>
> Philipp
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

go2ghana
In reply to this post by Philipp Klose-2
Am 08.05.2011 18:47, schrieb Philipp Klose:

>
>
> On 08.05.2011 17:56, Axel Huizinga wrote:
>> Hi Philipp,
>> this was pretty perfect timing.
>> While I have been experimenting with a neko version of the ming
>> library I noticed that frequent calls to CFFI with abstract parameters
>> are slow - so I tried the cpp target with a little improvement - now
>> with hxfcgi it is  already faster than php :)
> As said hxfcgi is kind of experimental. The main goal was to get the
> Web API fully implemented. When everything is stable and compatible, I
> believe there room for some speed and memory optimisations.
>> As you can see on this comparison <http://go2ghana.net/devel/ming.php>
>> Now I have some questions: How can I tweak the performance with
>> configuration settings of fcgi?
> In general you should try to do all stuff thats need to be done before
> calling Web.cacheModule(). Tweaking FastCGI performances depends on
> your server setup (which web server, which FastCGI manager?) Mainly it
> is about how many processes are started and how long the processes are
> allowed to live. FastCGI is quite small, so most improvements could be
> archived by optimising your actually web application and standard web
> server settings (HTTP-expire, caching, etc.)
>> what may cause this error message:
>> Terminal error Could not generate Request, File src/hxfcgi.cpp, line 101
> That is pretty interesting. Could you provide a example how reproduce
> this error? Which web server and which haXe target? This error is
> caused when hxfcgi waits (really waits, everything is blocked) for a
> new request from FastCGI. FastCGI responds with an error, which is a
> little bit odd and should not happen at all.
>>
>> Cordially,
>> Axel
>>
>
> Philipp
>
Found that the error mentioned above is only reported to the error_log
in cgi mode.
I looks like it happens on every program - at least I get it on the test
from your distro too.
compiled to cpp target tested on apache2
But the content is delivered correctly though.
Axel


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

KaalH!

Le 8 mai 2011 à 19:48, Axel Huizinga a écrit :

> Am 08.05.2011 18:47, schrieb Philipp Klose:
>>
>>
>> On 08.05.2011 17:56, Axel Huizinga wrote:
>>> Hi Philipp,
>>> this was pretty perfect timing.
>>> While I have been experimenting with a neko version of the ming library I noticed that frequent calls to CFFI with abstract parameters
>>> are slow - so I tried the cpp target with a little improvement - now with hxfcgi it is  already faster than php :)
>> As said hxfcgi is kind of experimental. The main goal was to get the Web API fully implemented. When everything is stable and compatible, I believe there room for some speed and memory optimisations.
>>> As you can see on this comparison <http://go2ghana.net/devel/ming.php>
>>> Now I have some questions: How can I tweak the performance with configuration settings of fcgi?
>> In general you should try to do all stuff thats need to be done before calling Web.cacheModule(). Tweaking FastCGI performances depends on your server setup (which web server, which FastCGI manager?) Mainly it is about how many processes are started and how long the processes are allowed to live. FastCGI is quite small, so most improvements could be archived by optimising your actually web application and standard web server settings (HTTP-expire, caching, etc.)
>>> what may cause this error message:
>>> Terminal error Could not generate Request, File src/hxfcgi.cpp, line 101
>> That is pretty interesting. Could you provide a example how reproduce this error? Which web server and which haXe target? This error is caused when hxfcgi waits (really waits, everything is blocked) for a new request from FastCGI. FastCGI responds with an error, which is a little bit odd and should not happen at all.
>>>
>>> Cordially,
>>> Axel
>>>
>>
>> Philipp
>>
> Found that the error mentioned above is only reported to the error_log in cgi mode.
> I looks like it happens on every program - at least I get it on the test from your distro too.
> compiled to cpp target tested on apache2
> But the content is delivered correctly though.
> Axel
>

Fixed in git repository.

>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

KaalH!
In reply to this post by go2ghana

Le 8 mai 2011 à 17:56, Axel Huizinga a écrit :

> Am 06.05.2011 21:12, schrieb Philipp Klose:
>> Hi list,
>>
>> today I published the first version of hxfcgi to haxelib. hxfcgi gives you the possibility to use the standart haxe Web Api (you might know from the PHP and the Neko target) and deploy you application as a CGI or FastCGI script on any web server. In addition to the neko target it is now possible to use haXe cpp to create web applications, which is quite a speed improvement.
>>
>> The haxelib version currently only ships ndll files for Linux 32bit target, but all sources and a makefile are included to build the ndll file on you own. (Please keep in mind, if you like to target neko you also need nekoapi.ndll according to your platform) When everything becomes more stable we will probably ship the library with the most common binaries.
>>
>> A short description of differences and how to deploy hxfcgi could be found on this wiki page: http://haxe.org/com/libs/hxfcgi
>>
>> You should consider hxfcgi as experimental, it still need a lot of testing. If you find a bug feel free to contribute to the project (https://github.com/TheHippo/hxfcgi/) or simply file a issue (https://github.com/TheHippo/hxfcgi/issues). We are looking forward for any kind of feedback.
>>
>> A special thanks to Kaahl! who implemented a most of the Api functions.
>>
>> Philipp
>>
>>
>>
>>
>>
> Hi Philipp,
> this was pretty perfect timing.
> While I have been experimenting with a neko version of the ming library I noticed that frequent calls to CFFI with abstract parameters
> are slow - so I tried the cpp target with a little improvement - now with hxfcgi it is  already faster than php :)
> As you can see on this comparison <http://go2ghana.net/devel/ming.php>

Great, impressive results as hxfcgi is not optimized yet.
What is your testing environment ? (apache/nginx/ lighttpd/other, 32 or 64 bits system ? )
Could you add mod_neko,  neko CGI and neko FastCGI targets ? It can help improving hxfcgi for both cpp and neko targets.

Kaalh

> Now I have some questions: How can I tweak the performance with configuration settings of fcgi?
> what may cause this error message:
> Terminal error Could not generate Request, File src/hxfcgi.cpp, line 101
>
> Cordially,
> Axel
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

Gamehaxe
In reply to this post by Philipp Klose-2
Hi,
Is the web api a "static" api?  I would think that this limits the
ability to have many threads servicing requests.  I think it might
be better to convert to an interface, and pass the "response" object
to a handler.  You could keep the Web file API the same, and make
it delegate to a singleton in the simple case, but let you have
multiple responses if you like.

Hugh

> Hi list,
>
> today I published the first version of hxfcgi to haxelib. hxfcgi gives  
> you the possibility to use the standart haxe Web Api (you might know  
> from the PHP and the Neko target) and deploy you application as a CGI or  
> FastCGI script on any web server. In addition to the neko target it is  
> now possible to use haXe cpp to create web applications, which is quite  
> a speed improvement.
>
> The haxelib version currently only ships ndll files for Linux 32bit  
> target, but all sources and a makefile are included to build the ndll  
> file on you own. (Please keep in mind, if you like to target neko you  
> also need nekoapi.ndll according to your platform) When everything  
> becomes more stable we will probably ship the library with the most  
> common binaries.
>
> A short description of differences and how to deploy hxfcgi could be  
> found on this wiki page: http://haxe.org/com/libs/hxfcgi
>
> You should consider hxfcgi as experimental, it still need a lot of  
> testing. If you find a bug feel free to contribute to the project  
> (https://github.com/TheHippo/hxfcgi/) or simply file a issue  
> (https://github.com/TheHippo/hxfcgi/issues). We are looking forward for  
> any kind of feedback.
>
> A special thanks to Kaahl! who implemented a most of the Api functions.
>
> Philipp
>
>
>
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

Philipp Klose-2


On 09.05.2011 13:33, Gamehaxe wrote:
> Hi,
> Is the web api a "static" api?  I would think that this limits the
> ability to have many threads servicing requests.  I think it might
> be better to convert to an interface, and pass the "response" object
> to a handler.  You could keep the Web file API the same, and make
> it delegate to a singleton in the simple case, but let you have
> multiple responses if you like.
>
> Hugh

Hi Hugh,

the API is the same as the standard Web API for neko / php. The
"problem" with haXe on the server side currently is that you have to:
a) use PHP
b) need root right to install custom Apache extension for running neko.

There is currently no way to use haXe C++ on the server side. (Which is
something I do not understand, but I also don't care about IPhone
development at all.) Also if you want to use neko you are stick to use
Apache, which is known to be not the fasted and very hungry web server.

The main goal of hxfcgi is to bring you haXe written web application to
any web server you want on "every" haXe target, without changing your
code. "Write once, deploy/host everywhere."

If you want to have more processes working on requests then your FastCGI
handler should spawn more hxfcgi processes. Handling your connections
currently should be task of you web server / FastCGI.

There is some room for optimisations right now, but main goal will be to
keep the API compatible, even thought you are right about the fact that
it could be done more effectively.

Philipp


>
>> Hi list,
>>
>> today I published the first version of hxfcgi to haxelib. hxfcgi
>> gives you the possibility to use the standart haxe Web Api (you might
>> know from the PHP and the Neko target) and deploy you application as
>> a CGI or FastCGI script on any web server. In addition to the neko
>> target it is now possible to use haXe cpp to create web applications,
>> which is quite a speed improvement.
>>
>> The haxelib version currently only ships ndll files for Linux 32bit
>> target, but all sources and a makefile are included to build the ndll
>> file on you own. (Please keep in mind, if you like to target neko you
>> also need nekoapi.ndll according to your platform) When everything
>> becomes more stable we will probably ship the library with the most
>> common binaries.
>>
>> A short description of differences and how to deploy hxfcgi could be
>> found on this wiki page: http://haxe.org/com/libs/hxfcgi
>>
>> You should consider hxfcgi as experimental, it still need a lot of
>> testing. If you find a bug feel free to contribute to the project
>> (https://github.com/TheHippo/hxfcgi/) or simply file a issue
>> (https://github.com/TheHippo/hxfcgi/issues). We are looking forward
>> for any kind of feedback.
>>
>> A special thanks to Kaahl! who implemented a most of the Api functions.
>>
>> Philipp
>>
>>
>>
>>
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

KaalH!

Le 9 mai 2011 à 17:30, Philipp Klose a écrit :

>
>
> On 09.05.2011 13:33, Gamehaxe wrote:
>> Hi,
>> Is the web api a "static" api?  I would think that this limits the
>> ability to have many threads servicing requests.  I think it might
>> be better to convert to an interface, and pass the "response" object
>> to a handler.  You could keep the Web file API the same, and make
>> it delegate to a singleton in the simple case, but let you have
>> multiple responses if you like.
>>
>> Hugh
>
> Hi Hugh,
>
> the API is the same as the standard Web API for neko / php. The "problem" with haXe on the server side currently is that you have to:
> a) use PHP
> b) need root right to install custom Apache extension for running neko.
>
> There is currently no way to use haXe C++ on the server side. (Which is something I do not understand, but I also don't care about IPhone development at all.) Also if you want to use neko you are stick to use Apache, which is known to be not the fasted and very hungry web server.

Hi Hugh,

For c++ you still need an installed version of hxcpp, is there a way for shared hosting to put all hxcpp dso in the application directory or build a static application ?
 
>
> The main goal of hxfcgi is to bring you haXe written web application to any web server you want on "every" haXe target, without changing your code. "Write once, deploy/host everywhere."
>
> If you want to have more processes working on requests then your FastCGI handler should spawn more hxfcgi processes. Handling your connections currently should be task of you web server / FastCGI.
>
> There is some room for optimisations right now, but main goal will be to keep the API compatible, even thought you are right about the fact that it could be done more effectively.

We may mix with your nice implementation start (http://code.google.com/p/hxfastcgi/) at some point in the (near) future to also have an optimized advanced Web API, but I'm agree with Phillip, the first goal is to provide a clean, stable and easy to use c++/neko implementation of the standard Web API available for apache alternatives and shared hosting.

Kaalh

>
> Philipp
>
>
>>
>>> Hi list,
>>>
>>> today I published the first version of hxfcgi to haxelib. hxfcgi gives you the possibility to use the standart haxe Web Api (you might know from the PHP and the Neko target) and deploy you application as a CGI or FastCGI script on any web server. In addition to the neko target it is now possible to use haXe cpp to create web applications, which is quite a speed improvement.
>>>
>>> The haxelib version currently only ships ndll files for Linux 32bit target, but all sources and a makefile are included to build the ndll file on you own. (Please keep in mind, if you like to target neko you also need nekoapi.ndll according to your platform) When everything becomes more stable we will probably ship the library with the most common binaries.
>>>
>>> A short description of differences and how to deploy hxfcgi could be found on this wiki page: http://haxe.org/com/libs/hxfcgi
>>>
>>> You should consider hxfcgi as experimental, it still need a lot of testing. If you find a bug feel free to contribute to the project (https://github.com/TheHippo/hxfcgi/) or simply file a issue (https://github.com/TheHippo/hxfcgi/issues). We are looking forward for any kind of feedback.
>>>
>>> A special thanks to Kaahl! who implemented a most of the Api functions.
>>>
>>> Philipp
>>>
>>>
>>>
>>>
>>
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

go2ghana
In reply to this post by KaalH!
Am 09.05.2011 09:32, schrieb KaalH!:

> Le 8 mai 2011 à 17:56, Axel Huizinga a écrit :
>
>> Am 06.05.2011 21:12, schrieb Philipp Klose:
>>> Hi list,
>>>
>>> today I published the first version of hxfcgi to haxelib. hxfcgi gives you the possibility to use the standart haxe Web Api (you might know from the PHP and the Neko target) and deploy you application as a CGI or FastCGI script on any web server. In addition to the neko target it is now possible to use haXe cpp to create web applications, which is quite a speed improvement.
>>>
>>> The haxelib version currently only ships ndll files for Linux 32bit target, but all sources and a makefile are included to build the ndll file on you own. (Please keep in mind, if you like to target neko you also need nekoapi.ndll according to your platform) When everything becomes more stable we will probably ship the library with the most common binaries.
>>>
>>> A short description of differences and how to deploy hxfcgi could be found on this wiki page: http://haxe.org/com/libs/hxfcgi
>>>
>>> You should consider hxfcgi as experimental, it still need a lot of testing. If you find a bug feel free to contribute to the project (https://github.com/TheHippo/hxfcgi/) or simply file a issue (https://github.com/TheHippo/hxfcgi/issues). We are looking forward for any kind of feedback.
>>>
>>> A special thanks to Kaahl! who implemented a most of the Api functions.
>>>
>>> Philipp
>>>
>>>
>>>
>>>
>>>
>> Hi Philipp,
>> this was pretty perfect timing.
>> While I have been experimenting with a neko version of the ming library I noticed that frequent calls to CFFI with abstract parameters
>> are slow - so I tried the cpp target with a little improvement - now with hxfcgi it is  already faster than php :)
>> As you can see on this comparison<http://go2ghana.net/devel/ming.php>
> Great, impressive results as hxfcgi is not optimized yet.
> What is your testing environment ? (apache/nginx/ lighttpd/other, 32 or 64 bits system ? )
> Could you add mod_neko,  neko CGI and neko FastCGI targets ? It can help improving hxfcgi for both cpp and neko targets.
>
Am working on but currently don't know how to handle the differences
between the c and cpp cffi api
related to (byte)array access.
my first mod_neko version was

value movieBytes(value movie)
{
     int ssize;
     size_t size = 1024;
     FILE * stream;
     char *bp;

     stream = open_memstream(&bp, &size);

     if(stream == NULL)
     {
         return val_null;
     }
     else
     {
         ssize = SWFMovie_output_to_stream(val_data(movie), stream);
         fclose(stream);
     }

     int i;
     value swfBytes = alloc_array(size);
     for(i=0;i<size;i++)
         val_array_ptr(swfBytes)[i] = alloc_int(bp[i]);

     return swfBytes;
}

for cpp I use this one:
value movieBytes(value movie)
{
     int ssize, rsize;
     size_t size = 1024;
     FILE * stream;
     char *bp;

     stream = open_memstream(&bp, &size);

     if(stream == NULL)
     {
         return val_null;
     }
     else
     {
         ssize =
SWFMovie_output_to_stream(V2SWFMovie(val_data(movie))->movie, stream);
         fclose(stream);
     }

     unsigned char* by = (unsigned char*) new char [ size];
     memcpy(by, bp, size);

     buffer buf = alloc_buffer_len(NULL);
     unsigned int i;
     for(i=0;i<size;i++)
     {
         if(debug)
             printf("byte %d:%u -> %d\n", i , bp[i] ,  by[i]);
         buffer_append_char(buf, by[i]);
     }
     return buffer_val(buf);
}

on the HaXe side the returned value is treated as int array and the
print with toString method.
Am not really a c/cpp expert so any hint how to improve this part are
very welcome


btw - I noticed something weird with hxfcgi:

     static function main() {
         Web.cacheModule(run);
         run();
     }

when I omit the call to run I get the same output - calling cacheModule
executes the run function as well
but it is executed only once.
noticed this first when I tried the run b4 the call to cacheModule which
resulted in duplicate output.
So in practice calling run explicitly is not required?


> Kaalh
>
>> Now I have some questions: How can I tweak the performance with configuration settings of fcgi?
>> what may cause this error message:
>> Terminal error Could not generate Request, File src/hxfcgi.cpp, line 101
>>
>> Cordially,
>> Axel
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

Philipp Klose-2


On 11.05.2011 09:08, Axel Huizinga wrote:

> Am 09.05.2011 09:32, schrieb KaalH!:
>> Le 8 mai 2011 à 17:56, Axel Huizinga a écrit :
>>
>> Great, impressive results as hxfcgi is not optimized yet.
>> What is your testing environment ? (apache/nginx/ lighttpd/other, 32
>> or 64 bits system ? )
>> Could you add mod_neko,  neko CGI and neko FastCGI targets ? It can
>> help improving hxfcgi for both cpp and neko targets.
>>
> Am working on but currently don't know how to handle the differences
> between the c and cpp cffi api
> related to (byte)array access.
> my first mod_neko version was
>
> value movieBytes(value movie)
> {
>     int ssize;
>     size_t size = 1024;
>     FILE * stream;
>     char *bp;
>
>     stream = open_memstream(&bp, &size);
>
>     if(stream == NULL)
>     {
>         return val_null;
>     }
>     else
>     {
>         ssize = SWFMovie_output_to_stream(val_data(movie), stream);
>         fclose(stream);
>     }
>
>     int i;
>     value swfBytes = alloc_array(size);
>     for(i=0;i<size;i++)
>         val_array_ptr(swfBytes)[i] = alloc_int(bp[i]);
>
>     return swfBytes;
> }
>
> for cpp I use this one:
> value movieBytes(value movie)
> {
>     int ssize, rsize;
>     size_t size = 1024;
>     FILE * stream;
>     char *bp;
>
>     stream = open_memstream(&bp, &size);
>
>     if(stream == NULL)
>     {
>         return val_null;
>     }
>     else
>     {
>         ssize =
> SWFMovie_output_to_stream(V2SWFMovie(val_data(movie))->movie, stream);
>         fclose(stream);
>     }
>
>     unsigned char* by = (unsigned char*) new char [ size];
>     memcpy(by, bp, size);
>
>     buffer buf = alloc_buffer_len(NULL);
>     unsigned int i;
>     for(i=0;i<size;i++)
>     {
>         if(debug)
>             printf("byte %d:%u -> %d\n", i , bp[i] ,  by[i]);
>         buffer_append_char(buf, by[i]);
>     }
>     return buffer_val(buf);
> }
>
> on the HaXe side the returned value is treated as int array and the
> print with toString method.
> Am not really a c/cpp expert so any hint how to improve this part are
> very welcome

I am not that familiar with bytearray/data, but if you want your ndll
usable from neko and hxcpp you need to use hxcpp's CFFI.h. (To use the
ndll for neko target you also need nekoapi.ndll.) Not all function from
the neko cffi are available if you use the hxcpp CFFI, you need to take
a look at CFFI.h and CFFIAPI.h

>
>
> btw - I noticed something weird with hxfcgi:
>
>     static function main() {
>         Web.cacheModule(run);
>         run();
>     }
>
> when I omit the call to run I get the same output - calling
> cacheModule executes the run function as well
> but it is executed only once.
> noticed this first when I tried the run b4 the call to cacheModule
> which resulted in duplicate output.
> So in practice calling run explicitly is not required?

this should be fixed on the hxfcgi version I just committed to haxelib.

Philipp


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Standard interface based Web API.

Gamehaxe
In reply to this post by Philipp Klose-2
Hi,
Ok, I guess my proposal then is that we should have a
standard "interface" based web API for haxe, rather than
a static function based one.

This allows the possibility of threaded servers, rather than
explicitly preventing the possibility.

To this end, I suggest any new code should first wrap the
current Web global functions into an interface, an then write
code against this interface.  This will allow your code
to run at maximum efficiency on all platforms in the future.

Hugh

>
>
> On 09.05.2011 13:33, Gamehaxe wrote:
>> Hi,
>> Is the web api a "static" api?  I would think that this limits the
>> ability to have many threads servicing requests.  I think it might
>> be better to convert to an interface, and pass the "response" object
>> to a handler.  You could keep the Web file API the same, and make
>> it delegate to a singleton in the simple case, but let you have
>> multiple responses if you like.
>>
>> Hugh
>
> Hi Hugh,
>
> the API is the same as the standard Web API for neko / php. The  
> "problem" with haXe on the server side currently is that you have to:
> a) use PHP
> b) need root right to install custom Apache extension for running neko.
>
> There is currently no way to use haXe C++ on the server side. (Which is  
> something I do not understand, but I also don't care about IPhone  
> development at all.) Also if you want to use neko you are stick to use  
> Apache, which is known to be not the fasted and very hungry web server.
>
> The main goal of hxfcgi is to bring you haXe written web application to  
> any web server you want on "every" haXe target, without changing your  
> code. "Write once, deploy/host everywhere."
>
> If you want to have more processes working on requests then your FastCGI  
> handler should spawn more hxfcgi processes. Handling your connections  
> currently should be task of you web server / FastCGI.
>
> There is some room for optimisations right now, but main goal will be to  
> keep the API compatible, even thought you are right about the fact that  
> it could be done more effectively.
>
> Philipp
>
>
>>
>>> Hi list,
>>>
>>> today I published the first version of hxfcgi to haxelib. hxfcgi gives  
>>> you the possibility to use the standart haxe Web Api (you might know  
>>> from the PHP and the Neko target) and deploy you application as a CGI  
>>> or FastCGI script on any web server. In addition to the neko target it  
>>> is now possible to use haXe cpp to create web applications, which is  
>>> quite a speed improvement.
>>>
>>> The haxelib version currently only ships ndll files for Linux 32bit  
>>> target, but all sources and a makefile are included to build the ndll  
>>> file on you own. (Please keep in mind, if you like to target neko you  
>>> also need nekoapi.ndll according to your platform) When everything  
>>> becomes more stable we will probably ship the library with the most  
>>> common binaries.
>>>
>>> A short description of differences and how to deploy hxfcgi could be  
>>> found on this wiki page: http://haxe.org/com/libs/hxfcgi
>>>
>>> You should consider hxfcgi as experimental, it still need a lot of  
>>> testing. If you find a bug feel free to contribute to the project  
>>> (https://github.com/TheHippo/hxfcgi/) or simply file a issue  
>>> (https://github.com/TheHippo/hxfcgi/issues). We are looking forward  
>>> for any kind of feedback.
>>>
>>> A special thanks to Kaahl! who implemented a most of the Api functions.
>>>
>>> Philipp
>>>
>>>
>>>
>>>
>>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Standard interface based Web API.

Franco Ponticelli
On that regard I have done that for ufront, you can find the classes here:


Franco

On Sun, May 15, 2011 at 5:28 PM, Gamehaxe <[hidden email]> wrote:
Hi,
Ok, I guess my proposal then is that we should have a
standard "interface" based web API for haxe, rather than
a static function based one.

This allows the possibility of threaded servers, rather than
explicitly preventing the possibility.

To this end, I suggest any new code should first wrap the
current Web global functions into an interface, an then write
code against this interface.  This will allow your code
to run at maximum efficiency on all platforms in the future.

Hugh



On 09.05.2011 13:33, Gamehaxe wrote:
Hi,
Is the web api a "static" api?  I would think that this limits the
ability to have many threads servicing requests.  I think it might
be better to convert to an interface, and pass the "response" object
to a handler.  You could keep the Web file API the same, and make
it delegate to a singleton in the simple case, but let you have
multiple responses if you like.

Hugh

Hi Hugh,

the API is the same as the standard Web API for neko / php. The "problem" with haXe on the server side currently is that you have to:
a) use PHP
b) need root right to install custom Apache extension for running neko.

There is currently no way to use haXe C++ on the server side. (Which is something I do not understand, but I also don't care about IPhone development at all.) Also if you want to use neko you are stick to use Apache, which is known to be not the fasted and very hungry web server.

The main goal of hxfcgi is to bring you haXe written web application to any web server you want on "every" haXe target, without changing your code. "Write once, deploy/host everywhere."

If you want to have more processes working on requests then your FastCGI handler should spawn more hxfcgi processes. Handling your connections currently should be task of you web server / FastCGI.

There is some room for optimisations right now, but main goal will be to keep the API compatible, even thought you are right about the fact that it could be done more effectively.

Philipp



Hi list,

today I published the first version of hxfcgi to haxelib. hxfcgi gives you the possibility to use the standart haxe Web Api (you might know from the PHP and the Neko target) and deploy you application as a CGI or FastCGI script on any web server. In addition to the neko target it is now possible to use haXe cpp to create web applications, which is quite a speed improvement.

The haxelib version currently only ships ndll files for Linux 32bit target, but all sources and a makefile are included to build the ndll file on you own. (Please keep in mind, if you like to target neko you also need nekoapi.ndll according to your platform) When everything becomes more stable we will probably ship the library with the most common binaries.

A short description of differences and how to deploy hxfcgi could be found on this wiki page: http://haxe.org/com/libs/hxfcgi

You should consider hxfcgi as experimental, it still need a lot of testing. If you find a bug feel free to contribute to the project (https://github.com/TheHippo/hxfcgi/) or simply file a issue (https://github.com/TheHippo/hxfcgi/issues). We are looking forward for any kind of feedback.

A special thanks to Kaahl! who implemented a most of the Api functions.

Philipp






--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Standard interface based Web API.

Nicolas Cannasse
In reply to this post by Gamehaxe
Le 15/05/2011 18:28, Gamehaxe a écrit :
> Hi,
> Ok, I guess my proposal then is that we should have a
> standard "interface" based web API for haxe, rather than
> a static function based one.
>
> This allows the possibility of threaded servers, rather than
> explicitly preventing the possibility.

Not really against your proposal, but you can always use Thread Local
Storage in order to have per-thread static object in multithread.

Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Standard interface based Web API.

Heinz Hölzer-2
In reply to this post by Franco Ponticelli
Hey Fraco,

i found out that you use static eregs like:
static var paramPattern = ~/^\{([?$])?([*])?([a-z0-9_]+)(\?)?\}/; // in ufront.web.routing.RouteUriParser 
this is a big problem in multithreaded environments because they are infact singletons and have state.

I know that this pattern for eregs is used a lot in haxe libraries, but this is a bad habit from my point of view.

best,
h

best,
h



Am 15.05.2011 20:14, schrieb Franco Ponticelli:
On that regard I have done that for ufront, you can find the classes here:


Franco

On Sun, May 15, 2011 at 5:28 PM, Gamehaxe <[hidden email]> wrote:
Hi,
Ok, I guess my proposal then is that we should have a
standard "interface" based web API for haxe, rather than
a static function based one.

This allows the possibility of threaded servers, rather than
explicitly preventing the possibility.

To this end, I suggest any new code should first wrap the
current Web global functions into an interface, an then write
code against this interface.  This will allow your code
to run at maximum efficiency on all platforms in the future.

Hugh



On 09.05.2011 13:33, Gamehaxe wrote:
Hi,
Is the web api a "static" api?  I would think that this limits the
ability to have many threads servicing requests.  I think it might
be better to convert to an interface, and pass the "response" object
to a handler.  You could keep the Web file API the same, and make
it delegate to a singleton in the simple case, but let you have
multiple responses if you like.

Hugh

Hi Hugh,

the API is the same as the standard Web API for neko / php. The "problem" with haXe on the server side currently is that you have to:
a) use PHP
b) need root right to install custom Apache extension for running neko.

There is currently no way to use haXe C++ on the server side. (Which is something I do not understand, but I also don't care about IPhone development at all.) Also if you want to use neko you are stick to use Apache, which is known to be not the fasted and very hungry web server.

The main goal of hxfcgi is to bring you haXe written web application to any web server you want on "every" haXe target, without changing your code. "Write once, deploy/host everywhere."

If you want to have more processes working on requests then your FastCGI handler should spawn more hxfcgi processes. Handling your connections currently should be task of you web server / FastCGI.

There is some room for optimisations right now, but main goal will be to keep the API compatible, even thought you are right about the fact that it could be done more effectively.

Philipp



Hi list,

today I published the first version of hxfcgi to haxelib. hxfcgi gives you the possibility to use the standart haxe Web Api (you might know from the PHP and the Neko target) and deploy you application as a CGI or FastCGI script on any web server. In addition to the neko target it is now possible to use haXe cpp to create web applications, which is quite a speed improvement.

The haxelib version currently only ships ndll files for Linux 32bit target, but all sources and a makefile are included to build the ndll file on you own. (Please keep in mind, if you like to target neko you also need nekoapi.ndll according to your platform) When everything becomes more stable we will probably ship the library with the most common binaries.

A short description of differences and how to deploy hxfcgi could be found on this wiki page: http://haxe.org/com/libs/hxfcgi

You should consider hxfcgi as experimental, it still need a lot of testing. If you find a bug feel free to contribute to the project (https://github.com/TheHippo/hxfcgi/) or simply file a issue (https://github.com/TheHippo/hxfcgi/issues). We are looking forward for any kind of feedback.

A special thanks to Kaahl! who implemented a most of the Api functions.

Philipp






--
haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Standard interface based Web API.

Franco Ponticelli
I remember your note about that and I guess you are right :)
I will try to fix it with time.

Franco

2011/5/16 Heinz Hölzer <[hidden email]>
Hey Fraco,

i found out that you use static eregs like:
static var paramPattern = ~/^\{([?$])?([*])?([a-z0-9_]+)(\?)?\}/; // in ufront.web.routing.RouteUriParser 
this is a big problem in multithreaded environments because they are infact singletons and have state.

I know that this pattern for eregs is used a lot in haxe libraries, but this is a bad habit from my point of view.

best,
h

best,
h



Am 15.05.2011 20:14, schrieb Franco Ponticelli:
On that regard I have done that for ufront, you can find the classes here:


Franco

On Sun, May 15, 2011 at 5:28 PM, Gamehaxe <[hidden email]> wrote:
Hi,
Ok, I guess my proposal then is that we should have a
standard "interface" based web API for haxe, rather than
a static function based one.

This allows the possibility of threaded servers, rather than
explicitly preventing the possibility.

To this end, I suggest any new code should first wrap the
current Web global functions into an interface, an then write
code against this interface.  This will allow your code
to run at maximum efficiency on all platforms in the future.

Hugh



On 09.05.2011 13:33, Gamehaxe wrote:
Hi,
Is the web api a "static" api?  I would think that this limits the
ability to have many threads servicing requests.  I think it might
be better to convert to an interface, and pass the "response" object
to a handler.  You could keep the Web file API the same, and make
it delegate to a singleton in the simple case, but let you have
multiple responses if you like.

Hugh

Hi Hugh,

the API is the same as the standard Web API for neko / php. The "problem" with haXe on the server side currently is that you have to:
a) use PHP
b) need root right to install custom Apache extension for running neko.

There is currently no way to use haXe C++ on the server side. (Which is something I do not understand, but I also don't care about IPhone development at all.) Also if you want to use neko you are stick to use Apache, which is known to be not the fasted and very hungry web server.

The main goal of hxfcgi is to bring you haXe written web application to any web server you want on "every" haXe target, without changing your code. "Write once, deploy/host everywhere."

If you want to have more processes working on requests then your FastCGI handler should spawn more hxfcgi processes. Handling your connections currently should be task of you web server / FastCGI.

There is some room for optimisations right now, but main goal will be to keep the API compatible, even thought you are right about the fact that it could be done more effectively.

Philipp



Hi list,

today I published the first version of hxfcgi to haxelib. hxfcgi gives you the possibility to use the standart haxe Web Api (you might know from the PHP and the Neko target) and deploy you application as a CGI or FastCGI script on any web server. In addition to the neko target it is now possible to use haXe cpp to create web applications, which is quite a speed improvement.

The haxelib version currently only ships ndll files for Linux 32bit target, but all sources and a makefile are included to build the ndll file on you own. (Please keep in mind, if you like to target neko you also need nekoapi.ndll according to your platform) When everything becomes more stable we will probably ship the library with the most common binaries.

A short description of differences and how to deploy hxfcgi could be found on this wiki page: http://haxe.org/com/libs/hxfcgi

You should consider hxfcgi as experimental, it still need a lot of testing. If you find a bug feel free to contribute to the project (https://github.com/TheHippo/hxfcgi/) or simply file a issue (https://github.com/TheHippo/hxfcgi/issues). We are looking forward for any kind of feedback.

A special thanks to Kaahl! who implemented a most of the Api functions.

Philipp






--
haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: hxfcgi - a FastCGI / CGI wrapper for haXe neko and Cpp target

alexander.konotop
In reply to this post by Philipp Klose-2
В Fri, 06 May 2011 21:12:14 +0200
Philipp Klose <[hidden email]> пишет:

> http://haxe.org/com/libs/hxfcgi

There's no need to run spawn-fcgi in case of lighttpd. In 1.4 You can
use next config:

    fastcgi.server += ( "/app.fcgi" =>
        ((
                "bin-path" => "/var/www/kaznachey/app.fcgi",
                "socket" => "/tmp/hxfcgi-app.socket",
                "kill-signal" => 10,     # this is because programs
    linked against libfcgi need USR1 kill-signal "min-procs" => 1,
                "max-procs" => 8        # as You wish
        ))
    )

Actually lighttpd server has its own built-in spawn-fcgi utility. If
you use this config - you'll have next files created automatically
in /tmp:
hxfcgi-app.socket-0
hxfcgi-app.socket-1
hxfcgi-app.socket-2
hxfcgi-app.socket-3
hxfcgi-app.socket-4
hxfcgi-app.socket-5
hxfcgi-app.socket-6
hxfcgi-app.socket-7

if one of them will crash - lighttpd will run spawn-fcgi again. Also it
will balance server's load between sockets itself.

I don't know what about kill-signal. I took this config option from
php-fastcgi-redmine settings.


I didn't change wiki at http://haxe.org/com/libs/hxfcgi myself because
I don't know how to do the same in lighty 1.5.

BTW, cpp version didn't work for me - lighttpd says:

2011-06-27 16:55:06: (mod_fastcgi.c.1104) the
fastcgi-backend /var/www/kaznachey/app.fcgi failed to start: 2011-06-27
16:55:06: (mod_fastcgi.c.1108) child exited with status
0 /var/www/kaznachey/app.fcgi 2011-06-27 16:55:06: (mod_fastcgi.c.1111)
If you're trying to run your app as a FastCGI backend, make sure you're
using the FastCGI-enabled version. If this is PHP on Gentoo, add
'fastcgi' to the USE flags. 2011-06-27 16:55:06: (mod_fastcgi.c.1399)
[ERROR]: spawning fcgi failed. 2011-06-27 16:55:06: (server.c.938)
Configuration of plugins failed. Going down.

--
haXe - an open source web programming language
http://haxe.org