Running a huge wicket site(1m + users)

[Nino.Martinez]

Hi Guys

We are having the potential fun of running a site with around 1 million
users, and a lot more over time. What could be great optimizing points?

We have looked at these things

    * Detachable models (not sure if it makes anything run faster, just
      that it keeps the memory footprint down making more users possible
      on each server)
    * Web Cache(Oscache, Ehcache or Apache http)
    * Internal cache(Eh distributed cache)
    * Clustering(simple web server clustering with apache
      http/loadbalancer/tomcat)
          o Would Jetty be better?

Are there something we have forgotten? Have other point to pick out?
Should we investigate terracotta also(seems they integration are working
now)?

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Erik van Oosten]

Nino Saturnino Martinez Vazquez Wael wrote:
>    * Clustering(simple web server clustering with apache
>      http/loadbalancer/tomcat)
>          o Would Jetty be better?
Terracotta?


--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Nino.Martinez]

Yeah, will look into it.. And thanks! :)

Erik van Oosten wrote:

> Nino Saturnino Martinez Vazquez Wael wrote:
>  
>>    * Clustering(simple web server clustering with apache
>>      http/loadbalancer/tomcat)
>>          o Would Jetty be better?
>>    
> Terracotta?
>
>
> --
> Erik van Oosten
> http://day-to-day-stuff.blogspot.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>  

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Cristi Manole]

Hello,

Could you share with us the link to the website ? I don't think it's
jayway.dk.

And I was wondering what your DB is...? Are you using Hibernate?

I think everyone would appreciate you sharing all the information you can
about the design, etc. Most of us are hoping to build a website just like
yours :))

Btw, congrats :)

Cristi Manole

On Tue, Jul 15, 2008 at 5:49 PM, Nino Saturnino Martinez Vazquez Wael <
nino.martinez@...> wrote:

> Yeah, will look into it.. And thanks! :)
>
>
> Erik van Oosten wrote:
>
>> Nino Saturnino Martinez Vazquez Wael wrote:
>>
>>
>>>   * Clustering(simple web server clustering with apache
>>>     http/loadbalancer/tomcat)
>>>         o Would Jetty be better?
>>>
>>>
>> Terracotta?
>>
>>
>> --
>> Erik van Oosten
>> http://day-to-day-stuff.blogspot.com/
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>
> --
> -Wicket for love
>
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> [phone]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Nino.Martinez]

The site is not public yet, as we are in beta testing currently. I'll be
happy to give out links once we go public:)

Cristi Manole wrote:
> Hello,
>
> Could you share with us the link to the website ? I don't think it's
> jayway.dk.
>  
So true:)
> And I was wondering what your DB is...? Are you using Hibernate?
>  
We are using spring JDBC templates towards mysql
> I think everyone would appreciate you sharing all the information you can
> about the design, etc. Most of us are hoping to build a website just like
> yours :))
>  
I'll tell once the site goes public:)
> Btw, congrats :)
>  
Thanks..

> Cristi Manole
>
> On Tue, Jul 15, 2008 at 5:49 PM, Nino Saturnino Martinez Vazquez Wael <
> nino.martinez@...> wrote:
>
>  
>> Yeah, will look into it.. And thanks! :)
>>
>>
>> Erik van Oosten wrote:
>>
>>    
>>> Nino Saturnino Martinez Vazquez Wael wrote:
>>>
>>>
>>>      
>>>>   * Clustering(simple web server clustering with apache
>>>>     http/loadbalancer/tomcat)
>>>>         o Would Jetty be better?
>>>>
>>>>
>>>>        
>>> Terracotta?
>>>
>>>
>>> --
>>> Erik van Oosten
>>> http://day-to-day-stuff.blogspot.com/
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>>      
>> --
>> -Wicket for love
>>
>> Nino Martinez Wael
>> Java Specialist @ Jayway DK
>> http://www.jayway.dk
>> [phone]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
>  

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Ryan Sonnek-2]

On Tue, Jul 15, 2008 at 8:54 AM, Nino Saturnino Martinez Vazquez Wael <
nino.martinez@...> wrote:

> Hi Guys
>
> We are having the potential fun of running a site with around 1 million
> users, and a lot more over time. What could be great optimizing points?
>
> We have looked at these things
>
>   * Detachable models (not sure if it makes anything run faster, just
>     that it keeps the memory footprint down making more users possible
>     on each server)
>   * Web Cache(Oscache, Ehcache or Apache http)
>   * Internal cache(Eh distributed cache)
>   * Clustering(simple web server clustering with apache
>     http/loadbalancer/tomcat)
>         o Would Jetty be better?
>
> Are there something we have forgotten? Have other point to pick out? Should
> we investigate terracotta also(seems they integration are working now)?
>

Cache, Cache, Cache.  if you're running any high volume/traffic sites, you
absolutely need to leverage caching to get any amount of scalability.  This
goes for ANY web framework and not just wicket.

readup on some of the published whitepapers for high traffic sites (flickr
is a great case study) to see how they do it.

[Nino.Martinez]

thanks for the pointers..

Ryan Sonnek wrote:

> On Tue, Jul 15, 2008 at 8:54 AM, Nino Saturnino Martinez Vazquez Wael <
> nino.martinez@...> wrote:
>
>  
>> Hi Guys
>>
>> We are having the potential fun of running a site with around 1 million
>> users, and a lot more over time. What could be great optimizing points?
>>
>> We have looked at these things
>>
>>   * Detachable models (not sure if it makes anything run faster, just
>>     that it keeps the memory footprint down making more users possible
>>     on each server)
>>   * Web Cache(Oscache, Ehcache or Apache http)
>>   * Internal cache(Eh distributed cache)
>>   * Clustering(simple web server clustering with apache
>>     http/loadbalancer/tomcat)
>>         o Would Jetty be better?
>>
>> Are there something we have forgotten? Have other point to pick out? Should
>> we investigate terracotta also(seems they integration are working now)?
>>
>>    
>
>
> Cache, Cache, Cache.  if you're running any high volume/traffic sites, you
> absolutely need to leverage caching to get any amount of scalability.  This
> goes for ANY web framework and not just wicket.
>
> readup on some of the published whitepapers for high traffic sites (flickr
> is a great case study) to see how they do it.
>
>  

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Daan (StuQ)]

On 16 jul 2008, at 04:49, Ryan Sonnek wrote:

> On Tue, Jul 15, 2008 at 8:54 AM, Nino Saturnino Martinez Vazquez  
> Wael <
> nino.martinez@...> wrote:
>
>> We are having the potential fun of running a site with around 1  
>> million
>> users, and a lot more over time. What could be great optimizing  
>> points?
>>
>> We have looked at these things
>>
>>  * Detachable models (not sure if it makes anything run faster, just
>>    that it keeps the memory footprint down making more users possible
>>    on each server)
>>  * Web Cache(Oscache, Ehcache or Apache http)
>>  * Internal cache(Eh distributed cache)
>>  * Clustering(simple web server clustering with apache
>>    http/loadbalancer/tomcat)
>>        o Would Jetty be better?
>>
>> Are there something we have forgotten? Have other point to pick  
>> out? Should
>> we investigate terracotta also(seems they integration are working  
>> now)?
>
> Cache, Cache, Cache.  if you're running any high volume/traffic  
> sites, you
> absolutely need to leverage caching to get any amount of  
> scalability.  This
> goes for ANY web framework and not just wicket.
>
> readup on some of the published whitepapers for high traffic sites  
> (flickr
> is a great case study) to see how they do it.

Try to have the server-side as stateless as possible. If the state is  
at the client, any server can handle the requests without exchanging  
state. See http://cwiki.apache.org/WICKET/stateless-pages.html for a  
short intro. It will change the way you write your project, but  
keeping state server-side can be disastrous for real performance.

Regards,

Daan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Nino.Martinez]

Daan van Etten wrote:

> On 16 jul 2008, at 04:49, Ryan Sonnek wrote:
>
>> On Tue, Jul 15, 2008 at 8:54 AM, Nino Saturnino Martinez Vazquez Wael <
>> nino.martinez@...> wrote:
>>
>>> We are having the potential fun of running a site with around 1 million
>>> users, and a lot more over time. What could be great optimizing points?
>>>
>>> We have looked at these things
>>>
>>>  * Detachable models (not sure if it makes anything run faster, just
>>>    that it keeps the memory footprint down making more users possible
>>>    on each server)
>>>  * Web Cache(Oscache, Ehcache or Apache http)
>>>  * Internal cache(Eh distributed cache)
>>>  * Clustering(simple web server clustering with apache
>>>    http/loadbalancer/tomcat)
>>>        o Would Jetty be better?
>>>
>>> Are there something we have forgotten? Have other point to pick out?
>>> Should
>>> we investigate terracotta also(seems they integration are working now)?
>>
>> Cache, Cache, Cache.  if you're running any high volume/traffic
>> sites, you
>> absolutely need to leverage caching to get any amount of
>> scalability.  This
>> goes for ANY web framework and not just wicket.
>>
>> readup on some of the published whitepapers for high traffic sites
>> (flickr
>> is a great case study) to see how they do it.
>
> Try to have the server-side as stateless as possible. If the state is
> at the client, any server can handle the requests without exchanging
> state. See http://cwiki.apache.org/WICKET/stateless-pages.html for a
> short intro. It will change the way you write your project, but
> keeping state server-side can be disastrous for real performance.
>

Yeah I know, problem are that our application are ajax heavy, and
stateless and ajax does not cope well I've heard..
> Regards,
>
> Daan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Daan (StuQ)]

On 16 jul 2008, at 09:54, Nino Saturnino Martinez Vazquez Wael wrote:

> Daan van Etten wrote:
>> On 16 jul 2008, at 04:49, Ryan Sonnek wrote:
>>
>>> On Tue, Jul 15, 2008 at 8:54 AM, Nino Saturnino Martinez Vazquez  
>>> Wael <
>>> nino.martinez@...> wrote:
>>>
>>>> We are having the potential fun of running a site with around 1  
>>>> million
>>>> users, and a lot more over time. What could be great optimizing  
>>>> points?
>>>>
>>>> [..]
>>> Cache, Cache, Cache.  if you're running any high volume/traffic  
>>> sites, you
>>> absolutely need to leverage caching to get any amount of  
>>> scalability.  This
>>> goes for ANY web framework and not just wicket.
>>>
>>> readup on some of the published whitepapers for high traffic sites  
>>> (flickr
>>> is a great case study) to see how they do it.
>>
>> Try to have the server-side as stateless as possible. If the state  
>> is at the client, any server can handle the requests without  
>> exchanging state. See http://cwiki.apache.org/WICKET/stateless-pages.html 
>>  for a short intro. It will change the way you write your project,  
>> but keeping state server-side can be disastrous for real performance.
>>
> Yeah I know, problem are that our application are ajax heavy, and  
> stateless and ajax does not cope well I've heard..

Maybe not within Wicket, I know too little of Wicket to draw a valid  
conclusion on that. But it is definitely possible.
Look for example at the SproutCore development model. They create  
their application in Javascript and do requests to the backend to get  
records, save records, etc. Their application runs in the browser,  
making the server more like a stateless backend (from what I  
understood of SproutCore).
I know it's possible (and done before) to build a Javascript  
application (or even desktop) that way.

Regards,

Daan van Etten


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martijn Dashorst]

It is exactly the opposite: keeping state serverside increases
performance. It makes it more expensive to scale out, but that is
about it.

Keeping state readily available at the server ensures you don't have
to send it across the wire, or have to reconstruct it at the server.
It consumes memory, and bandwidth if you have to cluster your nodes
and need failover, but with a buddy system you don't have to send it
across your whole infrastructure.

Martijn

On Wed, Jul 16, 2008 at 9:51 AM, Daan van Etten <daan@...> wrote:

> On 16 jul 2008, at 04:49, Ryan Sonnek wrote:
>
>> On Tue, Jul 15, 2008 at 8:54 AM, Nino Saturnino Martinez Vazquez Wael <
>> nino.martinez@...> wrote:
>>
>>> We are having the potential fun of running a site with around 1 million
>>> users, and a lot more over time. What could be great optimizing points?
>>>
>>> We have looked at these things
>>>
>>>  * Detachable models (not sure if it makes anything run faster, just
>>>   that it keeps the memory footprint down making more users possible
>>>   on each server)
>>>  * Web Cache(Oscache, Ehcache or Apache http)
>>>  * Internal cache(Eh distributed cache)
>>>  * Clustering(simple web server clustering with apache
>>>   http/loadbalancer/tomcat)
>>>       o Would Jetty be better?
>>>
>>> Are there something we have forgotten? Have other point to pick out?
>>> Should
>>> we investigate terracotta also(seems they integration are working now)?
>>
>> Cache, Cache, Cache.  if you're running any high volume/traffic sites, you
>> absolutely need to leverage caching to get any amount of scalability.
>>  This
>> goes for ANY web framework and not just wicket.
>>
>> readup on some of the published whitepapers for high traffic sites (flickr
>> is a great case study) to see how they do it.
>
> Try to have the server-side as stateless as possible. If the state is at the
> client, any server can handle the requests without exchanging state. See
> http://cwiki.apache.org/WICKET/stateless-pages.html for a short intro. It
> will change the way you write your project, but keeping state server-side
> can be disastrous for real performance.
>
> Regards,
>
> Daan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Daan (StuQ)]

Hi Martijn,

On 16 jul 2008, at 10:19, Martijn Dashorst wrote:

> It is exactly the opposite: keeping state serverside increases
> performance. It makes it more expensive to scale out, but that is
> about it.
Can you elaborate a bit on your first statement? You need a lot of  
data-juggling for many clients, so I'd love to learn why it gives  
higher performance at the server.

In my opinion it depends on your use case, but in high-load  
environments I'd suggest to keep the state at the client. Sessions  
stored server-side not only make it more expensive to scale out, but  
you're going to hit the performance ceiling much sooner than with  
sessions at the client.

Regards,

Daan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Johan Compagner]

For wicket keeping server state gives you more performance, except maybe the
serialization penalty which is an overhead.

But if you have enough memory for your clients (the expense to scale out) it
is way faster

If you use bookmarkable/stateless pages then everything has to be
constructed on the the server everytime. If those pages
are huge you create a lot of garbage.

Also if you push a lot of state to the client means that you use more
bandwidth and that is way more expensive then memory/disk on the server.

If a page is in memory in wicket and you press for example refresh. It is
really really fast. there is almost no overhead what so ever.
(except getting data in the detached models again)

But this all depends greatly on what kind of framework you use. For example
GWT gives you only client side state, yes that scales pretty good on that
part.

johan



On Wed, Jul 16, 2008 at 10:33 AM, Daan van Etten <daan@...> wrote:

> Hi Martijn,
>
> On 16 jul 2008, at 10:19, Martijn Dashorst wrote:
>
>  It is exactly the opposite: keeping state serverside increases
>> performance. It makes it more expensive to scale out, but that is
>> about it.
>>
> Can you elaborate a bit on your first statement? You need a lot of
> data-juggling for many clients, so I'd love to learn why it gives higher
> performance at the server.
>
> In my opinion it depends on your use case, but in high-load environments
> I'd suggest to keep the state at the client. Sessions stored server-side not
> only make it more expensive to scale out, but you're going to hit the
> performance ceiling much sooner than with sessions at the client.
>
>
> Regards,
>
> Daan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Erik van Oosten]

IMHO whether state at the client helps hugely depends on the amount of
pages the user works with.

If the user hardly ever leaves that one single page, keeping state on
the client will help performance, provided the server does not need to
keep a copy of (all) that state. The latter deviates from the main
Wicket philosophy as I perceive it, but it is certainly possible in a
clean way. (In my current project we do this in a few places *.) If you
want to go this way, you'd better have a very Javascript capable person
in the team.

If your user is constantly requesting quite different pages, the Wicket
model is probably a better match (possibly using stateless pages
wherever possible).

Regards,
    Erik.



* Before you ask: we use JQuery to get content from a URL which maps to
a stateless Wicket page that serves HTML fragments. For more simple
things (e.g. validate an access code) we use a couple of servlets.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martijn Dashorst]

On Wed, Jul 16, 2008 at 10:33 AM, Daan van Etten <daan@...> wrote:
> Can you elaborate a bit on your first statement? You need a lot of
> data-juggling for many clients, so I'd love to learn why it gives higher
> performance at the server.

What is this data juggling you talk of? If you use sticky sessions
(which is really necessary for any serious web application IMO) there
should not be any data juggling.

> In my opinion it depends on your use case, but in high-load environments I'd
> suggest to keep the state at the client.

As long as you have 1 page that uses the server as an RPC service,
this works. WHen you have to transfer state between different pages
you'd rather keep the state on the server. Imagine posting 1MB of
client side state to the server, and then sending it back (happened
with a .net app).

> Sessions stored server-side not
> only make it more expensive to scale out, but you're going to hit the
> performance ceiling much sooner than with sessions at the client.

What performance ceiling are you talking about? There is no
performance penalty for storing state on the server, as long as you
don't have to synchronize it with other servers. Otherwise it is just
using memory, and functions as a good cache. To minimize clustering
overhead most folks choose sticky sessions with a buddy system for
failover.

Martijn

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Daan (StuQ)]

On 16 jul 2008, at 11:34, Martijn Dashorst wrote:

> On Wed, Jul 16, 2008 at 10:33 AM, Daan van Etten <daan@...> wrote:
>> Can you elaborate a bit on your first statement? You need a lot of
>> data-juggling for many clients, so I'd love to learn why it gives  
>> higher
>> performance at the server.
>
> What is this data juggling you talk of? If you use sticky sessions
> (which is really necessary for any serious web application IMO) there
> should not be any data juggling.
But if you need failover, you need a buddy system, because session  
sharing across multiple clusters is not that desirable or fast. You  
eliminate the necessary data-juggling by using an inferior way of  
failover. Because you need more memory and more processing power and  
LAN traffic to keep the state synchronized, you simply need more iron  
to serve your web application. So, you need to scale out to larger  
clusters earlier. It's cheaper and faster to keep the state at the  
client.

>
>> In my opinion it depends on your use case, but in high-load  
>> environments I'd
>> suggest to keep the state at the client.
>
> As long as you have 1 page that uses the server as an RPC service,
> this works. WHen you have to transfer state between different pages
> you'd rather keep the state on the server. Imagine posting 1MB of
> client side state to the server, and then sending it back (happened
> with a .net app).

So don't use multiple pages. Make your applications without complete  
page refreshes. Replace parts of your functionality, like panel  
replacing in Wicket. When you've fetched that panel once, cache it at  
the client (if done right, browsers do this for you automatically).  
The server thus only gives data or (static) JS/HTML. Transfer client-
fetched data in a format like JSON, which is easily compressed and can  
be fetched stateless. The server just 'dumbly' returns data, much like  
a session-less DB-server. It's even possible to aggressively cache  
these responses in the browser, on downstream servers and/or on the  
server.
This is exactly what GMail does, after your initial session. It seems  
to work for them... :-) GMail is one of the snappiest web apps out  
there. Google does complete page refreshes, but probably only because  
it is 90% search result data. Full page refreshes can also be cached,  
but only if they're stateless.

>
>> Sessions stored server-side not
>> only make it more expensive to scale out, but you're going to hit the
>> performance ceiling much sooner than with sessions at the client.
>
> What performance ceiling are you talking about? There is no
> performance penalty for storing state on the server, as long as you
> don't have to synchronize it with other servers. Otherwise it is just
> using memory, and functions as a good cache. To minimize clustering
> overhead most folks choose sticky sessions with a buddy system for
> failover.

As long as you don't have many visitors, you never will hit the  
performance ceiling. As soon as you need more than one server, you  
have to solve the session problem by limiting the synchronization of  
state or other workarounds. With a buddy system, you only have limited  
failover. It doesn't work with two independent data centers, unless  
you continuously want to push session state around. Really, with 1  
million users, and (guessing) 10.000-20.000 concurrent visitors, you  
really don't want to store all that session state. It will slow things  
down.

An interesting link: http://davidvancouvering.blogspot.com/2007/09/session-state-is-evil.html

Regards,

Daan van Etten


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...