On Jun 13, 8:38 pm, Oveek <[email protected]> wrote:
> Okay I've been doing some testing. I think your latest commit in the
> StoreSet has hit the problem at its source, but I'm seeing some things
> that still aren't making sense.

Unfortunately my change screws things up for sqlite, while working for
other DBs. So I'm exploring some options at the moment. Should have
something for you to try out in a few minutes.

> The scope and lifetime of objects is something I've been wondering
> about for a while. Based on some of the logging I did, I got the
> impression none of the objects in the stack persist across requests,
> which I found kind of odd

I think it may be less predictable than desired and it may also change
depending on which wsgi server is being used.

> It turns out the __del__ method is not a good indicator of an object's
> status because if I understand correctly, according to Python docs
> there is no guarantee that it will be called even on interpreter exit.
> Do you know a way to find out when an object gets finalized?

Unfortunately, no.

> That's good news for me. How much of that RAM is usually being used?
> I'm curious how well things will hold up under load. Based on the
> tests on my laptop, I'm going to have to do considerable tuning,
> because a heavy load with connection pooling enabled is causing memory
> consumption to jump a lot when there are many concurrent requests.

On the same server, but with different mod_wsgi daemon processes, a
tiddlyweb using the sql store using sqlite has a VSIZE of 142028. A
similarly configured instance using the text store is 109296. The
resident size of the sqlite one is 13788. This is
tiddlyweb.peermore.com.

In my experience from larger installations with Postgres, it's really
hard to get it right in terms of memory use and connection handling.
The default settings are not ideal: seem to lead to a large number of
processes using a large amount of RAM.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/TiddlyWikiDev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to