SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 30 of 30
  1. #26
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,629
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    .NET definitely sits on RAM when you've got the app pool spun up -- that is somewhat by design though. They trade an ugly first hit and big load for very, very fast loads behind it. You've certainly experienced this if you have done any .NET development.

    As for .NET and IIS, the default is to spin down app pools after 20 minutes as well as automatically recycle apps once a day -- both were precedents from previous IIS setups and from the day where you were running some horribly memory leakin. From what I understand, the general recommendation out of Redmond these days is to never spin down nor recycle automatically if you can help it. In any case, inside of the bounds of the app pool a .NET app is certainly persistent across requests even if an individual Page (or Controller) is a per-request instance. You can certainly shoot your app in the foot by failing to properly clean up resources or mishandling static variables.

    Quote Originally Posted by Kiwiheretic View Post
    That's an interesting point as I made the same argument (against certain rails deployments) here:

    http://www.sitepoint.com/forums/show....php?t=1198406

    I did a quick Google of uWSGI vs WSGI. I generally use Django with WSGI which is an apache module Wheras uWSGI is not. uWSGI runs as a separate process with all the extra ram that entails.

    The claim seems to be that if you have web application processes sitting around all the time, that they eliminate the startup and shutdown time of a script that needs to be invoked on every request.

    However the feeling I got is that PHP didn't perform badly in language benchmarks so maybe I need to see if I can get some good stats on that.
    In most web applications its not the language performance that matters but the database performance and the biggest lag in the request/response cycle seems to be I/O bound (database lag) most of the time. However I must admit I haven't done any high volume traffic testing with php against other language or framework configurations but would be interesting.
    There is a lot more than startup time involved in the differences. PHP's shared nothing model lets one do some things very quickly but precludes a lot of fancy stunts (such as dynamic-proxy based ORMs) that other platforms excel in. I don't think benchmarks make a whole lot of sense in general but especially between platforms -- end of the day the question isn't who can serve the most pages on the least hardware but "do you have enough throughput to keep your customers happy at a price you can afford."

  2. #27
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,127
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99 View Post
    .NET definitely sits on RAM when you've got the app pool spun up -- that is somewhat by design though. They trade an ugly first hit and big load for very, very fast loads behind it. You've certainly experienced this if you have done any .NET development.

    As for .NET and IIS, the default is to spin down app pools after 20 minutes as well as automatically recycle apps once a day -- both were precedents from previous IIS setups and from the day where you were running some horribly memory leakin. From what I understand, the general recommendation out of Redmond these days is to never spin down nor recycle automatically if you can help it. In any case, inside of the bounds of the app pool a .NET app is certainly persistent across requests even if an individual Page (or Controller) is a per-request instance. You can certainly shoot your app in the foot by failing to properly clean up resources or mishandling static variables.
    On first hit, it may cache your runtimes, but it doesn't just sit there automatically and it disappears after a lack of requests. This is as you say to ensure quick runtime, but I think it is a bit misleading to say it sits in memory all of the time, that part just isn't true.

    So maybe a difference in how it is "stated" more so than anything here between us. I've written a LOT of sites in IIS and the memory usage of the server isn't all that different from some of the Linux PHP servers I've built. You'll see it rise at the application being hit, and go back down when it isn't (granted in .NET servers it goes down a bit slower due to waiting to ensure there isn't another request coming in -- unless you knock down the app pool spin down time significantly).

    The servers I've setup, we never have to restart/recycle the app pools unless we need to clear the cache (and that is only because we never have zero requests coming in long enough for the app pools to spin down).

  3. #28
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,629
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    I think you are a bit mistaken here -- the app domain remains in memory so long as it's containing app pool is alive. App pools by default shut down after 20 minutes of inactivity so they do "disappear because of lack of requests" but for no reason internal to ASP.NET and everything to do with the hosting environment. This is unlike PHP where the longest anything can stay in memory is the life of the script period end of story. As I said the auto recycle (every 1740 minutes to be exact) is also there by default unless you actively disable it.

    Where this memory use matters is in the land of el cheapo shared hosting -- you can pack a lot more low-load PHP sites on a server and not see side effects than you can for any other platform because resource use is so focused to the execution time which is typically measured in milliseconds even for the slowest scripts. Contrast this with ASP.NET where that first hit and all the JIT stuff takes a fair amount of CPU and that app domain is going to want to remain standing for a bit consuming precious memory.

    If you are dealing with dedicated servers and non-trivial apps then you'll likely see somewhat similar resource consumption for similar scales of traffic no matter what the platform.

  4. #29
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,127
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99 View Post
    I think you are a bit mistaken here -- the app domain remains in memory so long as it's containing app pool is alive. App pools by default shut down after 20 minutes of inactivity so they do "disappear because of lack of requests" but for no reason internal to ASP.NET and everything to do with the hosting environment. This is unlike PHP where the longest anything can stay in memory is the life of the script period end of story. As I said the auto recycle (every 1740 minutes to be exact) is also there by default unless you actively disable it.
    Yes, but that is IIS, not .NET. I could just as easily create my application using mono, host it in apache and see that it doesn't use any additional memory just sitting there. .NET is not the culprit here. So I'm not mistaken.

    Quote Originally Posted by wwb_99 View Post
    Where this memory use matters is in the land of el cheapo shared hosting -- you can pack a lot more low-load PHP sites on a server and not see side effects than you can for any other platform because resource use is so focused to the execution time which is typically measured in milliseconds even for the slowest scripts.
    I don't buy that one bit. It is entirely dependent on how poorly the script is written, it isn't hard to see the affects of one bad site on a shared hosting account with PHP. Just because it doesn't sit there idle, doesn't mean it can't affect memory worse.

    Quote Originally Posted by wwb_99 View Post
    Contrast this with ASP.NET where that first hit and all the JIT stuff takes a fair amount of CPU and that app domain is going to want to remain standing for a bit consuming precious memory.
    So does PHP, all execution occurs on every hit, thus CPU and memory shoot up. With .NET at least, the subsequent hits on CPU and memory are far less. Plus the only thing really sitting in memory (and I'm not sure this is true; as .NET utilizes temporary folders to hold dlls processed recently by JIT), would be the basics for needing to kick the app off again quickly, it isn't storing much more than a bare minimum initialization process in actual memory.

    We have servers setup with over 50 app pools and 50 sites, no problems what-so-ever. There are 16 GB of RAM so across each app pool, there is roughly .32 gigs each. If memory were really an issue, this server would show it, but it doesn't.

  5. #30
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,629
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    This is getting to be quite a bit of a derail but what the hey I'll bite.

    Quote Originally Posted by cpradio View Post
    Yes, but that is IIS, not .NET. I could just as easily create my application using mono, host it in apache and see that it doesn't use any additional memory just sitting there. .NET is not the culprit here. So I'm not mistaken.
    You are certainly mistaken about Mono's structure -- see http://www.mono-project.com/Mod_mono for details but mono clearly runs as a separate process and persistent apps server behind apache. Reading through the documentation it seems that it works much like phusion passenger does for ruby or uwsgi apps in terms of mating apache with a persistent back end that apache does not do well at.

    In any case the model works like this -- you have an app pool which has an application manager which in turn spins up and destroys app domains. App domains are what your program typically sees -- IE if you have a typical static class with a static member variable it is shared throughout the app domain. Individual requests are threads within said app domain in general. Overall, you might want to read http://www.west-wind.com/presentatio...spnetworks.asp -- it is a bit dated (based on IIS6) but still very valuable in terms of understanding the nuts and bolts here.

    I don't buy that one bit. It is entirely dependent on how poorly the script is written, it isn't hard to see the affects of one bad site on a shared hosting account with PHP. Just because it doesn't sit there idle, doesn't mean it can't affect memory worse.
    You can certainly bring down the server in a single badly written script in any language. But that is fundamentally harder to do when the script has a limited lifecycle and will either hit the memory limit or the timeout and die. Compare that with persistent app servers which will continually leak memory until they have to be reset and also keep other apps and then keep soaking up RAM.

    So does PHP, all execution occurs on every hit, thus CPU and memory shoot up. With .NET at least, the subsequent hits on CPU and memory are far less. Plus the only thing really sitting in memory (and I'm not sure this is true; as .NET utilizes temporary folders to hold dlls processed recently by JIT), would be the basics for needing to kick the app off again quickly, it isn't storing much more than a bare minimum initialization process in actual memory.
    Exactly -- .NET loads a lot up front then subsequent requests are cheaper. I'd also note that PHP tries to do at least some of this stuff inasmuch as most modern php setups include an opcode cache to cut down on the work of parsing the php script every time it is requested. I know the WebPI version includes this by default; most *nix setups include APC or something similar. You might want to do some memory profiling of your own apps -- my general experience is that if an app is typically using 250mb of RAM then you'll see it eat 175 or so on the 1st request and ramp up a bit after as caches and pages get hit and hydrated to memory.

    We have servers setup with over 50 app pools and 50 sites, no problems what-so-ever. There are 16 GB of RAM so across each app pool, there is roughly .32 gigs each. If memory were really an issue, this server would show it, but it doesn't.
    That is pretty typical usage -- our big, mean, busy apps sit in ~250mb app pools, the lower priority ones seem to live in ~150mb. Moreover, for a typical oversold shared hosting scenario 50 apps is a drop in the bucket -- how would your servers handle 5000 apps at that scale? That is apparently a light load for alot of the $3/mo hosting outfits -- the more the merrier there.

    FWIW, from what I know bad mojo starts happening when the app pool hits 6-800mb though that could have been a .NET 2.0 thing as we've typically avoided said mojo since those days so I don't know if that has moved a bit.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •