Mohammad DAMT wrote:
> Seems that this mail (attached) has not been answered yet *-)
Oopss.. sorry for the delay!
> Btw I'd like to have a new configuration keyword for fcgi
> server. I'd like to have something like
>
> ServerList 127.0.0.1:9090;/tmp/unix.sock;other.host:port
Well, it okay, but I would suggest to use multiple Server entries
rather than a new configuration entry. The more reserver words we
use, the more problems we will have with the parsing. What do you
think of something like this?
Handler fastcgi {
Server 127.0.0.1:9090
Server /tmp/unix.sock
Server other.host:port
}
> And for the server list, I have a plan to have the round-robin works
> in the handler. So the handler would pick the server from the
> ServerList and invoke it using the manager. And each server handled
> by one manager. So for the case above, we would have three manager
> threads.
>
> What do you say?
It sounds great :-)
>> I have been reading this code, but it does not make much sense
>> for me. It seems like you want to have an extra pointer in
>> set_env_pair(), but what is its purpose?
>
> I need to pass fcgi handler to set_env_pair, or at least fcgi->id to
> build the environment buffer. Each env must be prefixed with
> FCGI_PARAMS header. (However in fcgi spec we can see only one
> FCGI_PARAMS for -all- environment variables, but it doesnt work)
What about building the content without knowing the ID, and then,
when you get it, add the header with the ID? :-m
> fcgi_manager_step returns immediately if there is a response from fcgi
> server which has not being picked up by handler. then handler would
> reset the buffer after pick the data and return it to the main thread.
Well, my original idea was: If the manager get something from the
FastCGI server, it will process it, always. As long as it has a
pointer to each connection which is currently using it and therefore
waiting for some information, it will copy the information into its
buffer.
It is important here the concurrency. Each thread has a set of
connections. These connection will never change of thread, so there
is only one connection being processed and all the other connections
of the thread are not being used. Besides that, each thread has its
own fastcgi manager, so it can safely work in that way.
If we have one Fcgi manager in it thread, it is going to be a few
connections to the fcgi server, as many as threads in the server.
Maybe five or so..
> I have played it with ab (from apache stock) and had this result
> with 500 requests:
>
> Document Path: /test.fcgi
> Complete requests: 500
> Requests per second: 970.52 [#/sec] (mean)
Pretty cool. Good stuff! :-)
> However when I increased the concurrency level to more than 4, after
> processing some requests, it stucked in
>
> ret = cherokee_socket_read (fcgim->socket, &fcgim->read_buffer,
> DEFAULT_READ_SIZE, &size); (fcgi_manager.c:327)
>
> any hints?
Ummm.. no. Have you sorted this out?
>> > c. data is incomplete, to be retried (ret_eagain?)
>>
>> If you got some data to be send, just put it on the buffer and
>> return ret_ok
>
> how to escape the step? what value should be returned?
Yes, if you don't have anything an ret_eagain set the connection on
hold until the next loop.
>> > 1. how to print to log?
>>
>> Do you want to log the connections? If so, do not do it; It should
>> not do it from a handler.
>>
>> If what you want to write information about that FastCGI server
>> state or something like that, you can use:
>>
>> cherokee_logger_write_string (CONN_VSRV(HANDLER_CONN(handler))->logger,
>> "%s", whatever);
>>
>
> is this similar to apache writing to error_log?
I have no idea. I don't know much about the Apache API. It will
just write an arbitrary string in log.
> - cherokee_buffer_t tmp = CHEROKEE_BUF_INIT;
> + cherokee_buffer_t tmp = CHEROKEE_BUF_INIT, write_tmp;
[..]
> + cherokee_buffer_init (&tmp);
> + cherokee_buffer_init (&write_tmp);
You can write this like:
cherokee_buffer_t tmp = CHEROKEE_BUF_INIT;
cherokee_buffer_t write_tmp = CHEROKEE_BUF_INIT;
in this way, you don't need to call cherokee_buffer_init()
> + CHEROKEE_MUTEX_LOCK (&__global_fastcgi_managers_lock);
> + ret = cherokee_fcgi_manager_send (fcgi->manager_ref,
&fcgi->write_buffer, &size);
> + CHEROKEE_MUTEX_UNLOCK (&__global_fastcgi_managers_lock);
> + CHEROKEE_MUTEX_LOCK (&__global_fastcgi_managers_lock);
> + ret = cherokee_fcgi_manager_step (fcgim);
> + CHEROKEE_MUTEX_UNLOCK (&__global_fastcgi_managers_lock);
Tell me what do you think of the design I explained before. With
that way of working, we don't need this mutexes any longer.
Mohammad, the patch looks nice..
Sorry about the delay! :-)
--
Greetings, alo.
_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
