scalable web apps

scalable web apps

[Joel Reymont]

How do you build scalable web apps with OCaml?

Do you use Apache with mod_caml? Naked Ocsigen?

Do you put Ocsigen behind Nginx?

	Thanks in advance, Joel

---
http://twitter.com/wagerlabs

Re: scalable web apps

[Sylvain Le Gall]

On 24-07-2010, Joel Reymont <joelr1@gmail.com> wrote:
> How do you build scalable web apps with OCaml?
>
> Do you use Apache with mod_caml? Naked Ocsigen?
>
> Do you put Ocsigen behind Nginx?
>

I think that using ocsigen should be enough. There was a nice
presentation by Dario Texeira at the last OCaml Meeting:
https://forge.ocamlcore.org/docman/view.php/77/106/ocaml-web-startup.pdf
(he talks about dispatcher from page 5 to 10, a way to use all the 
processing power of a server)

Unfortunately, he said more things than what is written. The video of
his talk is on my computer -- I will publish it when I have time.

Regards,
Sylvain Le Gall

Re: [Caml-list] scalable web apps

[William Le Ferrand]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

Hi,

Personally I wrote www.corefarm.com using ocsigen and I deployed it
(actually, the backend gatewayX.corefarm.com, not the frontend) in amazon
ec2, behind the elastic load balancer (
http://aws.amazon.com/elasticloadbalancing/). So when traffic increases (and
when the servers start to lag), new instances are automatically brought to
life.

For www.corefarm.org I wrote a custom loadbalancer but I never used it; I
had at most 300 requests every 10 seconds. (not from visitors, from the
CPU-sharing application) and the server was never overloaded.

All the best,

william



2010/7/24 Joel Reymont <joelr1@gmail.com>

> How do you build scalable web apps with OCaml?
>
> Do you use Apache with mod_caml? Naked Ocsigen?
>
> Do you put Ocsigen behind Nginx?
>
>        Thanks in advance, Joel
>
> ---
> http://twitter.com/wagerlabs
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
William Le Ferrand

Speed matters : http://www.corefarm.com
Objects get social : http://www.sotokolan.com

Mobile : +33 6 84 01 52 92
LinkedIn : http://www.linkedin.com/in/williamleferrand

[-- Attachment #2: Type: text/html, Size: 2386 bytes --]

Re: [Caml-list] scalable web apps

[Dario Teixeira]

Hi,

> How do you build scalable web apps with OCaml?
> Do you use Apache with mod_caml? Naked Ocsigen?
> Do you put Ocsigen behind Nginx?

Your question is quite open-ended.  There are several "scalability crisis"
that an web app is expected to confront as it grows from handling at most
a handfull of requests per second to dealing with tens or even hundreds of
thousands of requests per second.  Are we talking about surviving a "mere"
Slashdot effect (not as scary nowadays as it once was), or about competing
with Facebook?

Naked Ocsigen -- particularly naked native-code Ocsigen -- should serve
you a long way in the initial stage of the growth path.  In fact, I suspect
you'll run into scalability problems with the database backend much sooner
than you'll find them on the Ocsigen side.  (For caching DB requests, I
reckon that Ocsigen's Ocsigen_cache module should be sufficient for this
early stage, single Ocsigen server situations).

The only circumstance where I would be cautious on relying solely on a
naked Ocsigen is if you are also required to serve plenty of static content
(images, etc).  Even though Ocsigen includes an extension for serving static
pages, for hysterical reasons no Unix supports non-blocking mode for regular
files, which of course causes problems for Lwt-apps (see the Lwt manual for
more information on this).  Therefore, in this context you may get better
results by having another server (like Nginx) dedicated to static content.

As Sylvain mentioned, in my talk I discussed that Ocaml's single-coredness is 
in no way an obstacle to scaling an web app beyond a single Ocsigen server.
However, at this stage of growth you'll also have to consider using a
distributed caching mechanism, such as Memcached or Wink's Cache [1] (the
later developed in Ocaml by Gerd Stolpmann et al).

Best regards,
Dario Teixeira

[1] http://oss.wink.com/cache/

Re: [Caml-list] scalable web apps

[Joel Reymont]

On Jul 25, 2010, at 2:52 PM, Dario Teixeira wrote:

> Are we talking about surviving a "mere"
> Slashdot effect (not as scary nowadays as it once was),

This as I'm looking to provide paid conversion of trading strategies from one trading language to another. 

See an example conversion of TradeStation Easylanguage C# here:

http://groups.google.com/group/topdog/browse_thread/thread/d5fd8feac8e68331

Note that converted code goes first, followed by original code.

I'm going with naked Ocsigen and Amazon SimpleDB and will tweet (blog?) about the process.

	Thanks, Joel

---
http://twitter.com/wagerlabs

Re: [Caml-list] scalable web apps

[Török Edwin]

On Sun, 25 Jul 2010 06:52:46 -0700 (PDT)
Dario Teixeira <darioteixeira@yahoo.com> wrote:

> The only circumstance where I would be cautious on relying solely on a
> naked Ocsigen is if you are also required to serve plenty of static
> content (images, etc).  Even though Ocsigen includes an extension for
> serving static pages, for hysterical reasons no Unix supports
> non-blocking mode for regular files, which of course causes problems
> for Lwt-apps (see the Lwt manual for more information on this).

I thought ocaml's "threads" are meant to solve the I/O problem.
Doesn't it use native pthreads for each OCaml thread, and prior to
performing I/O it releases the mutex allowing other threads to run?
Of course you'd still have to wait for the I/O to complete to serve the
file to one particular user, but in the meantime you could serve some
other (already cached) file to another user, generate some dynamic
content, etc.

Lwt's Lwt_preemptive seems to allow one to use 'preemptive
threads' (which I assume are just usual OCaml threads).
So would it be possible to put the file I/O on Lwt_preemptive.detach
threads? Has anyone tried to measure the performance of doing that?

Best regards,
--Edwin

Re: [Caml-list] scalable web apps

[Jérémie Dimino]

On Mon, Jul 26, 2010 at 10:29:04AM +0300, Török Edwin wrote:
> Lwt's Lwt_preemptive seems to allow one to use 'preemptive
> threads' (which I assume are just usual OCaml threads).
> So would it be possible to put the file I/O on Lwt_preemptive.detach
> threads?

Yes.

> Has anyone tried to measure the performance of doing that?

Yes, i tried it some time ago with two small C programs which were just
reading a file on the disk. One doing read operations in a simple loop,
and one launching a thread for each read operation (or reusing the same
thread). The threaded version was about 100 times slower than the
non-threaded one.

BTW it is planed to add some kind of asynchronous file I/O support in
Lwt by using mmap and mincore.

Best,

-- 
Jérémie

Re: [Caml-list] scalable web apps

[Török Edwin]

On Mon, 26 Jul 2010 09:59:01 +0200
Jérémie Dimino <jeremie@dimino.org> wrote:

> On Mon, Jul 26, 2010 at 10:29:04AM +0300, Török Edwin wrote:
> > Lwt's Lwt_preemptive seems to allow one to use 'preemptive
> > threads' (which I assume are just usual OCaml threads).
> > So would it be possible to put the file I/O on Lwt_preemptive.detach
> > threads?
> 
> Yes.
> 
> > Has anyone tried to measure the performance of doing that?
> 
> Yes, i tried it some time ago with two small C programs which were
> just reading a file on the disk. One doing read operations in a
> simple loop, and one launching a thread for each read operation (or
> reusing the same thread). The threaded version was about 100 times
> slower than the non-threaded one.
> 
> BTW it is planed to add some kind of asynchronous file I/O support in
> Lwt by using mmap and mincore.

How about using linux's AIO and eventfd?

Manpage of eventfd says:
"When used in the kernel, an eventfd file descriptor can provide a
kernel-userspace bridge  allowing,  for  example, functionalities like
KAIO (kernel AIO) to signal to a file descriptor that some operation is
complete.

A  key point about an eventfd file descriptor is that it can be
monitored just like any other file descriptor using select(2),
poll(2), or epoll(7).  This means that an application can
simultaneously monitor the readiness of  "tra‐ ditional"  files
and  the  readiness  of other kernel mechanisms that support the
eventfd interface."

And looks like libaio-ocaml has support for eventfd in AIO:
val fd : context -> Unix.file_descr
  (** return eventfd associated with the context *)

I think there could be a Lwt_unix.read_aio that is just
like Lwt_unix.read, except it checks the eventfd descriptor for being
readable instead of the original fd, and use Aio.read instead of usual
read, etc.

Best regards,
--Edwin

Re: [Caml-list] scalable web apps

[Jérémie Dimino]

On Mon, Jul 26, 2010 at 11:19:20AM +0300, Török Edwin wrote:
> How about using linux's AIO and eventfd?

Linux's AIO are Linux specific and not implemented on all file-systems,
so i am not sure it is the best way to go.

Best,

-- 
Jérémie

Re: [Caml-list] scalable web apps

[Dario Teixeira]

Hi,

> BTW it is planed to add some kind of asynchronous file I/O support in
> Lwt by using mmap and mincore.

Excellent!  When that arrives I suspect a naked Ocsigen server will also
be able to handle a large load of static-file requests, thus eliminating
the need for Nginx & Co.

Cheers,
Dario Teixeira

Re: [Caml-list] scalable web apps

[Jake Donham]

On Mon, Jul 26, 2010 at 12:59 AM, Jérémie Dimino <jeremie@dimino.org> wrote:
> Yes, i tried it some time ago with two small C programs which were just
> reading a file on the disk. One doing read operations in a simple loop,
> and one launching a thread for each read operation (or reusing the same
> thread). The threaded version was about 100 times slower than the
> non-threaded one.

This is perhaps off-topic for the list, but what is the reason for
this? I can imagine that launching a thread might be heavy, but is the
context-switch overhead for threads so bad?

> BTW it is planed to add some kind of asynchronous file I/O support in
> Lwt by using mmap and mincore.

How would this work? Is it possible to be notified when the page comes
into core (mincore appears to support only polling)? Is it possible to
request a page without blocking (by reading from it)? Just curious.

Jake

Re: [Caml-list] scalable web apps

[Török Edwin]

On Mon, 26 Jul 2010 12:57:55 -0700
Jake Donham <jake@donham.org> wrote:

> On Mon, Jul 26, 2010 at 12:59 AM, Jérémie Dimino <jeremie@dimino.org>
> wrote:
> > Yes, i tried it some time ago with two small C programs which were
> > just reading a file on the disk. One doing read operations in a
> > simple loop, and one launching a thread for each read operation (or
> > reusing the same thread). The threaded version was about 100 times
> > slower than the non-threaded one.
> 
> This is perhaps off-topic for the list, but what is the reason for
> this? I can imagine that launching a thread might be heavy, but is the
> context-switch overhead for threads so bad?
> 
> > BTW it is planed to add some kind of asynchronous file I/O support
> > in Lwt by using mmap and mincore.
> 
> How would this work? Is it possible to be notified when the page comes
> into core (mincore appears to support only polling)?

With AIO I think so, without it I don't know how.

> Is it possible to
> request a page without blocking (by reading from it)? Just curious.
> 
> Jake

Re: [Caml-list] scalable web apps

[Jérémie Dimino]

On Mon, Jul 26, 2010 at 12:57:55PM -0700, Jake Donham wrote:
> > BTW it is planed to add some kind of asynchronous file I/O support in
> > Lwt by using mmap and mincore.
> 
> How would this work? Is it possible to be notified when the page comes
> into core (mincore appears to support only polling)? Is it possible to
> request a page without blocking (by reading from it)? Just curious.

In case a page is not cached, the time required to launch a thread is
negligible compared to the time needed to retrieve the page from the
disk, so we can for example launch a thread which will try to access the
first byte of the mmaped page.

Best,

-- 
Jérémie

Re: scalable web apps

[Sylvain Le Gall]

Hello,

On 25-07-2010, Dario Teixeira <darioteixeira@yahoo.com> wrote:
>
> The only circumstance where I would be cautious on relying solely on a
> naked Ocsigen is if you are also required to serve plenty of static content
> (images, etc).  Even though Ocsigen includes an extension for serving static
> pages, for hysterical reasons no Unix supports non-blocking mode for regular
> files, which of course causes problems for Lwt-apps (see the Lwt manual for
> more information on this).  Therefore, in this context you may get better
> results by having another server (like Nginx) dedicated to static content.
>

I am creating an application with ocsigen that requires to serve a lot
of .tar.gz as static contents. 

Do you think the "no Unix supports non-blocking mode" will cause problem
in this case?

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: scalable web apps

[Dario Teixeira]

Hi,

> I am creating an application with ocsigen that requires to serve a lot
> of .tar.gz as static contents. 
> 
> Do you think the "no Unix supports non-blocking mode" will cause problem
> in this case?

I presume that application is related to the Oasis-DB initiative, right?
I wouldn't worry too much in that case.  First, because the Ocaml community
is not that big (yet) as to cause such heavy traffic.  Second, because
the set of tar.gz files is not that great (a few hundred, max?) and those
files will tend to be small.  If your server has enough memory, there's a
good chance many of the file blocks requested will eventually be buffered
in memory by the kernel, thus minimising expensive disc I/O.

Cheers,
Dario Teixeira

Re: scalable web apps

[Sylvain Le Gall]

On 26-07-2010, Dario Teixeira <darioteixeira@yahoo.com> wrote:
> Hi,
>
>> I am creating an application with ocsigen that requires to serve a lot
>> of .tar.gz as static contents. 
>> 
>> Do you think the "no Unix supports non-blocking mode" will cause problem
>> in this case?
>
> I presume that application is related to the Oasis-DB initiative, right?

You guess right ;-)

> I wouldn't worry too much in that case.  First, because the Ocaml community
> is not that big (yet) as to cause such heavy traffic.  Second, because
> the set of tar.gz files is not that great (a few hundred, max?) and those
> files will tend to be small.  If your server has enough memory, there's a
> good chance many of the file blocks requested will eventually be buffered
> in memory by the kernel, thus minimising expensive disc I/O.
>

There is indeed a good chance that the files end up in memory.

Thank you for your remarks.

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: scalable web apps

[William Le Ferrand]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

Why would you use ocsigen to serve static files?

For corefarm.com we put all the files in amazon s3 and we just generate on
the fly the url to retrieve them (adding the timestamp, signing the get
parameters etc).

My 2 cents,

william

2010/7/26 Sylvain Le Gall <sylvain@le-gall.net>

> On 26-07-2010, Dario Teixeira <darioteixeira@yahoo.com> wrote:
> > Hi,
> >
> >> I am creating an application with ocsigen that requires to serve a lot
> >> of .tar.gz as static contents.
> >>
> >> Do you think the "no Unix supports non-blocking mode" will cause problem
> >> in this case?
> >
> > I presume that application is related to the Oasis-DB initiative, right?
>
> You guess right ;-)
>
> > I wouldn't worry too much in that case.  First, because the Ocaml
> community
> > is not that big (yet) as to cause such heavy traffic.  Second, because
> > the set of tar.gz files is not that great (a few hundred, max?) and those
> > files will tend to be small.  If your server has enough memory, there's a
> > good chance many of the file blocks requested will eventually be buffered
> > in memory by the kernel, thus minimising expensive disc I/O.
> >
>
> There is indeed a good chance that the files end up in memory.
>
> Thank you for your remarks.
>
> Regards,
> Sylvain Le Gall
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>



-- 
William Le Ferrand

Speed matters : http://www.corefarm.com
Objects get social : http://www.sotokolan.com

Mobile : +33 6 84 01 52 92
LinkedIn : http://www.linkedin.com/in/williamleferrand

[-- Attachment #2: Type: text/html, Size: 2910 bytes --]

Re: [Caml-list] scalable web apps

[Richard Jones]

On Sat, Jul 24, 2010 at 08:49:26AM +0100, Joel Reymont wrote:
> How do you build scalable web apps with OCaml?

I would ask that question again, but miss out the "with OCaml" part,
because really the choice of language doesn't matter very much.

Or if you prefer think of it this way: People are using really
unsuitable languages (PHP) and really slow languages (Ruby, PHP,
Python, Perl) on some massive websites out there.

So look for books about the general subject: minimizing calls to the
database, scaling with Apache and memcached, the right layered
architecture to use, what to cache, optimizing HTML.

Here are a couple I like:

http://www.amazon.com/Building-Scalable-Web-Sites-Applications/dp/0596102356
http://www.amazon.com/Speed-Up-Your-Site-Optimization/dp/toc/0735713243

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] scalable web apps

[Dario Teixeira]

Hi,

> I would ask that question again, but miss out the "with OCaml" part,
> because really the choice of language doesn't matter very much.

Indeed.  Note, however, that more than once have people raised the issue
of Ocaml's non-concurrent GC on Ocsigen's mailing-list.  The doubt is
always whether this makes any Ocaml-based framework unsuitable for
scalable web applications.  I think it's important to assuage those fears
once and for all: in no meaningful way does Ocaml's single-coredness
constitute an impediment towards scalability in the web domain.


> Or if you prefer think of it this way: People are using really
> unsuitable languages (PHP) and really slow languages (Ruby, PHP,
> Python, Perl) on some massive websites out there.

Yeap.  Personally, I find Ocsigen's greatest advantage to be the safety
and expressiveness that it brings to backend programming (and soon also
to the frontend).  The fact that it's also fast is just icing on the cake...

Cheers,
Dario Teixeira



   

Re: [Caml-list] scalable web apps

[Joel Reymont]

How does Ocsigen handle database operations?

I assume they need to be asynchronous because of lightweight threads (Lwt).

Please feel free to point me to the manual but I think an answer in this thread would benefit future Google searches.

---
http://twitter.com/wagerlabs

Re: [Caml-list] scalable web apps

[Gabriel Kerneis]

On Sun, Jul 25, 2010 at 10:56:22PM +0100, Joel Reymont wrote:
> I assume they need to be asynchronous because of lightweight threads
> (Lwt).
> Please feel free to point me to the manual but I think an answer in
> this thread would benefit future Google searches.

http://ocsigen.org/lwt/doc/api/Lwt_preemptive.html#VALdetach

Regards,
-- 
Gabriel

Re: [Caml-list] scalable web apps

[Dario Teixeira]

Hi,

> How does Ocsigen handle database operations?
> I assume they need to be asynchronous because of
> lightweight threads (Lwt).

Ocsigen itself is agnostic on DB matters.  However, your assumption
concerning the Lwt-friendliness of the DB layer is correct.  There's
basically two solutions to this problem: 1) Use whatever DB bindings
you prefer, but wrap them under Lwt_preemptive; 2) Use Lwt-aware DB
bindings.  For the latter the usual recommendation is PG'OCaml [1],
which in its current incarnation can be used in a monadic fashion
(with Lwt, for example).  If you want to interact with the DB at
an even higher level there's also Macaque [2], which is part of
the Ocsigen project (note that Macaque relies on PG'OCaml for the
low-level work).

When using PG'OCaml with Lwt, pretty soon you'll come across the
problem of connection pooling.  This is the moment you'll want to
look into Lwt_pool, which makes this task a breeze.

Finally, if you're looking for a concrete example of all this stuff
put together I suggest taking a look at the Lambdium's database.ml
module [3] (you can find it under 'backend/src/data/').

Hope that's enough to get you going...
Cheers,
Dario Teixeira

[1] http://pgocaml.berlios.de/
[2] http://ocsigen.org/macaque/
[3] https://forge.ocamlcore.org/projects/lambdium/

Re: [Caml-list] scalable web apps

[Richard Jones]

On Sun, Jul 25, 2010 at 10:56:22PM +0100, Joel Reymont wrote:
> How does Ocsigen handle database operations?

I thought it was using PG'OCaml, but maybe I'm wrong.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] scalable web apps

[Dario Teixeira]

Hi,

> > How does Ocsigen handle database operations?
> 
> I thought it was using PG'OCaml, but maybe I'm wrong.

Ocsigen itself does not use PG'OCaml.  The two are frequently associated
because the latest versions of PG'OCaml are Lwt-friendly and therefore
a good choice for Ocsigen apps.  (Note that internally, Ocsigen uses
either Dbm or Sqlite to store session data).

Cheers,
Dario Teixeira

Re: [Caml-list] scalable web apps

[Florent Monnier]

Le lundi 26 juillet 2010 13:20:46, Dario Teixeira a écrit :
> Hi,
> 
> > > How does Ocsigen handle database operations?
> >
> > I thought it was using PG'OCaml, but maybe I'm wrong.
> 
> Ocsigen itself does not use PG'OCaml.  The two are frequently associated
> because the latest versions of PG'OCaml are Lwt-friendly and therefore
> a good choice for Ocsigen apps.  (Note that internally, Ocsigen uses
> either Dbm or Sqlite to store session data).

Both Dbm and Sqlite lock the entire files which blocks concurrent uses,
isn't it a problem?

-- 

Re: scalable web apps

[Sylvain Le Gall]

On 26-07-2010, Florent Monnier <monnier.florent@gmail.com> wrote:
> Le lundi 26 juillet 2010 13:20:46, Dario Teixeira a écrit :
>> Hi,
>> 
>> > > How does Ocsigen handle database operations?
>> >
>> > I thought it was using PG'OCaml, but maybe I'm wrong.
>> 
>> Ocsigen itself does not use PG'OCaml.  The two are frequently associated
>> because the latest versions of PG'OCaml are Lwt-friendly and therefore
>> a good choice for Ocsigen apps.  (Note that internally, Ocsigen uses
>> either Dbm or Sqlite to store session data).
>
> Both Dbm and Sqlite lock the entire files which blocks concurrent uses,
> isn't it a problem?
>

For sqlite, at least, it uses Lwt_preemptive.detach and sqlite3 contains
the required caml_enter/leave_blocking_section(s). So Lwt should work
without problems with sqlite.

I suppose it is the same for dbm.

Regards,
Sylvain Le Gall

Re: [Caml-list] Re: scalable web apps

[Gabriel Kerneis]

On Mon, Jul 26, 2010 at 05:10:01PM +0000, Sylvain Le Gall wrote:
> > Both Dbm and Sqlite lock the entire files which blocks concurrent uses,
> > isn't it a problem?
> 
> For sqlite, at least, it uses Lwt_preemptive.detach and sqlite3 contains
> the required caml_enter/leave_blocking_section(s). So Lwt should work
> without problems with sqlite.
> 
> I suppose it is the same for dbm.

No.  For dbm there is a separate daemon (ocsidbm) opening the file once
and serializing requests sent from and back to Ocsigen through a pipe.

Regards,
-- 
Gabriel

Re: scalable web apps

[Sylvain Le Gall]

On 26-07-2010, Gabriel Kerneis <kerneis@pps.jussieu.fr> wrote:
> On Mon, Jul 26, 2010 at 05:10:01PM +0000, Sylvain Le Gall wrote:
>> > Both Dbm and Sqlite lock the entire files which blocks concurrent uses,
>> > isn't it a problem?
>> 
>> For sqlite, at least, it uses Lwt_preemptive.detach and sqlite3 contains
>> the required caml_enter/leave_blocking_section(s). So Lwt should work
>> without problems with sqlite.
>> 
>> I suppose it is the same for dbm.
>
> No.  For dbm there is a separate daemon (ocsidbm) opening the file once
> and serializing requests sent from and back to Ocsigen through a pipe.
>

Thanks for this clarification. So basically, it also works with Lwt but
using a little bit heavier backend (i.e. launching a process rather than
launching a thread).

Regards,
Sylvain Le Gall

Re: [Caml-list] scalable web apps

[Yoann Padioleau]

On Jul 25, 2010, at 2:45 PM, Dario Teixeira wrote:

> 
> Hi,
> 
>> I would ask that question again, but miss out the "with OCaml" part,
>> because really the choice of language doesn't matter very much.
> 
> Indeed.  Note, however, that more than once have people raised the issue
> of Ocaml's non-concurrent GC on Ocsigen's mailing-list.  The doubt is
> always whether this makes any Ocaml-based framework unsuitable for
> scalable web applications.  I think it's important to assuage those fears
> once and for all: in no meaningful way does Ocaml's single-coredness
> constitute an impediment towards scalability in the web domain.

Yep. Facebook is written in PHP which does not even have threads ...

> 
> 
>> Or if you prefer think of it this way: People are using really
>> unsuitable languages (PHP) and really slow languages (Ruby, PHP,
>> Python, Perl) on some massive websites out there.
> 
> Yeap.  Personally, I find Ocsigen's greatest advantage to be the safety
> and expressiveness that it brings to backend programming (and soon also
> to the frontend).  The fact that it's also fast is just icing on the cake...

My biggest issue with OCsigen is the lack of documentation and examples.
With rails you got lots of books, and you got example of non trivial websites
like a mini amazon (called depot: http://pragprog.com/titles/rails2/source_code)
in less than 2000 lines of code.





> 
> Cheers,
> Dario Teixeira
> 
> 
> 
> 
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 

Re: scalable web apps

[Sylvain Le Gall]

Hello,

On 25-07-2010, Yoann Padioleau <padator@wanadoo.fr> wrote:
> On Jul 25, 2010, at 2:45 PM, Dario Teixeira wrote:
>> 
>> 
>>> Or if you prefer think of it this way: People are using really
>>> unsuitable languages (PHP) and really slow languages (Ruby, PHP,
>>> Python, Perl) on some massive websites out there.
>> 
>> Yeap.  Personally, I find Ocsigen's greatest advantage to be the safety
>> and expressiveness that it brings to backend programming (and soon also
>> to the frontend).  The fact that it's also fast is just icing on the cake...
>
> My biggest issue with OCsigen is the lack of documentation and examples.
> With rails you got lots of books, and you got example of non trivial websites
> like a mini amazon (called depot: http://pragprog.com/titles/rails2/source_code)
> in less than 2000 lines of code.
>

There are examples of ocsigen websites:
http://ocsigen.org/ocsimore/sources/
https://forge.ocamlcore.org/scm/viewvc.php/?root=ocsforge
http://ocsigen.org/ocsigenserver/sources/examples

You could even found some of them outside ocsigen websites:
https://forge.ocamlcore.org/scm/viewvc.php/?root=lambdoc
http://github.com/mfp/ocsiblog

But, I think the documentation issue is a chicken and egg problem. If
more people are interested in ocsigen, the documentation will improve...

I am experimenting with ocsigen since one month and I think it is a good
framework. It provides a good type checking of HTML struct, errors
outputted are not very clear, but you know where the problem is.

Regards,
Sylvain Le Gall