Lift 2.0, Scala 2.8, and AppEngine

[melling]

I want to jump in and do a Scala/Lift project on the Google
AppEngine. Since I'm still pretty much a beginner in all 3
technologies, I figure it's best to start with Scala 2.8/Lift 2 since
they're almost production ready. Can someone point me to a couple of
recent blogs to get me started? I'm not sure what changes occurred in
the latest Scala/Lift versions so I'm not sure if older blog posts are
still completely accurate.

-Mike

[Kevin Wright]

I can't speak on behalf of behalf of the current Lift 2 status, the extent of my contributions to the project was suggesting tail merge (hint: it wasn't recent)

Scala 2.8 though, and app deployments, I am a bit more familiar with everything that's going on there :)

So... I'd *definitely* recommend stax.net over GAE

a) It offers a Maven-based test/build/deploy solution.

b) It can handle threads and actors.

c) It's based on EC2, and can scale up nicely if your site suddenly gets all popular and profitable.

d) Stax.net use some Scala internally, so you'll find them very helpful and friendly if you encounter any issues.

I can also confirm that I'm not running into any issues with the Lift 2.0 snapshot against Scala 2.8.0.RC6.

And you're going to want 2.8 if you're after Squeryl or the massively improved collections library, or simply to work with a recent version of the eclipse plugin.

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Kevin Wright

mail/google talk: kev.lee...@gmail.com
wave: kev.lee...@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

[Michael Mellinger]

We already use GAE and I don't think we can change at this point, but
we'll consider it at a later stage. I found this and got my
HelloWorld Lift program running under Jetty.

http://github.com/dpp/lift_sbt_prototype

There must be some sort of template for Google's AppEngine. Now I'm
reading through StartingWithLift.pdf.

You know how it is when learning something new. Just gotta connect a
lot of dots. Unfortunately, the dots are versioned and I'm probably
gonna get burned mixing and matching Scala 2.8/Lift 2.0 and Scala
2.7/Lift 1.0.

-Mike

[Justin S.]

FYI, I put together a pom.xml for the latest Lift 2.0, Scala 2.8, and
Specs testing over here:

http://xclu.wordpress.com/2010/06/25/lift-2-0-scala-2-8-maven-in-eclipse/

[Timothy Perrett]

Mike,

By running Lift on GAE you loose nearly all the awesome USPs that lift provides. If you just want a framework to do templating and some other stuff, then sure, lift on GAE will be fine... if you want to use actors or anything that using any kind of threading your going to be a little screwed with GAE.

Thats not to say you cant make cool apps with Lift on GAE, its just likely you are going to have to jump through a lot of hoops to make it happen.

Cheers, Tim

[Michael Mellinger]

I don't really know maven either. I did get a HelloWorld app
deployed to AppEngine by following these instructions:

http://jpkutner.blogspot.com/2009/08/scala-and-lift-on-google-app-engine.html

Do I simply replace the pom.xml in my project directory with yours?
Maven does all the right magic, right up until ...? :-)

-Mike

[David Pollak]

FWIW, I think you're going to be very disappointed with the Lift/GAE combination.  Because GAE doesn't support all of the JVM's features and applies random constraints (e.g, requests for a given session may be served by different JVMs without any notice to the running application), you'll probably find that your Lift apps misbehave in random ways.  If you've already settled of GAE, then I'd recommend another web framework such as Wicket or Play.

Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

[Michael Mellinger]

Yeah, GAE was decided first, and work has already started. I heard
you on FLOSS Weekly (http://twit.tv/floss125) and realized Scala 2.8
is here so it's probably a great time to toe-dip into Scala/Lift with
some sort of project.

The yet another Java framework state of Java is a bit annoying and a
hard sell on group projects. I was hoping Scala/Lift would snowball,
and end the pain.

-Mike

[David Pollak]

On Sun, Jun 27, 2010 at 8:13 PM, Michael Mellinger <mmelli...@gmail.com> wrote:

Yeah, GAE was decided first, and work has already started.

Bummer.  

 

 I heard
you on FLOSS Weekly (http://twit.tv/floss125) and realized Scala 2.8
is here so it's probably a great time to toe-dip into Scala/Lift with
some sort of project.

Maybe next time you have a project that's hosted anywhere except GAE you'll give Lift a try.

 

The yet another Java framework state of Java is a bit annoying and a
hard sell on group projects.  I was hoping Scala/Lift would snowball,
and end the pain.

Play is Java-based, but the Scala extension is very nice.

 

-Mike

On Sun, Jun 27, 2010 at 9:19 PM, David Pollak
<feeder.of...@gmail.com> wrote:
> FWIW, I think you're going to be very disappointed with the Lift/GAE
> combination.  Because GAE doesn't support all of the JVM's features and
> applies random constraints (e.g, requests for a given session may be served
> by different JVMs without any notice to the running application), you'll
> probably find that your Lift apps misbehave in random ways.  If you've
> already settled of GAE, then I'd recommend another web framework such as
> Wicket or Play.
>
> On Sun, Jun 27, 2010 at 1:37 PM, Michael Mellinger <mmelli...@gmail.com>
> wrote:
>>
>> We already use GAE and I don't think we can change at this point, but
>> we'll consider it at a later stage.  I found this and got my
>> HelloWorld Lift program running under Jetty.
>>
>> http://github.com/dpp/lift_sbt_prototype
>>
>> There must be some sort of template for Google's AppEngine.  Now I'm
>> reading through StartingWithLift.pdf.
>>
>> You know how it is when learning something new.  Just gotta connect a
>> lot of dots.  Unfortunately, the dots are versioned and I'm probably
>> gonna get burned mixing and matching Scala 2.8/Lift 2.0 and Scala
>> 2.7/Lift 1.0.
>>

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Arthur]

I remember a long while back that there was talk of implementing
actors on GAE by using a CRON job and by running them in the thread
that sent the message to the actor. Was this deemed impossible or bad
or was it just not done because of the small target audience and the
difficulty of implementation?

-Arthur

On Jun 27, 11:41 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> On Sun, Jun 27, 2010 at 8:13 PM, Michael Mellinger

> <mmellinge...@gmail.com>wrote:

>
> > Yeah, GAE was decided first, and work has already started.
>
> Bummer.
>
> >  I heard
> > you on FLOSS Weekly (http://twit.tv/floss125) and realized Scala 2.8
> > is here so it's probably a great time to toe-dip into Scala/Lift with
> > some sort of project.
>
> Maybe next time you have a project that's hosted anywhere except GAE you'll
> give Lift a try.
>
>
>
> > The yet another Java framework state of Java is a bit annoying and a
> > hard sell on group projects.  I was hoping Scala/Lift would snowball,
> > and end the pain.
>
> Play is Java-based, but the Scala extension is very nice.
>
>
>
>
>
> > -Mike
>
> > On Sun, Jun 27, 2010 at 9:19 PM, David Pollak
> > <feeder.of.the.be...@gmail.com> wrote:
> > > FWIW, I think you're going to be very disappointed with the Lift/GAE
> > > combination.  Because GAE doesn't support all of the JVM's features and
> > > applies random constraints (e.g, requests for a given session may be
> > served
> > > by different JVMs without any notice to the running application), you'll
> > > probably find that your Lift apps misbehave in random ways.  If you've
> > > already settled of GAE, then I'd recommend another web framework such as
> > > Wicket or Play.
>
> > > On Sun, Jun 27, 2010 at 1:37 PM, Michael Mellinger <

> > mmellinge...@gmail.com>

> > > wrote:
>
> > >> We already use GAE and I don't think we can change at this point, but
> > >> we'll consider it at a later stage.  I found this and got my
> > >> HelloWorld Lift program running under Jetty.
>
> > >>http://github.com/dpp/lift_sbt_prototype
>
> > >> There must be some sort of template for Google's AppEngine.  Now I'm
> > >> reading through StartingWithLift.pdf.
>
> > >> You know how it is when learning something new.  Just gotta connect a
> > >> lot of dots.  Unfortunately, the dots are versioned and I'm probably
> > >> gonna get burned mixing and matching Scala 2.8/Lift 2.0 and Scala
> > >> 2.7/Lift 1.0.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lif...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[David Pollak]

On Wed, Jun 30, 2010 at 7:07 PM, Arthur <arthur...@gmail.com> wrote:

I remember a long while back that there was talk of implementing
actors on GAE by using a CRON job and by running them in the thread
that sent the message to the actor. Was this deemed impossible or bad
or was it just not done because of the small target audience and the
difficulty of implementation?

Doing any work for GAE is a waste of time.  Why?

GAE is slow and non-scalable, despite Google's claims (everyone I've spoken with that have tried to scale GAE apps have failed and gone elsewhere).

GAE locks you into a tremendously suboptimal storage mechanism.

GAE is free, but so is Stax and there are many inexpensive options including SliceHost.  Next up, you've got Amazon EC2 and RackSpace.

So, I haven't found a good reason for anyone to use GAE.  And if there's no good reason to use GAE, devoting a pile of resources to code around the GAE JVM incompatibilities (e.g., no new threads) seems like a waste.
 

To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[Arthur Peters]

That makes a lot of sense. I was just curious.

What recommendations would people have for minimum RAM size for hosting lift in a VPS. I experimented at one point and found that it seemed to require quite a bit. But I may not have been doing it write. Are there any guides online for how to setup and optimize a VPS for lift? (or other servlets I guess they are probably the same)

-Arthur (sent from phone)

On Jun 30, 2010 10:52 PM, "David Pollak" <feeder.of...@gmail.com> wrote:

On Wed, Jun 30, 2010 at 7:07 PM, Arthur <arthur...@gmail.com> wrote:
>

> I remember a long while...

Doing any work for GAE is a waste of time.  Why?

GAE is slow and non-scalable, despite Google's claims (everyone I've spoken with that have tried to scale GAE apps have failed and gone elsewhere).

GAE locks you into a tremendously suboptimal storage mechanism.

GAE is free, but so is Stax and there are many inexpensive options including SliceHost.  Next up, you've got Amazon EC2 and RackSpace.

So, I haven't found a good reason for anyone to use GAE.  And if there's no good reason to use GAE, devoting a pile of resources to code around the GAE JVM incompatibilities (e.g., no new threads) seems like a waste.
 

>
>
> -Arthur
>
> On Jun 27, 11:41 pm, David Pollak <feeder.of.the.be...@gmail.com>
> wrote:

> > On...

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

--
You received th...

[David Pollak]

On Thu, Jul 1, 2010 at 11:57 PM, Arthur Peters <a...@singingwizard.org> wrote:

That makes a lot of sense. I was just curious.

What recommendations would people have for minimum RAM size for hosting lift in a VPS.

64MB min.  128MB (so the JVM has 64MB heap+32MB other) is reasonable for most apps that are going to have 10-20 users logged in at any time. 

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Fredrik Jonsson]

Interesting. I would appreciate if you had time to elaborate a bit on this.

Our site seemed to need 768MB to run Ubuntu 9.10 Server with
PostgreSQL 8.4 and Jetty with a small Lift app on. (swap is not
allowed on the VPS host).

Could we do a better setup?

-Fredrik

On Fri, Jul 2, 2010 at 3:32 PM, David Pollak

[Derek Chen-Becker]

How much of that memory was PostgreSQL using? What were your VM memory allocations for heap, perm space, etc? I ask because I've seen PostgreSQL chew up quite a bit of memory if it's configured to do so.

Derek

[Arthur Peters]

I would also love to see the options, container and configuration used
to get lift to run in 128MB. I have attempted it and I had trouble
when I was running it in even 300MB let alone 128MB. I'm sure I was
doing something wrong, but I don't know what.

-Arthur

[Fredrik Jonsson]

These are the top stats from our VPS:

Mem: 1048576k total, 663416k used, 385160k free, 0k buffers
Swap: 0k total, 0k used, 0k free, 0k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28112 jetty 18 0 545m 136m 6100 S 0.0 13.4 3:06.41 jsvc
5570 postgres 15 0 107m 14m 5168 S 0.0 1.5 0:04.64 postgres
3178 postgres 18 0 107m 9.8m 4 S 0.0 1.0 0:03.59 postgres
5868 postgres 18 0 107m 9.8m 4 S 0.0 1.0 0:04.84 postgres

I'm not sure how these things works but the sum of the processes
virtual memory seems to be close to the total memory used.

Suggestions anyone?

Thanks!
-Fredrik

[Derek Williams]

Virt is what the kernel allows that process to use, but Res is the actual amount of RAM used. The total seems too high though, but I suspect that may be because you dont have any swap defined. Are you able to at least setup a swap file if you cant use an actual partition?

Also, what jvm options are you using? If you are using defaults, they scale with the total mem I believe.

I think thats all correct, but writing this from my phone so unable to doublecheck.

On 2010-07-02 5:07 PM, "Fredrik Jonsson" <fredri...@gmail.com> wrote:

These are the top stats from our VPS:

Mem:   1048576k total,   663416k used,   385160k free,        0k buffers
Swap:        0k total,        0k used,        0k free,        0k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28112 jetty     18   0  545m 136m 6100 S  0.0 13.4   3:06.41 jsvc
 5570 postgres  15   0  107m  14m 5168 S  0.0  1.5   0:04.64 postgres
 3178 postgres  18   0  107m 9.8m    4 S  0.0  1.0   0:03.59 postgres
 5868 postgres  18   0  107m 9.8m    4 S  0.0  1.0   0:04.84 postgres

I'm not sure how these things works but the sum of the processes
virtual memory seems to be close to the total memory used.

Suggestions anyone?

Thanks!
-Fredrik

On Fri, Jul 2, 2010 at 11:02 PM, Arthur Peters <a...@singingwizard.org> wrote:

> I would also love t...

--

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to t...

[Derek Williams]

To clarify, total should be Res, Buffers, and Cache. The total might be using Virt instead of Res due to the kernel not having swap to fall back on.

On 2010-07-02 6:29 PM, "Derek Williams" <de...@nebvin.ca> wrote:

Virt is what the kernel allows that process to use, but Res is the actual amount of RAM used. The total seems too high though, but I suspect that may be because you dont have any swap defined. Are you able to at least setup a swap file if you cant use an actual partition?

Also, what jvm options are you using? If you are using defaults, they scale with the total mem I believe.

I think thats all correct, but writing this from my phone so unable to doublecheck.

>
> On 2010-07-02 5:07 PM, "Fredrik Jonsson" <fredri...@gmail.com> wrote:
>

> These are the top...

[David Pollak]

On Fri, Jul 2, 2010 at 7:45 PM, Derek Williams <de...@nebvin.ca> wrote:

To clarify, total should be Res, Buffers, and Cache. The total might be using Virt instead of Res due to the kernel not having swap to fall back on.

To deploy, please download http://github.com/dpp/lift-samples/raw/master/jetty_instance.tgz and set the ram_size file to 64M and put your Lift app in webapps/root.war and run "start_prod.sh"

That'll consume about 96MB of total RAM.  You should be able to run the rest of your system (RDBMS, OS, etc.) in the remaining 32MB.

http://demo.liftweb.net serves a peak of 10 pages per second and typically has 500 sessions and it's running with 256MB of heap.

 

On 2010-07-02 6:29 PM, "Derek Williams" <de...@nebvin.ca> wrote:

Virt is what the kernel allows that process to use, but Res is the actual amount of RAM used. The total seems too high though, but I suspect that may be because you dont have any swap defined. Are you able to at least setup a swap file if you cant use an actual partition?

Also, what jvm options are you using? If you are using defaults, they scale with the total mem I believe.

I think thats all correct, but writing this from my phone so unable to doublecheck.

>
> On 2010-07-02 5:07 PM, "Fredrik Jonsson" <fredri...@gmail.com> wrote:
>

> These are the top...

>
>
> On Fri, Jul 2, 2010 at 11:02 PM, Arthur Peters <a...@singingwizard.org> wrote:

> I would also love t...

--

>
> You received this message because you are subscribed to the Google Groups "Lift" group.

To post to t...

--
You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Fredrik Jonsson]

Thank you! I'll try it out and get back with my findings. I like this community!

-Fredrik

[Fredrik Jonsson]

A final memory report if anyone is interested.

With 64mb heap jetty reports 119mb RES, postgres about 35mb RES and
rest of OS 10-20mb RES. I conclude that 128mb with some tweaking or on
the safe side 256 mb would be sufficient.

However since our VPS host (they use OpenVZ) doesn't allow swap top
reports 450mb total memory usage which forces us to buy 512 or even
768 mb to be on the safe side.

BR
-Fredrik

PS. switched to nginx asweel, thank you for pointing me to it.

[Arthur Peters]

Thanks for posting your results. Its quite illuminating (though it does leave me wondering why you would need swap or lots of extra RAM. What is soaking up the extra? I wonder.)

Just in case and one else had this confusion about the free service on Stax: free hosted apps hybernate after 24 hours HOWEVER this does not mean that an admin needs to poke it or anything. Any HTTP request to the app will wake it up. It just means that the first request after 24 hrs of non-use will take an extra few seconds while the VPS resumes from hibernation.

-Arthur (sent from phone)

On Jul 7, 2010 5:44 PM, "Fredrik Jonsson" <fredri...@gmail.com> wrote:

A final memory report if anyone is interested.

With 64mb heap jetty reports 119mb RES, postgres about 35mb RES and
rest of OS 10-20mb RES. I conclude that 128mb with some tweaking or on
the safe side 256 mb would be sufficient.

However since our VPS host (they use OpenVZ) doesn't allow swap top
reports 450mb total memory usage which forces us to buy 512 or even
768 mb to be on the safe side.

BR
-Fredrik

PS. switched to nginx asweel, thank you for pointing me to it.

On Sun, Jul 4, 2010 at 1:13 PM, Fredrik Jonsson <fredri...@gmail.com> wrote:

> Thank you! I'll ...

[Naftoli Gugenheim]

Interesting. What kind of "few seconds"? Like 3? Or 20?

--

[Arthur Peters]

They claim like 5 I think, but a quick test with the "basic eclipse app" (the one in the maven achetype) was more like 20 or maybe even 30. But that only happens the your app gets 0 hits in 24 hours I think. 

-Arthur (sent from phone)

On Jul 7, 2010 11:05 PM, "Naftoli Gugenheim" <nafto...@gmail.com> wrote:

Interesting. What kind of "few seconds"? Like 3? Or 20?

On Wed, Jul 7, 2010 at 6:51 PM, Arthur Peters <a...@singingwizard.org> wrote:

>
> Thanks for posting your results. Its quite illuminating (though it does leave me wondering why y...

--

> You received this message because you are subscribed to the Google Groups "Lift" group.

> To post ...

--
You received this message because you are subscribed to the Google Groups "Lift" group.

To post ...

[Timothy Perrett]

Correct - only if you get zero traffic.

[steve hermes]

Good info, thanks

[Naftoli Gugenheim]

I'd rather have that limitation than AppEngine's timing out requests after around that amount of time, if it still does that. :)

[philip]

Hello Mike,

I am going to use GAE as well using Liftweb. Do you have any recent
advice or problems?

Thanks, Philip

[Kevin Wright]

The general advice is not to use GAE :)

If you're after "free", then stax is a much better proposition.

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Timothy Perrett]

+1 

No threads in GAE!

Sent from my iPhone

[Okpala Ikenna N.]

Yeah kevin is right!! stax.net is easy to use java ee platform stack for lift and any other flavours of servlet applications.

Okpala Ikenna N. Jr.

[philip]

Do you all work for Stax?.... :)

Ok.. I agree, Stax seems to give a nice entry level to EC2. In the
case that a MySql database is going to be too small, then I could move
to a SimpleDB for some table which is large if my application did ever
get so large.

On Jul 14, 9:43 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
> +1
>
> No threads in GAE!
>
> Sent from my iPhone
>

> On 14 Jul 2010, at 14:37, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
>
>
>
> > The general advice is not to use GAE :)
> > If you're after "free", then stax is a much better proposition.
>

> > On 14 July 2010 13:51, philip <philip14...@gmail.com> wrote:
> > Hello Mike,
>
> > I am going to use GAE as well using Liftweb. Do you have any recent
> > advice or problems?
>
> > Thanks, Philip
>
> > On Jun 28, 12:45 am, melling <mmellinge...@gmail.com> wrote:
> > > I want to jump in and do a Scala/Lift project on theGoogle
> > > AppEngine.  Since I'm still pretty much a beginner in all 3
> > > technologies, I figure it's best to start with Scala 2.8/Lift 2 since
> > > they're almost production ready.  Can someone point me to a couple of
> > > recent blogs to get me started?  I'm not sure what changes occurred in
> > > the latest Scala/Lift versions so I'm not sure if older blog posts are
> > > still completely accurate.
>
> > > -Mike
>
> > --
> > You received this message because you are subscribed to the Google Groups "Lift" group.
> > To post to this group, send email to lif...@googlegroups.com.
> > To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en.
>
> > --
> > Kevin Wright
>
> > mail/google talk: kev.lee.wri...@gmail.com
> > wave: kev.lee.wri...@googlewave.com

[David Pollak]

On Thu, Jul 15, 2010 at 4:01 AM, philip <phili...@gmail.com> wrote:

Do you all work for Stax?....  :)

We're an opinionated bunch... we form strong opinions about what works for us.  The folks at Stax have been tremendously responsive to the Lift and Scala communities and we reflect that responsiveness in our recommendations.

 

Ok.. I agree, Stax seems to give a nice entry level to EC2. In the
case that a MySql database is going to be too small, then I could move
to a SimpleDB for some table which is large if my application did ever
get so large.

Or you can contact the Stax folks.  They make money when your app takes off... that's when they start selling you all kinds of management, scaling, etc. services and runtimes.  Don't worry, you'll be able to scale with Stax.

 

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Chris Perkins]

On Jul 15, 4:18 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> On Thu, Jul 15, 2010 at 4:01 AM, philip <philip14...@gmail.com> wrote:
>
> > Do you all work for Stax?....  :)
>
> We're an opinionated bunch... we form strong opinions about what works for
> us.  The folks at Stax have been tremendously responsive to the Lift and
> Scala communities and we reflect that responsiveness in our recommendations.
>

I'm not sure whether I'm understanding the pricing scheme, but the
cheapest non-free option seems to be 14c/hr, which is about $100 per
month. Is that right? Seems like a lot of money.

- Chris

[David Pollak]

It depends.  If you've got enough traffic to support your own box (which is 100 requests per second which if you can monitize at 0.0001 (one one-hundreth of a cent per request), means that you've got $24K/mo in revenue.)  And you're not going to get 100 requests per second (or even 10 requests per second) for free anywhere.

 

- Chris

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[sorenbs]

In the stax FAQ they state that
"It is important however to understand that as a cloud-based
application environment, there are some services your application will
need to avoid using to work properly. In general, applications will
run and scale best if they are designed so that the applications
maintain no state inside the appserver, and instead use external
datastores for persistence. Since application instances may come and
go at anytime, applications should avoid relying on the local-
persistence such as the filesystem or application variables that span
requests (such as static variables, or ServletContext/HttpSession
attributes). "

Is this a real consern for lift users?

On 15 Jul., 22:50, David Pollak <feeder.of.the.be...@gmail.com> wrote:

> On Thu, Jul 15, 2010 at 1:36 PM, Chris Perkins <chrisperkin...@gmail.com>wrote:
>
>
>
> > On Jul 15, 4:18 pm, David Pollak <feeder.of.the.be...@gmail.com>
> > wrote:
> > > On Thu, Jul 15, 2010 at 4:01 AM, philip <philip14...@gmail.com> wrote:
>
> > > > Do you all work for Stax?....  :)
>
> > > We're an opinionated bunch... we form strong opinions about what works
> > for
> > > us.  The folks at Stax have been tremendously responsive to the Lift and
> > > Scala communities and we reflect that responsiveness in our
> > recommendations.
>
> > I'm not sure whether I'm understanding the pricing scheme, but the
> > cheapest non-free option seems to be 14c/hr, which is about $100 per
> > month.  Is that right?  Seems like a lot of money.
>
> It depends.  If you've got enough traffic to support your own box (which is
> 100 requests per second which if you can monitize at 0.0001 (one
> one-hundreth of a cent per request), means that you've got $24K/mo in
> revenue.)  And you're not going to get 100 requests per second (or even 10
> requests per second) for free anywhere.
>
>
>
> > - Chris
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lif...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[Timothy Perrett]

You really do not need to worry about this.

> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

[philip]

Well, its interesting, Google App Engine folk keep saying the same
type of thing, don't hold state in the server between requests.
However, you lift people seem to like state. Also seam framework likes
state, encourages seam conversation scope.
It seems both state or no state can scale.

[Naftoli Gugenheim]

With stax you tell it how many instances to use. If you use more than one instance it would be problematic. To run more than one instance you need to have session affinity set up -- that means there's a frontend that makes sure any given session will always use the same instance -- and I don't know whether stax supports that.

[David Pollak]

On Thu, Jul 15, 2010 at 8:47 PM, philip <phili...@gmail.com> wrote:

Well, its interesting, Google App Engine folk keep saying the same
type of thing, don't hold state in the server between requests.
However, you lift people seem to like state. Also seam framework likes
state, encourages seam conversation scope.
It seems both state or no state can scale.

There's no such thing as "stateless".  There's only where you put the state.  See http://blog.lostlake.org/index.php?/archives/98-Back-in-the-Goat-Saddle.html

When you go with a migratable state architecture (each of your web front ends can migrate their state to another front end... either in the "we persist state externally on every request" [LAMP] or "we allow orderly migration of state" [J/EE], you have hidden scaling problems.  It's not until you get to the scale that you need to take advantage of the nominal scaling advantages that you realize that you have a really, really big problem.  If you use memcached to store state information, you're hosed because memcached is far less reliable than your average JVM instance.  If you use MySQL to store state information, you're hosed because MySQL scales until it doesn't and when it stops, it's ugly.

I've had exposure to a number of sites running at scale (sustaining 100+ requests per second).  The sites that are "stateless" generally have more scalability problems (e.g., memcached goes down and the service gets hinky), has a whole team devoted to managing the infrastructure for dealing with state, and has lots of infrastructure around deployment.  On the other hand, the likes of Lift, Seaside and WebObjects carry a lot of state in memory.  My experience with scalable applications written on these systems is that there are far fewer scalability issues and the requirements for managing these systems at scale is far less.

Put another way, with stateless, you're just playing whack-a-mole with state and that gets ugly at scale.  With stateful, you know exactly what the requirements are going in and you can deal with those requirements early and correctly.

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890