-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 8/10/2010 5:31 PM, André Warnier wrote:
> It is just that 3000 MB is *a lot* of bytes (3,145,728,000 of them).
Yup. 3000MiB is even bigger (3,221,225,472 of them), and what you'll get
from the JVM. (See below)
> Which means that each time one of these users hits the system,
> Tomcat would need to read and load 1 MB of data just to retrieve
> this user's previous session data, without even having done anything
> yet for this user and his present request.
Maybe, but maybe not: the Java heap is usually entirely in memory, so
in-memory session data is very quickly accessed (or ignored, depending
on how the request is handled). There is no penalty for loading this
session data in this case. Unless otherwise configured, all session data
stays in-memory during the lifetime of the context. This isn't like PHP
(or Perl?) where the sessions are serialized every time a request
completes and de-serialized when a request begins (and the session data
must be fetched).
In the case where the session data is stored on disk or in a database,
the penalty for accessing data is highly dependent upon the strategy for
storage and retrieval: if the entire session must be fetched from
storage unconditionally, then yes, it is a giant waste of time if that
data is not used every time. Heck, it's a giant waste of time no matter
what. On the other hand, if session attributes are stored and accessed
individually, one may be able to get away with little to no overhead for
session attributes that one actually uses (and no overhead if the
session is not used).
> One may wonder how fast this server is expected to be, if it handles
> 3,000 user sessions simultaneously ?
3000 sessions isn't really that crazy when you think about it. 3000
simultaneous requests might be a bit heavy on a single, modest server.
> So let's say that I am just curious as to what the application is.
Agreed.
> Where I do object :
>
> Christopher Schultz wrote: ...
>>
>> 2. Caches. This may be something that is often not considered for a
>> Perl hacker such as yourself, where webapps tend to be scripts that
>> run once and then terminate.
>
> Wrong. I am also a mod_perl hacker. In a mod_perl environment,
> scripts (or handlers) do not "terminate", and memory is not recycled
> (this is even an inconvenient of mod_perl, and something to watch
> when designing mod_perl applications).
Apologies. I was thinking the .cgi-style scripts that I'm pretty sure
/do/ terminate. Use of mod_perl is outside the scope of my argument :)
> A secondary motive for my question to the OP, was to find out
> whether this size was really the result of a rational calculation
> (or experience), or just some number plucked out of the air. RAM
> prices are fickle, but let's say that for server-quality RAM, one
> currently pays 25 US$ per GB. And we do not know who the OP works
> for, but say he is talking about 1,000 Tomcat servers.
That's 3TiB of RAM. Sweet.
> Saving 1 GB of
> Heap to run his applications would thus mean saving 25,000 US$. I
> believe it is worth asking the question.
Agreed.
- -chris
N.B. I was unable to get a predictable maximum heap size when running
with -Xmx:
public class MemoryInfo
{
public static void main(String[] args)
{
Runtime rt = Runtime.getRuntime();
System.out.printf("total=%10db (%4dMiB)", rt.totalMemory(),
(rt.totalMemory() / (1024*1024)));
System.out.println();
System.out.printf(" max=%10db (%4dMiB)", rt.maxMemory(),
(rt.maxMemory() / (1024*1024)));
System.out.println();
System.out.printf(" free=%10db (%4dMiB)", rt.freeMemory(),
(rt.freeMemory() / (1024*1024)));
System.out.println();
}
}
$ java -Xmx10M MemoryInfo
total= 9961472b ( 9MiB)
max= 9961472b ( 9MiB)
free= 9731320b ( 9MiB)
Note that 9437184 (1024 * 1024 * 9) < 9961472, so I'm not sure why the
extra memory. The code above doesn't necessarily get /only/ heap memory,
but you get an extra 5% for some reason.
$ java -Xmx100M MemoryInfo
total= 64356352b ( 61MiB)
max= 93257728b ( 88MiB)
free= 64019480b ( 61MiB)
That's weird: the JVM gives me less than I requested this time: only 88%
of what I requested.
$ java -showversion -Xmx1000M MemoryInfo
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)
total= 64356352b ( 61MiB)
max= 932118528b ( 888MiB)
free= 64019480b ( 61MiB)
... and again: less than I requested. Odd. Even when I use 1MB = 1024 *
1000, I'm still being stiffed by the JVM.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxhztUACgkQ9CaO5/Lv0PAXeACeP4uhSfDmw/GedynYNMvBqKUY
YdcAn09WBlQS8e16CUjo/wQQy+jqMP7x
=ENGs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
