Improve performance by bringing back the ghetto

[Paul Everitt]

Per Tres's suggestion, help the main app server's cache stay warm, and the catalog's cache stay warm, by putting searches back into the ghetto.

[Chris Rossi (chris-archimedeanco)]

Everybody or just OSI?

[Paul Everitt (paul-agendaless)]

Whatever you think best. Fine by me either way. Just OSI, for all I care.

While I'm at it, I notice we're only running one appserver daemon with 4 threads. Perhaps OSI should have more? I realize that number of processes, threads, and cache size are all voodoo. But just one, sounds somewhat wrong.

--Paul

On Aug 2, 2010, at 5:07 PM, Chris Rossi wrote:

> Everybody or just OSI?
>
> --
> Improve performance by bringing back the ghetto
> https://bugs.launchpad.net/bugs/612730
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in KARL3: New
>
> Bug description:
> Per Tres's suggestion, help the main app server's cache stay warm, and the catalog's cache stay warm, by putting searches back into the ghetto.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/karl3/+bug/612730/+subscribe

[Chris Rossi (chris-archimedeanco)]

If possible, I would like to defer this until after the two performance enhancements we've already done hit at least staging, if not production. This way we can better sort out the impact of this versus the other enhancements.

[Chris Rossi (chris-archimedeanco)]

Oops, sorry, I missed that you already have this for the next milestone.

[Paul Everitt (paul-agendaless)]

I think Chris would prefer seeing if other changes (community tags, marshalling cached queries, adding a second appserver) ameliorate the need for this.

[Chris Rossi (chris-archimedeanco)]

This is a prescription without a diagnosis. We should concentrate on finding specific slow things in Karl and then figuring out why their slow. This will probably mean collaboration with OSI as they report slowness with LiveSearch (for example) that we don't see. It will be tricky but we will need to figure out how and why their experience is differing from ours.

[Christian Theune (ctheune)]

Just as I stumbled over this: we pretty much always do it this way:

1 vm = 1 core = 1 process = 1 thread

Then

- have a load balancer limit 1 request to that one machine.
- have a handful (we use up to 20) of those setups and categorize them by looking at headers and URLs in the load balancer

this is our best setup we have for predictable performance in complex applications right now.

[Tres Seaver (tseaver)]

The ghetto configuration got rolled to staging 2012-04-30, and has been in production since shortly thereafter.