Ron Garret <·········@flownet.com> writes:
> Which one is better? (And what is the etymology of the name
> "Hutchentoot"?)
Gavino? Is that you?
Hunchenoot is better.
Zach
Zach Beane <····@xach.com> writes:
>> "Hutchentoot"?)
> Hunchenoot is better.
Hi Edi,
the name of your webserver is too complicated ...
:)
Jens
--
http://jensteich.de
On Jan 11, 10:21 am, Jens Teich <········@jensteich.de> wrote:
> Zach Beane <····@xach.com> writes:
> >> "Hutchentoot"?)
> > Hunchenoot is better.
>
> Hi Edi,
>
> the name of your webserver is too complicated ...
>
> :)
>
> Jens
>
> --http://jensteich.de
I call it hunch' :) . I can't judge AllegroServe since I tried only
through examples of it's tutorials. But hunch' is great, excellent
quality as a anytrademarked Ediware.
cheers
Slobodan
Jens Teich wrote:
> Zach Beane <····@xach.com> writes:
>
>>> "Hutchentoot"?)
>
>> Hunchenoot is better.
>
> Hi Edi,
>
> the name of your webserver is too complicated ...
>
> :)
...and the Logo sucks. It's no wonder that this Common Lisp thing
doesn't take off... ;)
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: alien_guy
Subject: Re: Hutchentoot or Allegroserve?
Date:
Message-ID: <fm5n3r$t71$1@aioe.org>
On Thu, 10 Jan 2008 09:52:22 -0800, Ron Garret wrote:
> Which one is better? (And what is the etymology of the name
> "Hutchentoot"?)
>
> rg
1) Many prefer Hunchentoot
2) http://members.cox.net/bill_lantz/pages/hunchentoot.html
P� Thu, 10 Jan 2008 18:52:22 +0100, skrev Ron Garret
<·········@flownet.com>:
> Which one is better? (And what is the etymology of the name
> "Hutchentoot"?)
>
> rg
I have used both and found they both provide a stable web developement
platform. Because I use LispWorks I prefer Hunchentoot as it was developed
on that platform. If I used ACL I suspect I would use AllegroCache. These
libraries stand out as being the most used and best supported CGI
interfaces.
The name Huncentoot comes from the spider Hunchentoot from Frank Zappa's
space opera with the same name. Drakma is a evil space queen from the same
opera (Weitz's http client). They reflect Edi Weitz's love of Zappa.
Beyond that they have no particular significance.
--------------
John Thingstad
P� Thu, 10 Jan 2008 19:23:52 +0100, skrev John Thingstad
<·······@online.no>:
> If I used ACL I suspect I would use AllegroCache.
erm.. AllegroServe of course.
--------------
John Thingstad
Ron Garret <·········@flownet.com> writes:
> Which one is better?
I use Hunchentoot for Weblocks and I find that it's excellent. Clean
API, good documentation, great working implementation, easy to
understand codebase (for rare occassions what you need to dive into it),
portability to almost every Lisp implementation and OS imaginable.
I haven't used AllegroServe because I tried Hunchentoot first, and in
about a year not once did I run into an itch that made me consider
trying out alternatives.
--
Regards,
Slava Akhmechet.
Ron Garret <·········@flownet.com> writes:
> Which one is better?
Well, I used AllegroServe for awhile, but am using Hunchentoot now, so I
suppose that means I think Hunchentoot is better. Really, I think its
patterns just match my patterns better; others may find that
AllegroServe fits _their_ minds better. No harm in that.
> (And what is the etymology of the name "Hutchentoot"?)
As noted elsewhere, it's from Frank Zappa.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Chris King: We're sysadmins. Sanity happens to other people.
Graham Reed: We're sysadmins. _We_ happen to other people. What's sanity?
I have ever read the following link. From the text, it seems
hutchentoot have some performance problem when working with SBCL, due
to the thread problem???
http://www.newartisans.com/blog_files/lisp.web.servers.php
Brian Jiang wrote:
> I have ever read the following link. From the text, it seems
> hutchentoot have some performance problem when working with SBCL, due
> to the thread problem???
> http://www.newartisans.com/blog_files/lisp.web.servers.php
See also
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/a2bf5d2bebc548d6
I do not know what to conclude from the blog.
What I have found in general is that it is hard to explain these kind of requirements on cll. I work
for a company where the software I work on does 10qps 24x7 and goes upto 25+ on peaks on a per box
basis and it is computation intensive (full text search engine with a large index in memory). I
can't really talk more about my work. Most people here do not understand (or seem not to) why
performance still matters. I guess it all depends on the field. But you can not demand stuff of a
free software either.
If there was a lucene port (some time ago there was some talk of it on cll), I could have made a
apples to apples comparison.
I am using Lisp only off work hours and still very much a newbie owing to the fact that I do not get
enough (contiguous) time to work on it.
So far what I have seen is hunchentoot seems to have a lot in terms of integrating support for
multipart parsing, dealing with char encoding, allowing flexible dispatch etc, but lacks on
stability and performance. That is, it is feature rich, but immature (just opinion). Part of the
blame may be on the Lisp standard, or the implementations .
Even within internet service industry, I see that performance requirements (or rather 'real time'
requirements) seem to be different. For example for a high volume search engine like the one I am
talking about, requiring more than around 400ms (worst case query) per request would need too much
hardware (everything is subjective depending on what pays the bills). But I have seen ITS (See posts
from Dan Wienreb - just quoting from memory) say their stuff can take upto 10 seconds for the
airline booking problem. There they have easier real time requirement but a far more complicated
(algorithmically) business logic. But even there performance still matters. Whereas Kenny's tutor
can take 15 seconds and can use the whole box for one user (or may be not). YMMV
-Antony
PS: personally I think ab is a bad way of testing, cause web server (for my field) performance is
about qps and not fixed concurrency (you'll need some time to understand what this means if you
don't already know)
On Sun, 13 Jan 2008 09:02:23 -0800, lisp linux <·········@lisp.linux> wrote:
> What I have found in general is that it is hard to explain these
> kind of requirements on cll. I work for a company where the software
> I work on does 10qps 24x7 and goes upto 25+ on peaks on a per box
> basis and it is computation intensive (full text search engine with
> a large index in memory). I can't really talk more about my
> work. Most people here do not understand (or seem not to) why
> performance still matters. I guess it all depends on the field. But
> you can not demand stuff of a free software either.
I think you are right and wrong at the same time. You are certainly
wrong if you somehow think that the inhabitants of c.l.l are too dumb
to understand such requirements or that it's impossible or "forbidden"
to talk about this here.
And you are right when you're saying that you can't run a million
dollar business and at the same bitch about the limitations of a piece
of free software that probably hasn't seen much more than two or three
man-weeks of development effort in its whole lifetime. (And, no, you
can't compare that with Apache, although both are free.)
If somebody has enough money to spend, one way is to go with AllegroCL
plus AllegroServe. I haven't really benchmarked it, but I'm sure it's
more than fast enough for almost everything. And if it isn't, Franz
will be happy to make it faster for you if you're one of their
customers. (Mind you, I'm talking about AllegroServe on AllegroCL,
not about Portable AllegroServe on some other Lisp.)
If you have the money and for some reason don't want to go the Franz
route, email me privately and I'll be happy to work with you on
improving Hunchentoot for your favorite Lisp implementation if you pay
my usual rates. Or if you don't like me, ask some other Lisp
consultant. The source code is available.
If you don't have the money but if you still want to use Lisp, try to
improve the situation yourself by submitting code to one of the open
source Lisp web servers to make them faster (assuming performance is
really what prevents you from getting things done).
If you don't have the money and if you don't have the time either, but
if you desperately need more performance for your no-money-no-time
project, use Apache and PHP. I'm sure you'll have lots of fun.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Sun, 13 Jan 2008 09:02:23 -0800, lisp linux <·········@lisp.linux> wrote:
>
>> What I have found in general is that it is hard to explain these
>> kind of requirements on cll. I work for a company where the software
>> I work on does 10qps 24x7 and goes upto 25+ on peaks on a per box
>> basis and it is computation intensive (full text search engine with
>> a large index in memory).
>
> I think you are right and wrong at the same time. You are certainly
> wrong if you somehow think that the inhabitants of c.l.l are too dumb
> to understand such requirements or that it's impossible or "forbidden"
> to talk about this here.
I would think that the folks at ITA software, for a relatively well
known example, are pretty familiar with performance requirements for
high volume, computationally intensive web-based services from software
using lisp.
On Jan 13, 3:56 pm, Brian Jiang <········@gmail.com> wrote:
> I have ever read the following link. From the text, it seems
> hutchentoot have some performance problem when working with SBCL, due
> to the thread problem???http://www.newartisans.com/blog_files/lisp.web.servers.php
From reading this link it seems that you understand how hard is to
benchmark anything well:
1st Why the hell you need lisp server for serving static content. Why
not using apache, IIS or even better lighttpd. Actually if you want
your static pages to kick ass on a mediocre hardware try YAWS on a
plain dual core it'll go over 150,000 connections without a problem.
2st Why testing hunch' with implementation that doesn't officially
support threads on OsX? If you want SBCL use linux X86, on Windows
choose LW or Allegro. On OsX choose whatever works for it, I don't own
Mac box so I don't know.
3rd What kind of static page is testing tomcat for? He says that he
was "using the dynamically generated default page for Hunchentoot." If
that's unrealistic scenarion I don't know what the hell is. If there's
only one page it might be kept in the cache and returned from it
instead of really generated. He should make some application that
generates the page according to some input, to make share that caching
mechanism won't take any shortcuts.
Benchmark are really hard to get even close to right. Many times
something that's obvious turns up to eat all the performance .
cheers
Slobodan
P.S.
take a look at the comments, easpecially the one from quasi:
All tests on a MBP with 2.33 core2duo running OSX 10.4.11
All I did was
(asdf:oos 'adsf:load-op 'hunchentoot)
(hunchentoot:start-server :port 4242)
CL:
Hunchentoot 0.14.0 on
ACL 8.0 [Mac OS X (Intel)] (Mar 12, 2007 17:50)
ab -n 1000 http://127.0.0.1:4242/
Requests per second: 431.97 [#/sec] (mean)
ab -c 10 -n 1000 http://127.0.0.1:4242/
Requests per second: 471.48 [#/sec] (mean)
ab -c 100 -n 1000 http://127.0.0.1:4242/
Requests per second: 445.04 [#/sec] (mean)
Apache test:
Server version: Apache/1.3.33 (Darwin)
Server built: Aug 19 2006 07:55:18
ab -c 1 -n 1000 http://127.0.0.1/
Requests per second: 458.72 [#/sec] (mean)
ab -c 10 -n 1000 http://127.0.0.1/
Requests per second: 748.50 [#/sec] (mean)
ab -c 100 -n 1000 http://127.0.0.1/
Requests per second: 677.97 [#/sec] (mean)
Apache is faster for serving static files (lighttpd is faster but when
you want to render dynamic pages, CL with internal webserver is not at
all bad. I have achieved up to 80% speed of apache with SSI vs. lisp
page using CMUCL and earlier TBNL. Difference reduces further with
more complicated pages. Current Hunchentoot is slower, but a
significant speed increase can be achieved if you avoid flexi-streams
(which is very slow).
We have had up time of upto 60 days with TBNL+CMUCL in production
easily.
quasi | Homepage | 12.03.07 - 4:46 am | #
On Sun, 13 Jan 2008 06:56:26 -0800 (PST), Brian Jiang <········@gmail.com> wrote:
> I have ever read the following link. From the text, it seems
> hutchentoot have some performance problem when working with SBCL,
> due to the thread problem???
>
> http://www.newartisans.com/blog_files/lisp.web.servers.php
It should be noted that the guy who posted that used SBCL on OS X
where "threading is not officially supported." I don't think this a
particularly fair comparison. But, hey, it's blogland...
What always amazes me is how people are concerned with performance
before they've even written a single line of code. For my take on
this see here:
http://weitz.de/hunchentoot/#performance
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Jan 13, 12:24 pm, Edi Weitz <········@agharta.de> wrote:
> It should be noted that the guy who posted that used SBCL on OS X
> where "threading is not officially supported." I don't think this a
> particularly fair comparison. But, hey, it's blogland...
>
> What always amazes me is how people are concerned with performance
> before they've even written a single line of code.
Being the guy who posted the blog, let me say that my results have
almost nothing to do with the reality others will experience. I
respect Edi's software and continue to use many of his packages, so my
intention in posting my results was not to discredit Hunchentoot, but
rather to note down a few personal observations. Also, I did try
Hunchentoot with SBCL on Linux, and still had threading issues.
If people are expecting the accuracy and thoroughness of journal
articles: read journals. I'm not always as rigorous as I should be,
nor do I consider the issue from every angle. If I restricted myself
to only those terms, I would probably never write at all (and indeed,
this very worry has stilled my pen in the past).
Edi, if you think the observations were unwarranted, say the word and
I'll remove them from my site.
John
On Mon, 14 Jan 2008 11:42:53 -0800 (PST), ······@gmail.com wrote:
> Edi, if you think the observations were unwarranted, say the word
> and I'll remove them from my site.
No, that's fine. I didn't want to censor you. However, it would be
interesting to see a comparison with another SMP Lisp like OpenMCL,
and maybe also with an efficient implementation of "green threads"
like in CMUCL or LispWorks 4.x.
Having said that, I never personally experienced Hunchentoot dropping
requests. That's a bad thing and shouldn't happen. If that's
reproducable, I'd appreciate if you could report it to the Hunchentoot
mailing list so that we can try to fix it or at least try to find the
reason. That's probably more helpful in the long run than blogging
about it. (Or maybe I'm just old-fashioned.)
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Mon, 14 Jan 2008 20:57:18 +0100, Edi Weitz <········@agharta.de> wrote:
> Having said that, I never personally experienced Hunchentoot
> dropping requests.
I should probably add the following technical details: Hunchentoot was
originally written only for LispWorks. In its first, unreleased, form
it used pools of pre-allocated worker threads like many other web
servers do. I tested this and came to the conclusion that it made the
code more complicated but otherwise didn't buy me anything - a typical
case of pre-mature optimization.
It might well be the case that now that Hunchentoot has changed quite
a bit and supports several other Lisps it is time to revisit this
decision. But I'll probably wait for others to investigate this as
Hunchentoot does its job for me.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Ron Garret <·········@flownet.com> writes:
> Which one is better? (And what is the etymology of the name
> "Hutchentoot"?)
The big advantage with Allegroserve is Webactions. I've been using
Portable Allegroserve with Webactions and CLSQL for some time and I'm
pretty happy with it.
As for Hunchentoot I've mostly been playing some of the tutorials, but
I haven't done any serious tests yet. As far as I can see it does not
have anything like the Common Lisp server Pages (CLP) found in
Webactions (correct me if I'm wrong). Some people prefer writing all
the HTML as Lisp, others prefer CLP style.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Sun, 13 Jan 2008 22:11:00 +0100, Petter Gustad <·············@gustad.com> wrote:
> As for Hunchentoot I've mostly been playing some of the tutorials,
> but I haven't done any serious tests yet. As far as I can see it
> does not have anything like the Common Lisp server Pages (CLP) found
> in Webactions (correct me if I'm wrong). Some people prefer writing
> all the HTML as Lisp, others prefer CLP style.
Hunchentoot is mainly a web server and like, say, Apache it doesn't
come with facilities to generate HTML out of the box. There are
plenty of ways to programmatically generate HTML from Lisp, though,
and most of them you can probably easily combine with Hunchentoot (or
any other Lisp web server). See for example here:
http://www.cl-user.net/asp/tags/11029
http://www.cliki.net/web
For libraries similar to CLP that definitely work with Hunchentoot,
you might want to look at:
http://common-lisp.net/project/cl-emb/
http://weitz.de/html-template/
(Apologies to those I've forgotten to mention.)
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> For libraries similar to CLP that definitely work with Hunchentoot,
> you might want to look at:
>
> http://common-lisp.net/project/cl-emb/
> http://weitz.de/html-template/
I've seen some of the various HTML generating libraries, but not the
above CLP-style projects. I'll look into it. Thanks!
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
On Jan 14, 8:00 am, Petter Gustad <·············@gustad.com> wrote:
> Edi Weitz <········@agharta.de> writes:
> > For libraries similar to CLP that definitely work with Hunchentoot,
> > you might want to look at:
>
> > http://common-lisp.net/project/cl-emb/
> > http://weitz.de/html-template/
>
> I've seen some of the various HTML generating libraries, but not the
> above CLP-style projects. I'll look into it. Thanks!
>
> Petter
Have a look at weblocks, it's a widget based ajax framework built on
top of hunch' http://common-lisp.net/project/cl-weblocks/ it comes
with some prefabricated widgets like , navigation, dataform ,
datagrid, pagination etc + some produced in the community. You can
create new widgets withany of the technologies mentioned above or
using cl-who or veen hand-written html.
Currently the authro is finishing the new DSL for easy UI
modification, that would allow easy customizing of how the widget is
rendered. For a demo with soem of basic capabilities take a look at
http://72.249.76.121/ for a idea behind it check
http://www.defmacro.org/ramblings/continuations-web.html
cheers
Slobodan
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
On 10080 day of my life Ron Garret wrote:
> Which one is better? (And what is the etymology of the name
> "Hutchentoot"?)
(Portable) Allegroserve has i18n problems. If your users will input
anything out of Latin1 range, you have to use Hutchentoot.
--
Ivan Boldyrev
Today is the first day of the rest of your life.