nterprise application. It
> did not require high user traffic, so were weren't concerned about what
> people talk about as the biggest issue with Wicket, namely scalability. We
> certainly have had no performance problems ourselves."
>
> Although this article was written som
concerned about what people talk
about as the biggest issue with Wicket, namely scalability. We certainly have
had no performance problems ourselves."
Although this article was written some months ago, I didn't notice any concerns
refering to scalability.
Do you know, what the author
ously, obtaining these rates depends on a lot of things, and we noticed
that (unsurprisingly) the number of cores has a big impact on maximum
scalability (32 / 8 = 4k per core).
If you use an antiquated server that still processes requests on a thread per
connection model, then your throughput
On Mon, 2010-04-12 at 08:31 +1000, Chris Colman wrote:
> > I hesitate between the 2 solutions, as I don't need EJBs, but we never
> > know !!! .
>
> If you have an app that currently doesn't need EJBs then keep it that
> way!! ;)
More EJB FUD yay
> I hesitate between the 2 solutions, as I don't need EJBs, but we never
> know !!! .
If you have an app that currently doesn't need EJBs then keep it that
way!! ;)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.
rations)
> hibernate
> jms
>
> At the beginning there will be 2 computers (I prefer horizontal scalability).
> What would be your advice for the hardware (hard drive will be 10.000 RPM).
> -processor ?
> -ram
For 200 concurrent sessions, 100 MB is probably already enough (20MB
Hi Wicketers,
1) I need to build a system which can perform
-6000 different users per day
and
-200 concurent users
The software used:
wicket
postgresql (mainly read operations)
hibernate
jms
At the beginning there will be 2 computers (I prefer horizontal scalability).
What would be your
nope that is dropped and isnt very likely implemented in a coming release
On Fri, May 15, 2009 at 15:15, manuelbarzi wrote:
> hi, again
>
> regarding wicket > features > scalability, clustering
>
> there is a mention about:
>
> "The next version of Wicket wil
hi, again
regarding wicket > features > scalability, clustering
there is a mention about:
"The next version of Wicket will support client-side models for zero-state
scalability."
is this already released?
please, let me know asap.
thank you.
gt;
> >>> After reviewing the Wicket feature list, I accidentally noticed the
> >>> following
> >>> statement:
> >>> "The next version of Wicket will support client-side models for
> >>> zero-state
> >>> scalability".
, Alex Objelean wrote:
>
> After reviewing the Wicket feature list, I accidentally noticed the
> following
> statement:
> "The next version of Wicket will support client-side models for zero-state
> scalability". I am wondering if this feature will be indeed implemented i
is no timeline for it.
>>
>> -Matej
>>
>> On Tue, Mar 24, 2009 at 11:47 AM, Alex Objelean
>> wrote:
>>>
>>> After reviewing the Wicket feature list, I accidentally noticed the
>>> following
>>> statement:
>>> "The nex
on of Wicket will support client-side models for
>> zero-state
>> scalability". I am wondering if this feature will be indeed implemented
>> in
>> (which?) next version or this is just some feature which sounds great for
>> marketability and will never by implemented?
&
ist, I accidentally noticed the following
> statement:
> "The next version of Wicket will support client-side models for zero-state
> scalability". I am wondering if this feature will be indeed implemented in
> (which?) next version or this is just some feature which sounds great
After reviewing the Wicket feature list, I accidentally noticed the following
statement:
"The next version of Wicket will support client-side models for zero-state
scalability". I am wondering if this feature will be indeed implemented in
(which?) next version or this is just some fea
2008/9/18 Uwe Schäfer <[EMAIL PROTECTED]>:
> James Carman schrieb:
>
> hi James
>
>> That's where I got the 100 thing.
>
> ah, i lost track of that. did not want to sound harsh or anything.
>
>> The folders won't be removed even after all of their
>> subfolders are removed, right?
>
> no empty fold
James Carman schrieb:
hi James
That's where I got the 100 thing.
ah, i lost track of that. did not want to sound harsh or anything.
The folders won't be removed even after all of their
subfolders are removed, right?
no empty folder should be left behind (if you stay away from just
killi
you can order it with windows hpc _or_ red hat linux :-)
> I saw that yesterday. I wonder if that thing will run linux? When I
> get rich and infamous, I'm buying one.
>>> Also, looking at this whole thing.
>>> 32000 concurrent sessions on one machine? What are you trying to achieve? I
>>> hav
Ok, now to get rich and infamous!
On Thu, Sep 18, 2008 at 10:49 AM, Jan Kriesten
<[EMAIL PROTECTED]> wrote:
>
> you can order it with windows hpc _or_ red hat linux :-)
>
>> I saw that yesterday. I wonder if that thing will run linux? When I
>> get rich and infamous, I'm buying one.
>
Also,
I saw that yesterday. I wonder if that thing will run linux? When I
get rich and infamous, I'm buying one.
On Thu, Sep 18, 2008 at 10:32 AM, Jan Kriesten
<[EMAIL PROTECTED]> wrote:
>
>> Also, looking at this whole thing.
>> 32000 concurrent sessions on one machine? What are you trying to achieve
> Also, looking at this whole thing.
> 32000 concurrent sessions on one machine? What are you trying to achieve? I
> have yet to see a machine that can handle 32k concurrent users...
hehe - the new 'Office Cray' CX1 might be up for the challenge. :D
>From Matej's previous email:
e.g. int hash = computeHash(sessionId) % 100;
String folder = "" + hash + "/" + sessionId;
That's where I got the 100 thing. So, what we're talking about here
is potentially 10k "buckets" for session store folders. There would
be the potential for 10k top-level fo
Also, looking at this whole thing.
32000 concurrent sessions on one machine? What are you trying to achieve? I
have yet to see a machine that can handle 32k concurrent users...
-Matej
On Thu, Sep 18, 2008 at 4:12 PM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> I don't you you want to come anywhere
I don't you you want to come anywhere near the amount of 32k files in
single folder.
I wouldn't assume that every filesystem can handle such amount without
performance problems.
-Matej
On Thu, Sep 18, 2008 at 1:49 PM, Johan Compagner <[EMAIL PROTECTED]>wrote:
> yes having this configurable look
Johan Compagner schrieb:
hi Johan
or does another filesystem has another limit?
from what i´ve googled, all FS i could think of either dont care, or
limit to (almost) 32k or more. (could be wrong here, anyone?)
hopefully the hash is a bit equally divided so the first dir will make 999
dir
yes having this configurable looks ridiculous to me.
The only thing that i can think of is is the 32K limit for all the
filesystems?
or does another filesystem has another limit?
Because if that is the case we could make it so that for example we do 3
(1000 dirs) or 4 (1 dirs) numbers per dir
James Carman schrieb:
So, why are we dividing it up in the first place if it can't lead to
problems?
before, there was just the sessionId, which - as we all know - could
lead to problems with 32k concurrent sessions.
what you now have is 8 numbers (like in 100.000.000 minus one) * 32k.
i
On Thu, Sep 18, 2008 at 3:35 AM, Uwe Schäfer <[EMAIL PROTECTED]> wrote:
> James Carman schrieb:
>
> hi james
>
>> Do you think that modulus number should be customizable? So, for now,
>> you mod your number of users by 100. But, for larger sites, they
>> might want to mod it by 1000 or 256 or wha
James Carman schrieb:
hi james
Do you think that modulus number should be customizable? So, for now,
you mod your number of users by 100. But, for larger sites, they
might want to mod it by 1000 or 256 or whatever.
actually, the first level dir is created from hash%1 and the second
fro
Do you think that modulus number should be customizable? So, for now,
you mod your number of users by 100. But, for larger sites, they
might want to mod it by 1000 or 256 or whatever.
On Wed, Sep 17, 2008 at 3:25 PM, Uwe Schäfer <[EMAIL PROTECTED]> wrote:
> Igor Vaynberg schrieb:
>>
>> you can p
Igor Vaynberg schrieb:
you can prefix the file with the session name...
appended a patch (to the issue) that uses two directory-levels (from the
hashcode) as a prefix to the sessionId and removes them on unbind().
thx for your suggestions.
cu uwe
---
Hash will only be there for the folder name.
e.g. int hash = computeHash(sessionId) % 100;
String folder = "" + hash + "/" + sessionId;
this way you will have 100 top level folders in which you'll have session
folders. This was it's much less likely to have 32k session in one folder.
Or you can a
you can prefix the file with the session name...
-igor
On Tue, Sep 16, 2008 at 2:17 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> A hash doesnt have to be unique for the same string :)
> So when will the first be that has session leakage because of that
>
> On 9/16/08, Matej Knopp <[EMAIL PROT
A hash doesnt have to be unique for the same string :)
So when will the first be that has session leakage because of that
On 9/16/08, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Another approach would be just counting hash from session id and mod it.
>
> -Matej
>
> On Tue, Sep 16, 2008 at 6:00 PM, Uw
Matej Knopp schrieb:
Another approach would be just counting hash from session id and mod it.
that´s much better for sure. i´ll do it asap.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL P
Another approach would be just counting hash from session id and mod it.
-Matej
On Tue, Sep 16, 2008 at 6:00 PM, Uwe Schäfer <[EMAIL PROTECTED]>wrote:
> Matej Knopp schrieb:
>
>> I had a quick glance at the patch. The folder hierarchy it creates seems
>> to
>> be quite deep, i'm not sure if that
Matej Knopp schrieb:
I had a quick glance at the patch. The folder hierarchy it creates seems to
be quite deep, i'm not sure if that is necessary. Perhaps 3-4 levels would
be enough? Also I'm afraid that this approach would leave lot of empty
folders.
well, that depends on the number of differe
I had a quick glance at the patch. The folder hierarchy it creates seems to
be quite deep, i'm not sure if that is necessary. Perhaps 3-4 levels would
be enough? Also I'm afraid that this approach would leave lot of empty
folders.
-Matej
On Tue, Sep 16, 2008 at 3:55 PM, Uwe Schäfer <[EMAIL PROTEC
Uwe Schäfer schrieb:
can you create an enhancement jira issue for this?
filed as WICKET-1837, patch against 1.4m3 included.
thx uwe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECT
Matej Knopp schrieb:
can you create an enhancement jira issue for this?
will do.
thx
cu uwe
--
THOMAS DAILY GmbH
Adlerstraße 19
79098 Freiburg
Deutschland
T + 49 761 3 85 59 0
F + 49 761 3 85 59 550
E [EMAIL PROTECTED]
www.thomas-daily.de
Geschäftsführer/Managing Directors:
Wendy Thomas
hi
in the near future, i´ll have to create a scalability presentation for a
webapp that uses wicket. i think, i´ll have enough ammo for the
non-wicket parts, so i try to gather some wicket related info now.
is there anything compact already i could use to summarize, why/how
wicket can scale
gt; is vague, but right now, so are our requirements.
>>
>> Thanks,
>> Lowell
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>&g
On 9/19/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> On 9/19/07, Lowell Kirsh <[EMAIL PROTECTED]> wrote:
> > For work I'm trying to use wicket, but my boss wants to be reassured
> > that it will scale well. Can anyone point me to any sources (not
> > anecdotes) about how well wicket scales? And
What do you mean with Scaling?
Wicket scales pretty well. because we fully support clustering out of the
box.
So you can add just add new servers.
Wicket it self is fast, the database would be much more of a bottleneck.
johan
On 9/19/07, Lowell Kirsh <[EMAIL PROTECTED]> wrote:
>
> For work I'm
On 9/19/07, Lowell Kirsh <[EMAIL PROTECTED]> wrote:
> For work I'm trying to use wicket, but my boss wants to be reassured
> that it will scale well. Can anyone point me to any sources (not
> anecdotes) about how well wicket scales? And yes, I know my question
> is vague, but right now, so are our
For work I'm trying to use wicket, but my boss wants to be reassured
that it will scale well. Can anyone point me to any sources (not
anecdotes) about how well wicket scales? And yes, I know my question
is vague, but right now, so are our requirements.
Thanks,
Lowell
-
46 matches
Mail list logo
