Hello Mongrel Users, I''m writing a web server called Ebb. It''s written in C, makes use of the Mongrel HTTP parser, and uses libev its event loop. The goal is to be small, fast, and language independent server that can host web frameworks. I have written a small Ruby binding which provides a Rack handler - this will allow Ebb to host Rails, Merb, and other Ruby frameworks. In the future I will write a Python WSGI binding. The design is similar to the evented Mongrel web server. Connections are processed as follows: 1. libev loops and waits for incoming connections. 2. When Ebb can read from a client socket, it passes the buffer into the mongrel state machine which parses the headers into name value pairs. 3. Ebb starts a new thread and passes the request information and peer socket to a user supplied callback. The thread lasts only for the length of that callback. 4. The included Ruby binding, supplying this callback transforms the request into a Rack compatible "env" variable and passes it on a Rack adapter. The code measures in at less than 1000 lines of C code. There is much work to do; it is not ready for use. I am soliciting help from the community for testing and development. You may browse the git repository at http://repo.or.cz/w/ebb.git or check out the code with this command: git clone git://repo.or.cz/ebb.git I release Ebb under the MIT license. It is very fun to program Ebb so I suggest you do too :) Ry Dahl
On Jan 14, 2008 2:43 PM, ry dahl <ry at tinyclouds.org> wrote:> Hello Mongrel Users, > > I''m writing a web server called Ebb. It''s written in C, makes use of > the Mongrel HTTP parser, and uses libev its event loop. The goal is to > be small, fast, and language independent server that can host web > frameworks. I have written a small Ruby binding which provides a Rack > handler - this will allow Ebb to host Rails, Merb, and other Ruby > frameworks. In the future I will write a Python WSGI binding. >Nice ry!> > There is much work to do; it is not ready for use. I am soliciting > help from the community for testing and development. You may browse > the git repository at http://repo.or.cz/w/ebb.git or check out the > code with this command: > git clone git://repo.or.cz/ebb.git > I release Ebb under the MIT license. > It is very fun to program Ebb so I suggest you do too :) >A svn repo clone? (git-svn)? Not all jumped into the git bandwagon :-) -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
Good luck with your new server! I also suggest looking at Thin which has been developed very recently and seems quite promising: http://code.macournoyer.com/thin/ According to the benchmarks it''s the fastest Ruby web server currently. On Jan 14, 2008 6:43 PM, ry dahl <ry at tinyclouds.org> wrote:> Hello Mongrel Users, > > I''m writing a web server called Ebb. It''s written in C, makes use of > the Mongrel HTTP parser, and uses libev its event loop. The goal is to > be small, fast, and language independent server that can host web > frameworks. I have written a small Ruby binding which provides a Rack > handler - this will allow Ebb to host Rails, Merb, and other Ruby > frameworks. In the future I will write a Python WSGI binding. > > The design is similar to the evented Mongrel web server. Connections > are processed as follows: > > 1. libev loops and waits for incoming connections. > 2. When Ebb can read from a client socket, it passes the buffer into the > mongrel state machine which parses the headers into name value pairs. > 3. Ebb starts a new thread and passes the request information and peer socket > to a user supplied callback. The thread lasts only for the length of that > callback. > 4. The included Ruby binding, supplying this callback transforms the request > into a Rack compatible "env" variable and passes it on a Rack adapter. > > The code measures in at less than 1000 lines of C code. > > There is much work to do; it is not ready for use. I am soliciting > help from the community for testing and development. You may browse > the git repository at http://repo.or.cz/w/ebb.git or check out the > code with this command: > git clone git://repo.or.cz/ebb.git > I release Ebb under the MIT license. > It is very fun to program Ebb so I suggest you do too :) > > > Ry Dahl > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- Ersin Er
Hey Ry, Your project looks amazing. I had a look at rev to use libev, but it seems to be Ruby 1.9 only and I''m far from a C expert. So right now Thin uses EventMachine. I really like your idea and I think we could help each other in building something very cool. If you''d like to participate in Thin and have some suggestions on how to make it better we should have a talk. Send me an email if you''re interested. Marc On 14-Jan-08, at 1:21 PM, Ersin Er wrote:> Good luck with your new server! I also suggest looking at Thin which > has been developed very recently and seems quite promising: > > http://code.macournoyer.com/thin/ > > According to the benchmarks it''s the fastest Ruby web server > currently. > > On Jan 14, 2008 6:43 PM, ry dahl <ry at tinyclouds.org> wrote: >> Hello Mongrel Users, >> >> I''m writing a web server called Ebb. It''s written in C, makes use of >> the Mongrel HTTP parser, and uses libev its event loop. The goal is >> to >> be small, fast, and language independent server that can host web >> frameworks. I have written a small Ruby binding which provides a Rack >> handler - this will allow Ebb to host Rails, Merb, and other Ruby >> frameworks. In the future I will write a Python WSGI binding. >> >> The design is similar to the evented Mongrel web server. Connections >> are processed as follows: >> >> 1. libev loops and waits for incoming connections. >> 2. When Ebb can read from a client socket, it passes the buffer >> into the >> mongrel state machine which parses the headers into name value >> pairs. >> 3. Ebb starts a new thread and passes the request information and >> peer socket >> to a user supplied callback. The thread lasts only for the length >> of that >> callback. >> 4. The included Ruby binding, supplying this callback transforms >> the request >> into a Rack compatible "env" variable and passes it on a Rack >> adapter. >> >> The code measures in at less than 1000 lines of C code. >> >> There is much work to do; it is not ready for use. I am soliciting >> help from the community for testing and development. You may browse >> the git repository at http://repo.or.cz/w/ebb.git or check out the >> code with this command: >> git clone git://repo.or.cz/ebb.git >> I release Ebb under the MIT license. >> It is very fun to program Ebb so I suggest you do too :) >> >> >> Ry Dahl >> _______________________________________________ >> Mongrel-users mailing list >> Mongrel-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-users >> > > > > -- > Ersin Er > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
> A svn repo clone? (git-svn)? Not all jumped into the git bandwagon :-)Sorry - my hosting abilities are limited. I also find the multitude of revision control software annoying (but git seems functional!) apt-get install git ry
On Jan 14, 2008 4:56 PM, ry dahl <ry at tinyclouds.org> wrote:> > A svn repo clone? (git-svn)? Not all jumped into the git bandwagon :-) > > Sorry - my hosting abilities are limited. I also find the multitude of > revision control software annoying (but git seems functional!) > apt-get install git >no apt-get on Windows. And git support on it is a bit flacky (I hear another git versus *nix versus windows discussion starting). I''m on Bazaar, which is the same used by Ubuntu :-) http://bazaar-vcs.org/BzrVsGit Anyway, have git but not on my Windows box. Will check your code this weekend ;-) -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Jan 14, 2008, at 8:43 AM, ry dahl wrote:> Hello Mongrel Users, > > I''m writing a web server called Ebb. It''s written in C, makes use of > the Mongrel HTTP parser, and uses libev its event loop. The goal is to > be small, fast, and language independent server that can host web > frameworks. I have written a small Ruby binding which provides a Rack > handler - this will allow Ebb to host Rails, Merb, and other Ruby > frameworks. In the future I will write a Python WSGI binding. > > The design is similar to the evented Mongrel web server. Connections > are processed as follows: > > 1. libev loops and waits for incoming connections. > 2. When Ebb can read from a client socket, it passes the buffer into > the > mongrel state machine which parses the headers into name value > pairs. > 3. Ebb starts a new thread and passes the request information and > peer socket > to a user supplied callback. The thread lasts only for the length > of that > callback. > 4. The included Ruby binding, supplying this callback transforms the > request > into a Rack compatible "env" variable and passes it on a Rack > adapter. > > The code measures in at less than 1000 lines of C code. > > There is much work to do; it is not ready for use. I am soliciting > help from the community for testing and development. You may browse > the git repository at http://repo.or.cz/w/ebb.git or check out the > code with this command: > git clone git://repo.or.cz/ebb.git > I release Ebb under the MIT license. > It is very fun to program Ebb so I suggest you do too :) > > > Ry DahlHey Ry- Is glib-2.0 a dependency? It seems like 2.0 is an old version of glib. So ebb doesn''t compile on leopard out of the box. What do I need to install to make it work? ~/ebb > make gcc -g -Wall `pkg-config --cflags glib-2.0` -I/opt/libev-2.01/include - L/opt/libev-2.01/lib -c tcp.c -o tcp.o Package glib-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `glib-2.0.pc'' to the PKG_CONFIG_PATH environment variable No package ''glib-2.0'' found tcp.c:18:16: error: ev.h: No such file or directory tcp.c:19:18: error: glib.h: No such file or directory In file included from tcp.c:23: tcp.h:48: error: syntax error before ?GQueue? tcp.h:48: warning: no semicolon at end of struct or union tcp.h:53: error: syntax error before ?*? token tcp.h:53: warning: type defaults to ?int? in declaration of ?accept_watcher? tcp.h:53: warning: data definition has no type or storage class tcp.h:55: error: syntax error before ?}? token tcp.h:72: error: syntax error before ?ev_io? tcp.h:72: warning: no semicolon at end of struct or union tcp.c: In function ?tcp_client_write?: tcp.c:33: error: dereferencing pointer to incomplete type tcp.c:34: error: dereferencing pointer to incomplete type tcp.c:36: warning: implicit declaration of function ?g_log? tcp.c:36: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this function) tcp.c:36: error: (Each undeclared identifier is reported only once tcp.c:36: error: for each function it appears in.) tcp.c: At top level: tcp.c:46: warning: ?struct ev_io? declared inside parameter list tcp.c:46: warning: its scope is only this definition or declaration, which is probably not what you want tcp.c: In function ?tcp_client_on_readable?: tcp.c:48: error: dereferencing pointer to incomplete type tcp.c:52: error: ?EV_ERROR? undeclared (first use in this function) tcp.c:53: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this function) tcp.c:57: error: dereferencing pointer to incomplete type tcp.c:58: error: dereferencing pointer to incomplete type tcp.c:59: error: dereferencing pointer to incomplete type tcp.c:60: error: dereferencing pointer to incomplete type tcp.c:62: error: dereferencing pointer to incomplete type tcp.c:64: error: dereferencing pointer to incomplete type tcp.c:64: error: dereferencing pointer to incomplete type tcp.c:67: warning: implicit declaration of function ?g_debug? tcp.c:81: error: dereferencing pointer to incomplete type tcp.c:81: error: dereferencing pointer to incomplete type tcp.c:81: error: dereferencing pointer to incomplete type tcp.c: In function ?tcp_client_new?: tcp.c:95: warning: implicit declaration of function ?g_new0? tcp.c:95: error: syntax error before ?tcp_client? tcp.c:97: error: dereferencing pointer to incomplete type tcp.c:99: error: dereferencing pointer to incomplete type tcp.c:99: error: dereferencing pointer to incomplete type tcp.c:99: error: dereferencing pointer to incomplete type tcp.c:100: error: dereferencing pointer to incomplete type tcp.c:101: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this function) tcp.c:105: error: dereferencing pointer to incomplete type tcp.c:105: error: ?TRUE? undeclared (first use in this function) tcp.c:107: error: dereferencing pointer to incomplete type tcp.c:113: error: dereferencing pointer to incomplete type tcp.c:115: error: dereferencing pointer to incomplete type tcp.c:115: error: syntax error before ?struct? tcp.c:116: error: dereferencing pointer to incomplete type tcp.c:117: warning: implicit declaration of function ?ev_init? tcp.c:117: error: dereferencing pointer to incomplete type tcp.c:118: warning: implicit declaration of function ?ev_io_set? tcp.c:118: error: dereferencing pointer to incomplete type tcp.c:118: error: dereferencing pointer to incomplete type tcp.c:118: error: ?EV_READ? undeclared (first use in this function) tcp.c:118: error: ?EV_ERROR? undeclared (first use in this function) tcp.c:119: warning: implicit declaration of function ?ev_io_start? tcp.c:119: error: dereferencing pointer to incomplete type tcp.c:119: error: dereferencing pointer to incomplete type tcp.c: In function ?tcp_client_stop_read_watcher?: tcp.c:131: error: dereferencing pointer to incomplete type tcp.c:134: error: dereferencing pointer to incomplete type tcp.c:136: warning: implicit declaration of function ?ev_io_stop? tcp.c:136: error: dereferencing pointer to incomplete type tcp.c:136: error: dereferencing pointer to incomplete type tcp.c:137: error: dereferencing pointer to incomplete type tcp.c:138: error: dereferencing pointer to incomplete type tcp.c: In function ?tcp_client_free?: tcp.c:146: error: dereferencing pointer to incomplete type tcp.c: In function ?tcp_client_close?: tcp.c:153: error: dereferencing pointer to incomplete type tcp.c:155: error: dereferencing pointer to incomplete type tcp.c:156: error: dereferencing pointer to incomplete type tcp.c:156: error: ?FALSE? undeclared (first use in this function) tcp.c: In function ?tcp_server_new?: tcp.c:165: error: syntax error before ?tcp_server? tcp.c:167: error: dereferencing pointer to incomplete type tcp.c:168: error: dereferencing pointer to incomplete type tcp.c:170: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this function) tcp.c:175: error: dereferencing pointer to incomplete type tcp.c:189: error: dereferencing pointer to incomplete type tcp.c:189: warning: implicit declaration of function ?ev_loop_new? tcp.c:191: error: dereferencing pointer to incomplete type tcp.c:191: warning: implicit declaration of function ?g_queue_new? tcp.c:192: error: dereferencing pointer to incomplete type tcp.c:192: error: ?FALSE? undeclared (first use in this function) tcp.c: In function ?tcp_server_free?: tcp.c:203: warning: implicit declaration of function ?g_queue_free? tcp.c:203: error: dereferencing pointer to incomplete type tcp.c: In function ?tcp_server_close?: tcp.c:211: error: dereferencing pointer to incomplete type tcp.c:214: warning: implicit declaration of function ?g_queue_pop_head? tcp.c:214: error: dereferencing pointer to incomplete type tcp.c:214: warning: assignment makes pointer from integer without a cast tcp.c:217: error: dereferencing pointer to incomplete type tcp.c:218: error: dereferencing pointer to incomplete type tcp.c:219: error: dereferencing pointer to incomplete type tcp.c:221: error: dereferencing pointer to incomplete type tcp.c:222: error: dereferencing pointer to incomplete type tcp.c:223: error: dereferencing pointer to incomplete type tcp.c:225: error: dereferencing pointer to incomplete type tcp.c:227: error: dereferencing pointer to incomplete type tcp.c:227: error: dereferencing pointer to incomplete type tcp.c:228: error: dereferencing pointer to incomplete type tcp.c:229: error: dereferencing pointer to incomplete type tcp.c:231: warning: implicit declaration of function ?ev_unloop? tcp.c:231: error: dereferencing pointer to incomplete type tcp.c:231: error: ?EVUNLOOP_ALL? undeclared (first use in this function) tcp.c:232: warning: implicit declaration of function ?ev_loop_destroy? tcp.c:232: error: dereferencing pointer to incomplete type tcp.c:233: error: dereferencing pointer to incomplete type tcp.c:235: error: dereferencing pointer to incomplete type tcp.c:236: error: dereferencing pointer to incomplete type tcp.c:236: error: ?FALSE? undeclared (first use in this function) tcp.c: At top level: tcp.c:242: warning: ?struct ev_io? declared inside parameter list tcp.c: In function ?tcp_server_accept?: tcp.c:244: error: dereferencing pointer to incomplete type tcp.c:247: error: dereferencing pointer to incomplete type tcp.c:248: error: dereferencing pointer to incomplete type tcp.c:251: error: ?EV_ERROR? undeclared (first use in this function) tcp.c:252: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this function) tcp.c:258: warning: implicit declaration of function ?g_queue_push_head? tcp.c:258: error: dereferencing pointer to incomplete type tcp.c:258: error: ?gpointer? undeclared (first use in this function) tcp.c:258: error: syntax error before ?client? tcp.c:260: error: dereferencing pointer to incomplete type tcp.c:261: error: dereferencing pointer to incomplete type tcp.c:261: error: dereferencing pointer to incomplete type tcp.c: In function ?tcp_server_listen?: tcp.c:276: error: dereferencing pointer to incomplete type tcp.c:277: error: dereferencing pointer to incomplete type tcp.c:280: error: dereferencing pointer to incomplete type tcp.c:281: error: dereferencing pointer to incomplete type tcp.c:283: error: dereferencing pointer to incomplete type tcp.c:284: error: dereferencing pointer to incomplete type tcp.c:284: error: dereferencing pointer to incomplete type tcp.c:285: error: ?G_LOG_LEVEL_ERROR? undeclared (first use in this function) tcp.c:288: error: dereferencing pointer to incomplete type tcp.c:288: error: dereferencing pointer to incomplete type tcp.c:298: error: dereferencing pointer to incomplete type tcp.c:298: error: dereferencing pointer to incomplete type tcp.c:298: error: dereferencing pointer to incomplete type tcp.c:304: error: dereferencing pointer to incomplete type tcp.c:310: error: dereferencing pointer to incomplete type tcp.c:310: error: ?FALSE? undeclared (first use in this function) tcp.c:311: error: dereferencing pointer to incomplete type tcp.c:311: error: ?TRUE? undeclared (first use in this function) tcp.c:313: error: dereferencing pointer to incomplete type tcp.c:313: error: syntax error before ?struct? tcp.c:314: error: dereferencing pointer to incomplete type tcp.c:315: error: dereferencing pointer to incomplete type tcp.c:316: error: dereferencing pointer to incomplete type tcp.c:318: error: dereferencing pointer to incomplete type tcp.c:319: error: dereferencing pointer to incomplete type tcp.c:319: error: dereferencing pointer to incomplete type tcp.c:319: error: ?EV_READ? undeclared (first use in this function) tcp.c:319: error: ?EV_ERROR? undeclared (first use in this function) tcp.c:320: error: dereferencing pointer to incomplete type tcp.c:320: error: dereferencing pointer to incomplete type tcp.c:321: warning: implicit declaration of function ?ev_loop? tcp.c:321: error: dereferencing pointer to incomplete type tcp.c: In function ?tcp_server_address?: tcp.c:331: error: dereferencing pointer to incomplete type tcp.c:332: error: dereferencing pointer to incomplete type tcp.c:335: warning: control reaches end of non-void function make: *** [tcp.o] Error 1 Thanks - Ezra Zygmuntowicz -- Founder & Software Architect -- ezra at engineyard.com -- EngineYard.com
Hi Erza, I''m not sure if glib is installed by default on macs. (Seems like it should be but I don''t see it on mine.) If you use fink you can do apt-get install glib2-dev The makefile is pretty hacky - make sure you have libev in your LIBRARY_PATH and ev.h in your CPATH ry On Jan 14, 2008 10:03 PM, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:> > > On Jan 14, 2008, at 8:43 AM, ry dahl wrote: > > > Hello Mongrel Users, > > > > I''m writing a web server called Ebb. It''s written in C, makes use of > > the Mongrel HTTP parser, and uses libev its event loop. The goal is to > > be small, fast, and language independent server that can host web > > frameworks. I have written a small Ruby binding which provides a Rack > > handler - this will allow Ebb to host Rails, Merb, and other Ruby > > frameworks. In the future I will write a Python WSGI binding. > > > > The design is similar to the evented Mongrel web server. Connections > > are processed as follows: > > > > 1. libev loops and waits for incoming connections. > > 2. When Ebb can read from a client socket, it passes the buffer into > > the > > mongrel state machine which parses the headers into name value > > pairs. > > 3. Ebb starts a new thread and passes the request information and > > peer socket > > to a user supplied callback. The thread lasts only for the length > > of that > > callback. > > 4. The included Ruby binding, supplying this callback transforms the > > request > > into a Rack compatible "env" variable and passes it on a Rack > > adapter. > > > > The code measures in at less than 1000 lines of C code. > > > > There is much work to do; it is not ready for use. I am soliciting > > help from the community for testing and development. You may browse > > the git repository at http://repo.or.cz/w/ebb.git or check out the > > code with this command: > > git clone git://repo.or.cz/ebb.git > > I release Ebb under the MIT license. > > It is very fun to program Ebb so I suggest you do too :) > > > > > > Ry Dahl > > Hey Ry- > > Is glib-2.0 a dependency? It seems like 2.0 is an old version of > glib. So ebb doesn''t compile on leopard out of the box. What do I need > to install to make it work? > > ~/ebb > make > gcc -g -Wall `pkg-config --cflags glib-2.0` -I/opt/libev-2.01/include - > L/opt/libev-2.01/lib -c tcp.c -o tcp.o > Package glib-2.0 was not found in the pkg-config search path. > Perhaps you should add the directory containing `glib-2.0.pc'' > to the PKG_CONFIG_PATH environment variable > No package ''glib-2.0'' found > tcp.c:18:16: error: ev.h: No such file or directory > tcp.c:19:18: error: glib.h: No such file or directory > In file included from tcp.c:23: > tcp.h:48: error: syntax error before ''GQueue'' > tcp.h:48: warning: no semicolon at end of struct or union > tcp.h:53: error: syntax error before ''*'' token > tcp.h:53: warning: type defaults to ''int'' in declaration of > ''accept_watcher'' > tcp.h:53: warning: data definition has no type or storage class > tcp.h:55: error: syntax error before ''}'' token > tcp.h:72: error: syntax error before ''ev_io'' > tcp.h:72: warning: no semicolon at end of struct or union > tcp.c: In function ''tcp_client_write'': > tcp.c:33: error: dereferencing pointer to incomplete type > tcp.c:34: error: dereferencing pointer to incomplete type > tcp.c:36: warning: implicit declaration of function ''g_log'' > tcp.c:36: error: ''G_LOG_LEVEL_ERROR'' undeclared (first use in this > function) > tcp.c:36: error: (Each undeclared identifier is reported only once > tcp.c:36: error: for each function it appears in.) > tcp.c: At top level: > tcp.c:46: warning: ''struct ev_io'' declared inside parameter list > tcp.c:46: warning: its scope is only this definition or declaration, > which is probably not what you want > tcp.c: In function ''tcp_client_on_readable'': > tcp.c:48: error: dereferencing pointer to incomplete type > tcp.c:52: error: ''EV_ERROR'' undeclared (first use in this function) > tcp.c:53: error: ''G_LOG_LEVEL_ERROR'' undeclared (first use in this > function) > tcp.c:57: error: dereferencing pointer to incomplete type > tcp.c:58: error: dereferencing pointer to incomplete type > tcp.c:59: error: dereferencing pointer to incomplete type > tcp.c:60: error: dereferencing pointer to incomplete type > tcp.c:62: error: dereferencing pointer to incomplete type > tcp.c:64: error: dereferencing pointer to incomplete type > tcp.c:64: error: dereferencing pointer to incomplete type > tcp.c:67: warning: implicit declaration of function ''g_debug'' > tcp.c:81: error: dereferencing pointer to incomplete type > tcp.c:81: error: dereferencing pointer to incomplete type > tcp.c:81: error: dereferencing pointer to incomplete type > tcp.c: In function ''tcp_client_new'': > tcp.c:95: warning: implicit declaration of function ''g_new0'' > tcp.c:95: error: syntax error before ''tcp_client'' > tcp.c:97: error: dereferencing pointer to incomplete type > tcp.c:99: error: dereferencing pointer to incomplete type > tcp.c:99: error: dereferencing pointer to incomplete type > tcp.c:99: error: dereferencing pointer to incomplete type > tcp.c:100: error: dereferencing pointer to incomplete type > tcp.c:101: error: ''G_LOG_LEVEL_ERROR'' undeclared (first use in this > function) > tcp.c:105: error: dereferencing pointer to incomplete type > tcp.c:105: error: ''TRUE'' undeclared (first use in this function) > tcp.c:107: error: dereferencing pointer to incomplete type > tcp.c:113: error: dereferencing pointer to incomplete type > tcp.c:115: error: dereferencing pointer to incomplete type > tcp.c:115: error: syntax error before ''struct'' > tcp.c:116: error: dereferencing pointer to incomplete type > tcp.c:117: warning: implicit declaration of function ''ev_init'' > tcp.c:117: error: dereferencing pointer to incomplete type > tcp.c:118: warning: implicit declaration of function ''ev_io_set'' > tcp.c:118: error: dereferencing pointer to incomplete type > tcp.c:118: error: dereferencing pointer to incomplete type > tcp.c:118: error: ''EV_READ'' undeclared (first use in this function) > tcp.c:118: error: ''EV_ERROR'' undeclared (first use in this function) > tcp.c:119: warning: implicit declaration of function ''ev_io_start'' > tcp.c:119: error: dereferencing pointer to incomplete type > tcp.c:119: error: dereferencing pointer to incomplete type > tcp.c: In function ''tcp_client_stop_read_watcher'': > tcp.c:131: error: dereferencing pointer to incomplete type > tcp.c:134: error: dereferencing pointer to incomplete type > tcp.c:136: warning: implicit declaration of function ''ev_io_stop'' > tcp.c:136: error: dereferencing pointer to incomplete type > tcp.c:136: error: dereferencing pointer to incomplete type > tcp.c:137: error: dereferencing pointer to incomplete type > tcp.c:138: error: dereferencing pointer to incomplete type > tcp.c: In function ''tcp_client_free'': > tcp.c:146: error: dereferencing pointer to incomplete type > tcp.c: In function ''tcp_client_close'': > tcp.c:153: error: dereferencing pointer to incomplete type > tcp.c:155: error: dereferencing pointer to incomplete type > tcp.c:156: error: dereferencing pointer to incomplete type > tcp.c:156: error: ''FALSE'' undeclared (first use in this function) > tcp.c: In function ''tcp_server_new'': > tcp.c:165: error: syntax error before ''tcp_server'' > tcp.c:167: error: dereferencing pointer to incomplete type > tcp.c:168: error: dereferencing pointer to incomplete type > tcp.c:170: error: ''G_LOG_LEVEL_ERROR'' undeclared (first use in this > function) > tcp.c:175: error: dereferencing pointer to incomplete type > tcp.c:189: error: dereferencing pointer to incomplete type > tcp.c:189: warning: implicit declaration of function ''ev_loop_new'' > tcp.c:191: error: dereferencing pointer to incomplete type > tcp.c:191: warning: implicit declaration of function ''g_queue_new'' > tcp.c:192: error: dereferencing pointer to incomplete type > tcp.c:192: error: ''FALSE'' undeclared (first use in this function) > tcp.c: In function ''tcp_server_free'': > tcp.c:203: warning: implicit declaration of function ''g_queue_free'' > tcp.c:203: error: dereferencing pointer to incomplete type > tcp.c: In function ''tcp_server_close'': > tcp.c:211: error: dereferencing pointer to incomplete type > tcp.c:214: warning: implicit declaration of function ''g_queue_pop_head'' > tcp.c:214: error: dereferencing pointer to incomplete type > tcp.c:214: warning: assignment makes pointer from integer without a cast > tcp.c:217: error: dereferencing pointer to incomplete type > tcp.c:218: error: dereferencing pointer to incomplete type > tcp.c:219: error: dereferencing pointer to incomplete type > tcp.c:221: error: dereferencing pointer to incomplete type > tcp.c:222: error: dereferencing pointer to incomplete type > tcp.c:223: error: dereferencing pointer to incomplete type > tcp.c:225: error: dereferencing pointer to incomplete type > tcp.c:227: error: dereferencing pointer to incomplete type > tcp.c:227: error: dereferencing pointer to incomplete type > tcp.c:228: error: dereferencing pointer to incomplete type > tcp.c:229: error: dereferencing pointer to incomplete type > tcp.c:231: warning: implicit declaration of function ''ev_unloop'' > tcp.c:231: error: dereferencing pointer to incomplete type > tcp.c:231: error: ''EVUNLOOP_ALL'' undeclared (first use in this function) > tcp.c:232: warning: implicit declaration of function ''ev_loop_destroy'' > tcp.c:232: error: dereferencing pointer to incomplete type > tcp.c:233: error: dereferencing pointer to incomplete type > tcp.c:235: error: dereferencing pointer to incomplete type > tcp.c:236: error: dereferencing pointer to incomplete type > tcp.c:236: error: ''FALSE'' undeclared (first use in this function) > tcp.c: At top level: > tcp.c:242: warning: ''struct ev_io'' declared inside parameter list > tcp.c: In function ''tcp_server_accept'': > tcp.c:244: error: dereferencing pointer to incomplete type > tcp.c:247: error: dereferencing pointer to incomplete type > tcp.c:248: error: dereferencing pointer to incomplete type > tcp.c:251: error: ''EV_ERROR'' undeclared (first use in this function) > tcp.c:252: error: ''G_LOG_LEVEL_ERROR'' undeclared (first use in this > function) > tcp.c:258: warning: implicit declaration of function ''g_queue_push_head'' > tcp.c:258: error: dereferencing pointer to incomplete type > tcp.c:258: error: ''gpointer'' undeclared (first use in this function) > tcp.c:258: error: syntax error before ''client'' > tcp.c:260: error: dereferencing pointer to incomplete type > tcp.c:261: error: dereferencing pointer to incomplete type > tcp.c:261: error: dereferencing pointer to incomplete type > tcp.c: In function ''tcp_server_listen'': > tcp.c:276: error: dereferencing pointer to incomplete type > tcp.c:277: error: dereferencing pointer to incomplete type > tcp.c:280: error: dereferencing pointer to incomplete type > tcp.c:281: error: dereferencing pointer to incomplete type > tcp.c:283: error: dereferencing pointer to incomplete type > tcp.c:284: error: dereferencing pointer to incomplete type > tcp.c:284: error: dereferencing pointer to incomplete type > tcp.c:285: error: ''G_LOG_LEVEL_ERROR'' undeclared (first use in this > function) > tcp.c:288: error: dereferencing pointer to incomplete type > tcp.c:288: error: dereferencing pointer to incomplete type > tcp.c:298: error: dereferencing pointer to incomplete type > tcp.c:298: error: dereferencing pointer to incomplete type > tcp.c:298: error: dereferencing pointer to incomplete type > tcp.c:304: error: dereferencing pointer to incomplete type > tcp.c:310: error: dereferencing pointer to incomplete type > tcp.c:310: error: ''FALSE'' undeclared (first use in this function) > tcp.c:311: error: dereferencing pointer to incomplete type > tcp.c:311: error: ''TRUE'' undeclared (first use in this function) > tcp.c:313: error: dereferencing pointer to incomplete type > tcp.c:313: error: syntax error before ''struct'' > tcp.c:314: error: dereferencing pointer to incomplete type > tcp.c:315: error: dereferencing pointer to incomplete type > tcp.c:316: error: dereferencing pointer to incomplete type > tcp.c:318: error: dereferencing pointer to incomplete type > tcp.c:319: error: dereferencing pointer to incomplete type > tcp.c:319: error: dereferencing pointer to incomplete type > tcp.c:319: error: ''EV_READ'' undeclared (first use in this function) > tcp.c:319: error: ''EV_ERROR'' undeclared (first use in this function) > tcp.c:320: error: dereferencing pointer to incomplete type > tcp.c:320: error: dereferencing pointer to incomplete type > tcp.c:321: warning: implicit declaration of function ''ev_loop'' > tcp.c:321: error: dereferencing pointer to incomplete type > tcp.c: In function ''tcp_server_address'': > tcp.c:331: error: dereferencing pointer to incomplete type > tcp.c:332: error: dereferencing pointer to incomplete type > tcp.c:335: warning: control reaches end of non-void function > make: *** [tcp.o] Error 1 > > > Thanks > > > - Ezra Zygmuntowicz > -- Founder & Software Architect > -- ezra at engineyard.com > -- EngineYard.com > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >
An alternative might be github.com. It looks like they provide svn mirrors of your git repos. On Jan 14, 2008 1:50 PM, Luis Lavena <luislavena at gmail.com> wrote:> On Jan 14, 2008 4:56 PM, ry dahl <ry at tinyclouds.org> wrote: > > > A svn repo clone? (git-svn)? Not all jumped into the git bandwagon :-) > > > > Sorry - my hosting abilities are limited. I also find the multitude of > > revision control software annoying (but git seems functional!) > > apt-get install git > > > > no apt-get on Windows. And git support on it is a bit flacky > (I hear another git versus *nix versus windows discussion starting). > > I''m on Bazaar, which is the same used by Ubuntu :-) > > http://bazaar-vcs.org/BzrVsGit > > Anyway, have git but not on my Windows box. > > Will check your code this weekend ;-) > > -- > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > _______________________________________________ > > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-- Cheers, Kevin Williams http://www.bantamtech.com/
Ezra, libev will be in MacPorts later tonight or tomorrow, and with glib2 installed, Ebb builds cleanly on Leopard. best, Brett Ezra Zygmuntowicz wrote:> On Jan 14, 2008, at 8:43 AM, ry dahl wrote:> Hey Ry- > > Is glib-2.0 a dependency? It seems like 2.0 is an old version of > glib. So ebb doesn''t compile on leopard out of the box. What do I need > to install to make it work? > > <snip> > > Thanks > > > - Ezra Zygmuntowicz > -- Founder & Software Architect > -- ezra at engineyard.com > -- EngineYard.com-- Posted via http://www.ruby-forum.com/.
On Jan 14, 2008 11:43 AM, ry dahl <ry at tinyclouds.org> wrote:> Hello Mongrel Users, > > I''m writing a web server called Ebb. It''s written in C, makes use of > the Mongrel HTTP parser, and uses libev its event loop. The goal is to > be small, fast, and language independent server that can host web > frameworks. I have written a small Ruby binding which provides a Rack > handler - this will allow Ebb to host Rails, Merb, and other Ruby > frameworks. In the future I will write a Python WSGI binding. > > The design is similar to the evented Mongrel web server. Connections > are processed as follows: > > 1. libev loops and waits for incoming connections. > 2. When Ebb can read from a client socket, it passes the buffer into the > mongrel state machine which parses the headers into name value pairs. > 3. Ebb starts a new thread and passes the request information and peer > socket > to a user supplied callback. The thread lasts only for the length of > that > callback. > 4. The included Ruby binding, supplying this callback transforms the > request > into a Rack compatible "env" variable and passes it on a Rack adapter. > > The code measures in at less than 1000 lines of C code. > > There is much work to do; it is not ready for use. I am soliciting > help from the community for testing and development. You may browse > the git repository at http://repo.or.cz/w/ebb.git or check out the > code with this command: > git clone git://repo.or.cz/ebb.git > I release Ebb under the MIT license. > It is very fun to program Ebb so I suggest you do too :) > > > Ry Dahl >Ry, Awesome, great idea! I will definitely be checking this out hopefully this weekend ~Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20080118/16af0520/attachment.html
Hey All, Just one more quick message to entice contributors to take a look at Ebb. I was able to run some preliminary benchmarks for the first time today against evented Mongrel and Thin. They''re all running a small Camping application through Rack. http://s3.amazonaws.com/four.livejournal/20080121/ebb.png The code for that benchmark (and chart generation) can be found in the Ebb repo: http://repo.or.cz/w/ebb.git?a=commit;h=c2fecde0a04603727949ec0b05d694be89a464d2 ry On Jan 14, 2008 5:43 PM, ry dahl <ry at tinyclouds.org> wrote:> Hello Mongrel Users, > > I''m writing a web server called Ebb. It''s written in C, makes use of > the Mongrel HTTP parser, and uses libev its event loop. The goal is to > be small, fast, and language independent server that can host web > frameworks. I have written a small Ruby binding which provides a Rack > handler - this will allow Ebb to host Rails, Merb, and other Ruby > frameworks. In the future I will write a Python WSGI binding. > > The design is similar to the evented Mongrel web server. Connections > are processed as follows: > > 1. libev loops and waits for incoming connections. > 2. When Ebb can read from a client socket, it passes the buffer into the > mongrel state machine which parses the headers into name value pairs. > 3. Ebb starts a new thread and passes the request information and peer socket > to a user supplied callback. The thread lasts only for the length of that > callback. > 4. The included Ruby binding, supplying this callback transforms the request > into a Rack compatible "env" variable and passes it on a Rack adapter. > > The code measures in at less than 1000 lines of C code. > > There is much work to do; it is not ready for use. I am soliciting > help from the community for testing and development. You may browse > the git repository at http://repo.or.cz/w/ebb.git or check out the > code with this command: > git clone git://repo.or.cz/ebb.git > I release Ebb under the MIT license. > It is very fun to program Ebb so I suggest you do too :) > > > Ry Dahl >
On Jan 21, 2008 6:34 PM, ry dahl <ry at tinyclouds.org> wrote:> Hey All, > > Just one more quick message to entice contributors to take a look at > Ebb. I was able to run some preliminary benchmarks for the first time > today against evented Mongrel and Thin. They''re all running a small > Camping application through Rack. > > http://s3.amazonaws.com/four.livejournal/20080121/ebb.png >Hey ry, did you tweaked the HttpParser like Thin guy did? I was thinking about the modifications he did: He removed all the if conditions evaluating http_field, request_method, request_uri and others (most the ones that are allocated/initialized in HttpParser_alloc). But since I couldn''t find time to ask it in a separate mail, is time that boost the question using your thread ;-)> The code for that benchmark (and chart generation) can be found in the Ebb repo: > http://repo.or.cz/w/ebb.git?a=commit;h=c2fecde0a04603727949ec0b05d694be89a464d2svn mirror is coming, right? :-D -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Jan 21, 2008 1:55 PM, Luis Lavena <luislavena at gmail.com> wrote:> Hey ry, did you tweaked the HttpParser like Thin guy did? > > I was thinking about the modifications he did: > > He removed all the if conditions evaluating http_field, > request_method, request_uri and others (most the ones that are > allocated/initialized in HttpParser_alloc).I don''t think those conditions were *removed*, I think they were *moved*, but I''ve only glanced at the C code and would barely know what I was looking at anyway. :) -- Cheers, Kevin Williams http://www.bantamtech.com/ http://www.almostserio.us/ http://kevwil.com/
On Jan 21, 2008 7:00 PM, Kevin Williams <kevwil at gmail.com> wrote:> On Jan 21, 2008 1:55 PM, Luis Lavena <luislavena at gmail.com> wrote: > > Hey ry, did you tweaked the HttpParser like Thin guy did? > > > > I was thinking about the modifications he did: > > > > He removed all the if conditions evaluating http_field, > > request_method, request_uri and others (most the ones that are > > allocated/initialized in HttpParser_alloc). > > I don''t think those conditions were *removed*, I think they were > *moved*, but I''ve only glanced at the C code and would barely know > what I was looking at anyway. :)No, he removed them: http://pastie.caboo.se/141633 The ragel code will generate the http11_parser.c file, and http11.c file defines all the functions pointers: http11.c:207..225: VALUE HttpParser_alloc(VALUE klass) { VALUE obj; http_parser *hp = ALLOC_N(http_parser, 1); TRACE(); hp->http_field = http_field; hp->request_method = request_method; hp->request_uri = request_uri; hp->fragment = fragment; hp->request_path = request_path; hp->query_string = query_string; hp->http_version = http_version; hp->header_done = header_done; http_parser_init(hp); obj = Data_Wrap_Struct(klass, NULL, HttpParser_free, hp); return obj; } Theory indicates that allocation happens way before the ragel code is getting executed, so there is no need to evaluate the conditions all the time, ending with a speed boost. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
yes I removed those conditions and looks like Ry did the same (by looking quickly at his code). On 21-Jan-08, at 4:12 PM, Luis Lavena wrote:> On Jan 21, 2008 7:00 PM, Kevin Williams <kevwil at gmail.com> wrote: >> On Jan 21, 2008 1:55 PM, Luis Lavena <luislavena at gmail.com> wrote: >>> Hey ry, did you tweaked the HttpParser like Thin guy did? >>> >>> I was thinking about the modifications he did: >>> >>> He removed all the if conditions evaluating http_field, >>> request_method, request_uri and others (most the ones that are >>> allocated/initialized in HttpParser_alloc). >> >> I don''t think those conditions were *removed*, I think they were >> *moved*, but I''ve only glanced at the C code and would barely know >> what I was looking at anyway. :) > > No, he removed them: > > http://pastie.caboo.se/141633 > > The ragel code will generate the http11_parser.c file, and http11.c > file defines all the functions pointers: > > http11.c:207..225: > > VALUE HttpParser_alloc(VALUE klass) > { > VALUE obj; > http_parser *hp = ALLOC_N(http_parser, 1); > TRACE(); > hp->http_field = http_field; > hp->request_method = request_method; > hp->request_uri = request_uri; > hp->fragment = fragment; > hp->request_path = request_path; > hp->query_string = query_string; > hp->http_version = http_version; > hp->header_done = header_done; > http_parser_init(hp); > > obj = Data_Wrap_Struct(klass, NULL, HttpParser_free, hp); > > return obj; > } > > Theory indicates that allocation happens way before the ragel code is > getting executed, so there is no need to evaluate the conditions all > the time, ending with a speed boost. > > -- > Luis Lavena > Multimedia systems > - > A common mistake that people make when trying to design > something completely foolproof is to underestimate > the ingenuity of complete fools. > Douglas Adams > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
I didn''t know about those mods. I pulled the parser code from Thin. ry
> svn mirror is coming, right? :-DHi Luis, I''ll put it on github when they open (or another service?) Apparently their svn bridge isn''t fully functional yet. ry
On Jan 21, 2008 7:46 PM, ry dahl <ry at tinyclouds.org> wrote:> > svn mirror is coming, right? :-D > > Hi Luis, > > I''ll put it on github when they open (or another service?) Apparently > their svn bridge isn''t fully functional yet.What you can do is ask for a rubyforge project and use the svn available there as mirror. I''m still waiting to get bzr-git with write support so I can use bazaar all the way :-) -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On Mon, 21 Jan 2008 21:34:22 +0100 "ry dahl" <ry at tinyclouds.org> wrote:> Hey All, > > Just one more quick message to entice contributors to take a look at > Ebb. I was able to run some preliminary benchmarks for the first time > today against evented Mongrel and Thin. They''re all running a small > Camping application through Rack. > > http://s3.amazonaws.com/four.livejournal/20080121/ebb.png > > The code for that benchmark (and chart generation) can be found in the Ebb repo: > http://repo.or.cz/w/ebb.git?a=commit;h=c2fecde0a04603727949ec0b05d694be89a464d2Grrrr, you need a Y axis Ry. What is that measuring. Hell, shoot me the raw data and I''ll do the graph with R (since I''m curious). -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Mon, 21 Jan 2008 19:12:06 -0200 "Luis Lavena" <luislavena at gmail.com> wrote:> No, he removed them: > > http://pastie.caboo.se/141633 > > The ragel code will generate the http11_parser.c file, and http11.c > file defines all the functions pointers:<snip>> Theory indicates that allocation happens way before the ragel code is > getting executed, so there is no need to evaluate the conditions all > the time, ending with a speed boost.That''s bullshit. All of those tests are simple checks to make sure that you aren''t passing in NULL pointers (which happens when the lib is used generally). Removing those would be a tiny little impact on the performance since they''re written in raw C. Only reason that''d speed things up is if the compiler wasn''t doing its job right (which is possible). It''s also a performance *loss* in that a user of the library has to set all callbacks always (or get a crash) and then every function is called even if a user of the lib only cares about a particular piece. Also, what''s happened is now the safety checks against invalid input are gone too. Any of those actions could fire in the parser section and if those variables are not set then the whole program will eat it bad. That''s a very bad design change, and now I wish I''d gone to the dude''s demonstration so I could tell him. If someone wanted to optimize this just for the case where every function is used and always set, but not lose safety then they should change the constructor to the library to require those functions always be set. Then you could remove the if-statements. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
thx for the pointer, I''ll change the constructor then On 21-Jan-08, at 5:06 PM, Zed A. Shaw wrote:> On Mon, 21 Jan 2008 19:12:06 -0200 > "Luis Lavena" <luislavena at gmail.com> wrote: > >> No, he removed them: >> >> http://pastie.caboo.se/141633 >> >> The ragel code will generate the http11_parser.c file, and http11.c >> file defines all the functions pointers: > <snip> >> Theory indicates that allocation happens way before the ragel code is >> getting executed, so there is no need to evaluate the conditions all >> the time, ending with a speed boost. > > That''s bullshit. All of those tests are simple checks to make sure > that you aren''t passing in NULL pointers (which happens when the lib > is > used generally). Removing those would be a tiny little impact on the > performance since they''re written in raw C. Only reason that''d speed > things up is if the compiler wasn''t doing its job right (which is > possible). > > It''s also a performance *loss* in that a user of the library has to > set > all callbacks always (or get a crash) and then every function is > called > even if a user of the lib only cares about a particular piece. > > Also, what''s happened is now the safety checks against invalid input > are gone too. Any of those actions could fire in the parser section > and if those variables are not set then the whole program will eat it > bad. > > That''s a very bad design change, and now I wish I''d gone to the dude''s > demonstration so I could tell him. > > If someone wanted to optimize this just for the case where every > function is used and always set, but not lose safety then they should > change the constructor to the library to require those functions > always > be set. Then you could remove the if-statements. > > -- > Zed A. Shaw > - Hate: http://savingtheinternetwithhate.com/ > - Good: http://www.zedshaw.com/ > - Evil: http://yearofevil.com/ > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users
On Jan 21, 2008 8:06 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> On Mon, 21 Jan 2008 19:12:06 -0200 > "Luis Lavena" <luislavena at gmail.com> wrote: > > > No, he removed them: > > > > http://pastie.caboo.se/141633 > > > > The ragel code will generate the http11_parser.c file, and http11.c > > file defines all the functions pointers: > <snip> > > Theory indicates that allocation happens way before the ragel code is > > getting executed, so there is no need to evaluate the conditions all > > the time, ending with a speed boost. > > That''s bullshit. All of those tests are simple checks to make sure > that you aren''t passing in NULL pointers (which happens when the lib is > used generally). Removing those would be a tiny little impact on the > performance since they''re written in raw C. Only reason that''d speed > things up is if the compiler wasn''t doing its job right (which is > possible). >Please Zed, I''m not validating nor arguing against that decision. I just exposing that, the way I asked on #thin irc channel too a few weeks back.> It''s also a performance *loss* in that a user of the library has to set > all callbacks always (or get a crash) and then every function is called > even if a user of the lib only cares about a particular piece. >That''s why I was wondering, but still couldn''t run my own series of tests to see how that change impact on overall performance.> Also, what''s happened is now the safety checks against invalid input > are gone too. Any of those actions could fire in the parser section > and if those variables are not set then the whole program will eat it > bad. > > That''s a very bad design change, and now I wish I''d gone to the dude''s > demonstration so I could tell him. > > If someone wanted to optimize this just for the case where every > function is used and always set, but not lose safety then they should > change the constructor to the library to require those functions always > be set. Then you could remove the if-statements. >Good point. Still, prove of performance improvement must me shown, but there also corner cases that exposes situations like you mention. Again: I''m just exposing the situation, that''s why the "in theory"... I''m not validating anything :-) -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
> Grrrr, you need a Y axis Ry. What is that measuring. Hell, shoot me > the raw data and I''ll do the graph with R (since I''m curious).The vertical axis is requests/sec (says at the top of the graph). I don''t bother to give actual numbers because it''s only to demonstrate the relative increase in speed. You can generate your own data with the script in ruby_bridge/benchmark/test_camping.rb ry
On Mon, 21 Jan 2008 20:08:46 -0200 "Luis Lavena" <luislavena at gmail.com> wrote:> > That''s bullshit. All of those tests are simple checks to make sure > > that you aren''t passing in NULL pointers (which happens when the lib is > > used generally). Removing those would be a tiny little impact on the > > performance since they''re written in raw C. Only reason that''d speed > > things up is if the compiler wasn''t doing its job right (which is > > possible). > > > > Please Zed, I''m not validating nor arguing against that decision. I > just exposing that, the way I asked on #thin irc channel too a few > weeks back.Sorry Luis, but I didn''t say "Luis, you''re a bullshitter." I said, "That''s bullshit." Meaning, the claim of a large performance increase from just removing a series of if-statements isn''t worth the loss in security and safety. You should know by now that if I *really* wanted to be mean to you I''d say it directly to you. I''m talking about the code, nobody directly or their personalities. -- Zed A. Shaw - Hate: http://savingtheinternetwithhate.com/ - Good: http://www.zedshaw.com/ - Evil: http://yearofevil.com/
On Jan 21, 2008 11:53 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:> On Mon, 21 Jan 2008 20:08:46 -0200 > "Luis Lavena" <luislavena at gmail.com> wrote: > > > > That''s bullshit. All of those tests are simple checks to make sure > > > that you aren''t passing in NULL pointers (which happens when the lib is > > > used generally). Removing those would be a tiny little impact on the > > > performance since they''re written in raw C. Only reason that''d speed > > > things up is if the compiler wasn''t doing its job right (which is > > > possible). > > > > > > > Please Zed, I''m not validating nor arguing against that decision. I > > just exposing that, the way I asked on #thin irc channel too a few > > weeks back. > > Sorry Luis, but I didn''t say "Luis, you''re a bullshitter." I said, > "That''s bullshit." Meaning, the claim of a large performance increase > from just removing a series of if-statements isn''t worth the loss in > security and safety. >I know Zed, Monday was not a good day :-P (so no personal offense, just bad wording from my side). I was thinking sending an email with this thing I discovered on thin code, but found the opportunity to ask here (on ry thread instead). Don''t you hate when you don''t have enough time to do all the things you love?> You should know by now that if I *really* wanted to be mean to you I''d > say it directly to you. I''m talking about the code, nobody directly or > their personalities.Yes Zed, thankfuly you wouldn''t, right? :-D I''m such a nice, lovely person, you couldn''t be mean to me ;-) Take care man, -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
On 21 Jan 2008, at 22:11, ry dahl wrote:>> Grrrr, you need a Y axis Ry. What is that measuring. Hell, shoot me >> the raw data and I''ll do the graph with R (since I''m curious). > > The vertical axis is requests/sec (says at the top of the graph). I > don''t bother to give actual numbers because it''s only to demonstrate > the relative increase in speed. You can generate your own data with > the script in ruby_bridge/benchmark/test_camping.rbI see what you''re saying but unfortunately without numbers on the ordinate -- specifically without knowing where zero is -- it''s impossible to evaluate even the relative differences. Anyway, I''ll have a go and generating my own data with that script. Thanks. Regards, Andy Stewart ------- http://airbladesoftware.com
> I see what you''re saying but unfortunately without numbers on the > ordinate -- specifically without knowing where zero is -- it''s > impossible to evaluate even the relative differences.Oh yeah, sorry, zero is at the the bottom. yes, the graph could be clearer.. below is my data - each line is an average of multiple runs of ab with -n 1000. (in truth, i avoid exposing my numbers because i''m a bit embarrassed of my ancient computer. i think if you run them on a modern computer, these numbers will be in the thousands.) ebb -c 1 = 113.5025 ebb -c 10 = 93.956 ebb -c 19 = 101.156 ebb -c 28 = 110.335 ebb -c 37 = 119.89 ebb -c 46 = 93.464 ebb -c 55 = 87.46 ebb -c 64 = 93.116 ebb -c 73 = 94.01 ebb -c 82 = 80.8566666666667 ebb -c 91 = 92.064 ebb -c 100 = 98.666 evented mongrel -c 1 = 80.586 evented mongrel -c 10 = 82.418 evented mongrel -c 19 = 76.1075 evented mongrel -c 28 = 82.0766666666667 evented mongrel -c 37 = 88.45 evented mongrel -c 46 = 69.486 evented mongrel -c 55 = 72.81 evented mongrel -c 64 = 67.07 evented mongrel -c 73 = 67.3566666666667 evented mongrel -c 82 = 65.74 evented mongrel -c 91 = 65.666 evented mongrel -c 100 = 64.388 thin -c 1 = 92.1575 thin -c 10 = 74.284 thin -c 19 = 76.8 thin -c 28 = 91.85 thin -c 37 = 91.55 thin -c 46 = 74.802 thin -c 55 = 74.9 thin -c 64 = 69.886 thin -c 73 = 70.2933333333333 thin -c 82 = 63.6933333333333 thin -c 91 = 70.206 thin -c 100 = 70.262 ry
On Jan 22, 2008 1:00 PM, ry dahl <ry at tinyclouds.org> wrote:> > I see what you''re saying but unfortunately without numbers on the > > ordinate -- specifically without knowing where zero is -- it''s > > impossible to evaluate even the relative differences. > > Oh yeah, sorry, zero is at the the bottom. yes, the graph could be > clearer.. below is my data - each line is an average of multiple runs > of ab with -n 1000.Great data Ry, thanks for it. For sake of completeness, can you compare it with plain mongrel?> (in truth, i avoid exposing my numbers because i''m a bit embarrassed > of my ancient computer. i think if you run them on a modern computer, > these numbers will be in the thousands.) >You shouldn''t! I was doing the first test compatibility for mongrel back in 2006 from a P3 800Mhz 512MB RAM computer! Not mention that first version of mongrel_service was created on that computer! So: don''t be hard on you ;-) -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams
> For sake of completeness, can you compare it with plain mongrel?Yes, i''ll do that in future benchmarks. The monkey patching that swiftiply does makes it not so easy to run regular mongrel and evented mongrel from the same script. Speaking of future benchmarks, I will not make announcements to mongrel-users about Ebb anymore. Instead I will post on my livejournal under the tag ''ebb'' http://four.livejournal.com/tag/ebb If you would like to exclude my other livejournal dribble and only get Ebb updates, use this feed: http://max.kanat.us/tag-syndicate/?user=four&tag=ebb The git repo itself also has a feed, which I will try to make interesting http://repo.or.cz/w/ebb.git?a=rss> I was doing the first test compatibility for mongrel back in 2006 from > a P3 800Mhz 512MB RAM computer!but that''s what i''m running now (eep!) ry