Web Farms and session handling

Hi!
We have a problem which is correlated to web farms and session handling and
are thinking of what solution to choose.
Our setup is with a web farm, one ldap server and a database cluster.
The web farm is doing searches which are quite performance expensive against
the ldap server, taking up to 10 or 15 seconds. The searches are displayed
to the client in a datagrid, which then may have to be paged.
There are different ways to handle paging:
- do the search again against the ldap, but in our opinion that is to slow
to be an option.
- save the search result in the viewstate, but that gives pages roundtrip
with sizes of megabytes.
- save the search result in the in-proc session, but that can't handle where
the session is moved to another server within the web farm.
- save the search result in the aspnet state server session, but the state
server isn't cluster-aware and is therefore a single point of failure, which
really isn't an option.
- save the search result in a sql session, but according to MS articles this
normally requires a new database server, in our case a database cluster. The
cost for another database cluster (hardware, software, maintanance and so
on) is high.
Anyone have any ideas that'll solve our problem? Anyone have any high load
experience with SQL server sessions?
Regards,
Johnif you have a sqlserver cluster, you don't need a new one. the resources for
using sqlserver for state management is low, single row read and write per
page flip. your current server should hardly notice it.
aspstate is a pretty simple database as are the queries.
-- bruce (sqlwork.com)
"John Allberg" <smuda@.nospam.nospam> wrote in message
news:uia8TOn9FHA.2364@.TK2MSFTNGP12.phx.gbl...
> Hi!
> We have a problem which is correlated to web farms and session handling
> and are thinking of what solution to choose.
> Our setup is with a web farm, one ldap server and a database cluster.
> The web farm is doing searches which are quite performance expensive
> against the ldap server, taking up to 10 or 15 seconds. The searches are
> displayed to the client in a datagrid, which then may have to be paged.
> There are different ways to handle paging:
> - do the search again against the ldap, but in our opinion that is to slow
> to be an option.
> - save the search result in the viewstate, but that gives pages roundtrip
> with sizes of megabytes.
> - save the search result in the in-proc session, but that can't handle
> where the session is moved to another server within the web farm.
> - save the search result in the aspnet state server session, but the state
> server isn't cluster-aware and is therefore a single point of failure,
> which really isn't an option.
> - save the search result in a sql session, but according to MS articles
> this normally requires a new database server, in our case a database
> cluster. The cost for another database cluster (hardware, software,
> maintanance and so on) is high.
>
> Anyone have any ideas that'll solve our problem? Anyone have any high load
> experience with SQL server sessions?
> Regards,
> John
>
Thanks for Bruce's input.
Hi John,
I agree with Bruce on this. And so far in ASP.NET 1.X if stateserver of not
possible, SqlServer session maybe the only considerable approach for
webfarm or webgarden scenario...
BTW. in ASP.NET 2.0 we can replace the default build-in sessionState module
with our own custom module , that may help implement our own session
storage mechanism...
Regards,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
| From: "Bruce Barker" <brubar_nospamplease_@.safeco.com>
| References: <uia8TOn9FHA.2364@.TK2MSFTNGP12.phx.gbl>
| Subject: Re: Web Farms and session handling
| Date: Thu, 1 Dec 2005 10:31:56 -0800
| Lines: 56
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| X-RFC2646: Format=Flowed; Response
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| Message-ID: <u13JDWq9FHA.3048@.TK2MSFTNGP10.phx.gbl>
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: rdcsd1.safeco.com 12.144.134.2
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:362123
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| if you have a sqlserver cluster, you don't need a new one. the resources
for
| using sqlserver for state management is low, single row read and write
per
| page flip. your current server should hardly notice it.
|
| aspstate is a pretty simple database as are the queries.
|
|
| -- bruce (sqlwork.com)
|
|
|
|
|
| "John Allberg" <smuda@.nospam.nospam> wrote in message
| news:uia8TOn9FHA.2364@.TK2MSFTNGP12.phx.gbl...
| > Hi!
| >
| > We have a problem which is correlated to web farms and session handling
| > and are thinking of what solution to choose.
| >
| > Our setup is with a web farm, one ldap server and a database cluster.
| >
| > The web farm is doing searches which are quite performance expensive
| > against the ldap server, taking up to 10 or 15 seconds. The searches
are
| > displayed to the client in a datagrid, which then may have to be paged.
| >
| > There are different ways to handle paging:
| > - do the search again against the ldap, but in our opinion that is to
slow
| > to be an option.
| >
| > - save the search result in the viewstate, but that gives pages
roundtrip
| > with sizes of megabytes.
| >
| > - save the search result in the in-proc session, but that can't handle
| > where the session is moved to another server within the web farm.
| >
| > - save the search result in the aspnet state server session, but the
state
| > server isn't cluster-aware and is therefore a single point of failure,
| > which really isn't an option.
| >
| > - save the search result in a sql session, but according to MS articles
| > this normally requires a new database server, in our case a database
| > cluster. The cost for another database cluster (hardware, software,
| > maintanance and so on) is high.
| >
| >
| > Anyone have any ideas that'll solve our problem? Anyone have any high
load
| > experience with SQL server sessions?
| >
| > Regards,
| >
| > John
| >
| >
|
|
|
Hi!
Thanks for the help. With this info, we'll go with SQLState.
Thanks,
John
"Steven Cheng[MSFT]" <stcheng@.online.microsoft.com> wrote in message
news:aPiafhu9FHA.4028@.TK2MSFTNGXA02.phx.gbl...
> Thanks for Bruce's input.
> Hi John,
> I agree with Bruce on this. And so far in ASP.NET 1.X if stateserver of
> not
> possible, SqlServer session maybe the only considerable approach for
> webfarm or webgarden scenario...
> BTW. in ASP.NET 2.0 we can replace the default build-in sessionState
> module
> with our own custom module , that may help implement our own session
> storage mechanism...
> Regards,
> Steven Cheng
> Microsoft Online Support
> Get Secure! www.microsoft.com/security
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
> --
> | From: "Bruce Barker" <brubar_nospamplease_@.safeco.com>
> | References: <uia8TOn9FHA.2364@.TK2MSFTNGP12.phx.gbl>
> | Subject: Re: Web Farms and session handling
> | Date: Thu, 1 Dec 2005 10:31:56 -0800
> | Lines: 56
> | X-Priority: 3
> | X-MSMail-Priority: Normal
> | X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
> | X-RFC2646: Format=Flowed; Response
> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
> | Message-ID: <u13JDWq9FHA.3048@.TK2MSFTNGP10.phx.gbl>
> | Newsgroups: microsoft.public.dotnet.framework.aspnet
> | NNTP-Posting-Host: rdcsd1.safeco.com 12.144.134.2
> | Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
> | Xref: TK2MSFTNGXA02.phx.gbl
> microsoft.public.dotnet.framework.aspnet:362123
> | X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
> |
> | if you have a sqlserver cluster, you don't need a new one. the resources
> for
> | using sqlserver for state management is low, single row read and write
> per
> | page flip. your current server should hardly notice it.
> |
> | aspstate is a pretty simple database as are the queries.
> |
> |
> | -- bruce (sqlwork.com)
> |
> |
> |
> |
> |
> | "John Allberg" <smuda@.nospam.nospam> wrote in message
> | news:uia8TOn9FHA.2364@.TK2MSFTNGP12.phx.gbl...
> | > Hi!
> | >
> | > We have a problem which is correlated to web farms and session
> handling
> | > and are thinking of what solution to choose.
> | >
> | > Our setup is with a web farm, one ldap server and a database cluster.
> | >
> | > The web farm is doing searches which are quite performance expensive
> | > against the ldap server, taking up to 10 or 15 seconds. The searches
> are
> | > displayed to the client in a datagrid, which then may have to be
> paged.
> | >
> | > There are different ways to handle paging:
> | > - do the search again against the ldap, but in our opinion that is to
> slow
> | > to be an option.
> | >
> | > - save the search result in the viewstate, but that gives pages
> roundtrip
> | > with sizes of megabytes.
> | >
> | > - save the search result in the in-proc session, but that can't handle
> | > where the session is moved to another server within the web farm.
> | >
> | > - save the search result in the aspnet state server session, but the
> state
> | > server isn't cluster-aware and is therefore a single point of failure,
> | > which really isn't an option.
> | >
> | > - save the search result in a sql session, but according to MS
> articles
> | > this normally requires a new database server, in our case a database
> | > cluster. The cost for another database cluster (hardware, software,
> | > maintanance and so on) is high.
> | >
> | >
> | > Anyone have any ideas that'll solve our problem? Anyone have any high
> load
> | > experience with SQL server sessions?
> | >
> | > Regards,
> | >
> | > John
> | >
> | >
> |
> |
> |
>
You're welcome John,
Regards,
Steven Cheng
Microsoft Online Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
| From: "John Allberg" <smuda@.nospam.nospam>
| References: <uia8TOn9FHA.2364@.TK2MSFTNGP12.phx.gbl>
<u13JDWq9FHA.3048@.TK2MSFTNGP10.phx.gbl>
<aPiafhu9FHA.4028@.TK2MSFTNGXA02.phx.gbl>
| Subject: Re: Web Farms and session handling
| Date: Tue, 6 Dec 2005 09:24:40 +0100
| Lines: 121
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2527
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
| X-RFC2646: Format=Flowed; Original
| Message-ID: <eexaD6j#FHA.2300@.TK2MSFTNGP10.phx.gbl>
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: pc5161235.han.telia.se 131.115.161.235
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl
microsoft.public.dotnet.framework.aspnet:362973
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| Hi!
|
| Thanks for the help. With this info, we'll go with SQLState.
|
| Thanks,
|
| John
|
| "Steven Cheng[MSFT]" <stcheng@.online.microsoft.com> wrote in message
| news:aPiafhu9FHA.4028@.TK2MSFTNGXA02.phx.gbl...
| > Thanks for Bruce's input.
| >
| > Hi John,
| >
| > I agree with Bruce on this. And so far in ASP.NET 1.X if stateserver of
| > not
| > possible, SqlServer session maybe the only considerable approach for
| > webfarm or webgarden scenario...
| > BTW. in ASP.NET 2.0 we can replace the default build-in sessionState
| > module
| > with our own custom module , that may help implement our own session
| > storage mechanism...
| >
| > Regards,
| >
| > Steven Cheng
| > Microsoft Online Support
| >
| > Get Secure! www.microsoft.com/security
| > (This posting is provided "AS IS", with no warranties, and confers no
| > rights.)
| >
| > --
| > | From: "Bruce Barker" <brubar_nospamplease_@.safeco.com>
| > | References: <uia8TOn9FHA.2364@.TK2MSFTNGP12.phx.gbl>
| > | Subject: Re: Web Farms and session handling
| > | Date: Thu, 1 Dec 2005 10:31:56 -0800
| > | Lines: 56
| > | X-Priority: 3
| > | X-MSMail-Priority: Normal
| > | X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| > | X-RFC2646: Format=Flowed; Response
| > | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| > | Message-ID: <u13JDWq9FHA.3048@.TK2MSFTNGP10.phx.gbl>
| > | Newsgroups: microsoft.public.dotnet.framework.aspnet
| > | NNTP-Posting-Host: rdcsd1.safeco.com 12.144.134.2
| > | Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP10.phx.gbl
| > | Xref: TK2MSFTNGXA02.phx.gbl
| > microsoft.public.dotnet.framework.aspnet:362123
| > | X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
| > |
| > | if you have a sqlserver cluster, you don't need a new one. the
resources
| > for
| > | using sqlserver for state management is low, single row read and write
| > per
| > | page flip. your current server should hardly notice it.
| > |
| > | aspstate is a pretty simple database as are the queries.
| > |
| > |
| > | -- bruce (sqlwork.com)
| > |
| > |
| > |
| > |
| > |
| > | "John Allberg" <smuda@.nospam.nospam> wrote in message
| > | news:uia8TOn9FHA.2364@.TK2MSFTNGP12.phx.gbl...
| > | > Hi!
| > | >
| > | > We have a problem which is correlated to web farms and session
| > handling
| > | > and are thinking of what solution to choose.
| > | >
| > | > Our setup is with a web farm, one ldap server and a database
cluster.
| > | >
| > | > The web farm is doing searches which are quite performance expensive
| > | > against the ldap server, taking up to 10 or 15 seconds. The searches
| > are
| > | > displayed to the client in a datagrid, which then may have to be
| > paged.
| > | >
| > | > There are different ways to handle paging:
| > | > - do the search again against the ldap, but in our opinion that is
to
| > slow
| > | > to be an option.
| > | >
| > | > - save the search result in the viewstate, but that gives pages
| > roundtrip
| > | > with sizes of megabytes.
| > | >
| > | > - save the search result in the in-proc session, but that can't
handle
| > | > where the session is moved to another server within the web farm.
| > | >
| > | > - save the search result in the aspnet state server session, but the
| > state
| > | > server isn't cluster-aware and is therefore a single point of
failure,
| > | > which really isn't an option.
| > | >
| > | > - save the search result in a sql session, but according to MS
| > articles
| > | > this normally requires a new database server, in our case a database
| > | > cluster. The cost for another database cluster (hardware, software,
| > | > maintanance and so on) is high.
| > | >
| > | >
| > | > Anyone have any ideas that'll solve our problem? Anyone have any
high
| > load
| > | > experience with SQL server sessions?
| > | >
| > | > Regards,
| > | >
| > | > John
| > | >
| > | >
| > |
| > |
| > |
| >
|
|
|