Sébastien Arnaud wrote:

> Here is the output I get for: AC_SYS_LARGEFILE
>
> checking for special C compiler options needed for large files... no
> checking for _FILE_OFFSET_BITS value needed for large files... no
> checking for _LARGE_FILES value needed for large files... no
>
> I added the following in macro.h(line 219) to go around the issue:
>
> #ifndef _FILE_OFFSET_BITS
> # define _FILE_OFFSET_BITS 64
> #endif

  Marko has sorted out this problem. Thanks for your help :-)

> Wow! it went from ~3000 to 5000 req/sec I would have thought kqueue
> would be better performing than poll. Maybe the error message we are
> getting above is hurting performance... Or it is maybe an incoherent
> behavior in OS 10.4 that even though not clearly acknowledge by
> Apple, has been witnessed by several other open source projects
> using kqueue.  Oh well, we'll see, it looks like OS 10.4.3 is right
> around the corner.

  Yeah, I think kqueue is meant to be much faster than poll.. at least
  its complexity is O(1) rather than O(n), isn't it?

> Anyway, Alo, I think that if we disable kqueue on OS X for now,
> cherokee is looking quite stable and showing good performance. I
> attached below a crude result from apache on OS X on the same  machine,
> same page requested (prefork).

  By the moment you can specify the polling mechanism in the
  configuration file using the "PollMethod" keyword. If kqueue is
  working alright in other BSDs we should not do that.

  I will try to take a look at it. Anyway, if someone has it running
  it in *BSD with kqueue(), please let me know how is it working.

> Actually this may be jumping to a different topic, I think it would
> be nice if you defined some standard benchmarking tests to run on
> cherokee so that after each new release those exact same test could
> be run on various platforms and against the other mainstream servers
> (apache, lighttpd, etc..) to make sure that cherokee's main feature
> (performance and scalibility) is maintained throughout new releases.

  Yeah, it is a pretty good idea.

  Actually, I wrote a script a few days ago.. it is something like
  that but focussed in the compilation process.  I will run it just
  before each release to ensure it Cherokee is building in all the
  possible ways: dynamic, static, u-Cherokee, GNUTLS and OpenSSL.

  http://svn.0x50.org/file/cherokee/debian_testing.sh
  http://svn.0x50.org/file/cherokee/debian_testing_chroot.sh

  It is very handy; the dark side is that it is Debian dependent.

  About the pre-release performance tests.. do you have some idea
  about how to approach it?

--
Greetings, alo.
_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee

Reply via email to