Re: comparison of the NOVM version

> I've been running an experiment to try to quantify the differences
> between the regular Squid and the NOVM version. The results are
> at http://squid.nlanr.net/Squid/Devel/NOVM-compare/.
>
> Comments would be appreciated, as well as any other results comparing
> the two versions.
>
> Duane W.

    This is very interesting. I'm surprised that NOVM performs that close
 to VM version, I'd expect it to be much slower.

    Guess: NOVM is slightly faster on HIT's because there is no delay of
 objects being swapped in into VM initially.

    Then again, if pushed by zillions of small MISS requests I think NOVM
 would be slower somewhat as each fileopen adds additional time to
 request service times.

    It would be interesting to find out, which tradeoff is more critical,
 whether memory or FD count. Especially I'd like to point out that VM
 version response time can drop dramatically when VM usage hits the RAM
 limits while NOVM version goes on. On the other hand, if FD limit is
 reached on NOVM, further requests are not accepted while those that are
 being serviced do not suffer delays from OS paging. NOVM version has
 RAM usage under control while VM version can suffer from runaway ram
 problems and/or denial of service (either intensional or not)

    I'd like to see how both versions will behave when they are pushed
 by say 1000-2000 concurrent sessions, each session lasting average 10-20
 secs for a MISS (this is the average we see over congested links here)
 and with some percent of sessions being large ftp transfers which in
 real life tend to last longest and as such hook up most of the VM.
 Interesting would be to see a research on how VM response times changes
 if it is short of RAM and paging begins.
 Sadly, I have no spare resources to setup such tests here for myself.

    FD usage is quite similar for both versions with only NOVM/MISS
 having 50% more FD's in use, while memory use differs by several times.

    I think, NOVM version is as vital as VM version, and only sites
 that has a need to serve these 50% more concurrent sessions and have
 (real-)plenty of RAM might be forced to use VM version. I am not any
 special NOVM fan, (I use VM for now) but VM version has given me many
 times headaches with its memory consumption.
    One thing is _average_ which is nice and useful thing for decisions,
 but the other thing is _peak_ usage, and thats what NOVM deals better with.
 Usual failure scenario: evening time, lots of teenagers browse xxx sites,
 some users download large packages, all over congested links, and final
 destinaltion over dialup lines, all taking considerable time to complete,
 be it either HIT or MISS, building up tons of MB-s of VM usage not
 fitting into RAM, and paging starts. Now not only large and distant
 downloads are slow, but also small and nearby sessions start to take
 long time, and the snowball starts rolling, new requests come in faster
 than old ones gets serviced, VM only grows and FD's are consumed, until
 either users gets bored and cancel download, timeout is reached, or out
 of memory condition crashes whole squid.
    We here now we run with 256MB of RAM, because 128MB was not enough,
 and squid size is 120MB, rarely being bigger, so we have about a half of
 RAM just sitting and waiting to be available in _peak_ usage periods,
 "just in case"..

    VM and NOVM are now like two extremes. NOVM gives much load to disks
 and in the end might have disk io as speed limiting factor. What about
 taking best of both?

    I'd like to see that Squid would write objects to disk while they
 are imported, especially for objects that are over the average size,
 or some preconfigured max (maximum_object_size for eg).
    Small objects that would fit into buffers and are thus consuming RAM
 anyway (1024/2048/8192 bytes per buffer) might be held in VM until
 transfer is complete and then saved to disk in burst mode like VM does,
 so not tieing up FD's for the whole session time.
    Most hot objects could be held in VM as long as there is enough RAM,
 thus speeding up most frequently accessed objects while having RAM usage
 still under control and avoiding disk io as bonus.
    Such a version could be configured by options to be either VM version
 or NOVM version by managers preference, by just configuring max_obj_size
 between 0 bytes and xxxx MBytes and it would be easier to maintain and
 develop a single branch...

 regards,

-------------------------------------------------------------------
 Andres Kroonmaa Telefon: 6308 909
 Network administrator
 E-mail: andre@ml.ee Phone: (+372) 6308 909
 Organization: MicroLink Online
 EE0001, Estonia, Tallinn, Sakala 19 Fax: (+372) 6308 901
-------------------------------------------------------------------
Received on Tue Jul 29 2003 - 13:15:41 MDT