Concurrency in Sympy

[Paul Royik]

How many concurrent instances can Sympy handle?

I.e, how many people can simultenously access diff function?

[Joachim Durchholz]

Am 12.03.2015 um 13:17 schrieb Paul Royik:
> How many concurrent instances can Sympy handle?
>
> I.e, how many people can simultenously access diff function?

Everybody is running their own copy of SymPy, so the concurrency is at
the operating system level and the only limit is machine resources.

diff never showed up as particularly resource-consuming, so it's not
limited beyond the number of terminal sessions the machine can handle.
(Integrating can be different, heuristic approaches like Meijer can
easily tie up a processor core for an hour.)

[Paul Royik]

Can you explain more deeply concerning integration?

How many people can access integration simultaneously?

[Joachim Durchholz]

Am 12.03.2015 um 14:42 schrieb Paul Royik:
> Can you explain more deeply concerning integration?
> How many people can access integration simultaneously?

Can you explain what scenario you mean?
I.e. how many people accessing SymPy via what means on what machine(s)?

I suspect a misunderstanding somewhere, but I don't have enough context
to decide where.

Regards,
Jo

[Paul Royik]

I'm running my site under mod_wsgi+apache.

How many people simultaneously can calculate integral?

I experience problems with memory limit and need to adjust number of threads/processes/workers.

[Joachim Durchholz]

Am 12.03.2015 um 17:39 schrieb Paul Royik:
> I'm running my site under mod_wsgi+apache.
> How many people simultaneously can calculate integral?
> I experience problems with memory limit and need to adjust number of
> threads/processes/workers.

Ah, now I understand.

Integration can take large amounts of memory - I have seen footprints
over 4 GB for a single integral, and I doubt that that's the limit.

I'm no authority on the subject, but AFAIK such things happen when the
integrand is "difficult", i.e. the algorithms in SymPy do not find the
right solution quickly.

I think the best you can do is to impose a limit on how much resources a
web request may take, and if the process exceeds them, kill it and serve
a page with a message saying that the formula was too difficult
(possibly with some tips how to make the formula easier, or a link to
the appropriate pages in the SymPy documentation).

[Paul Royik]

But if integral is "easy" (take not much memory) is number of people is restricted only by available memory? Can Sympy serve as much as memory allows?

[Joachim Durchholz]

Am 12.03.2015 um 21:14 schrieb Paul Royik:
> But if integral is "easy" (take not much memory) is number of people is
> restricted only by available memory? Can Sympy serve as much as memory
> allows?

That depends on how many SymPy processes mod_wsgi sets up.
I have no idea how mod_wsgi works, so I can't say much about that.

It's likely configurable.

Also, it's likely a good idea to have a separate SymPy process per web
request, simply to keep sessions of different users separate.
In that case SymPy can indeed serve as much as memory allows.

[Paul Royik]

That's what I asked.

How to configure sympy?

[Joachim Durchholz]

Am 12.03.2015 um 21:48 schrieb Paul Royik:
> That's what I asked.
> How to configure sympy?

SymPy does not manage multiple processes at all, it's a single-threaded
application.
You'd have to look in mod_wsgi if you want to allow multiple instances
of SymPy to run in parallel.

[Paul Royik]

Thank you will look.

[Peter Brady]

The latest release of sympy uses an LRU cache to limit memory usage. The days of a 4GB integral should be over. The size of the cache can be controlled via the environment variable SYMPY_CACHE_SIZE.

[Sudhanshu Mishra]

Hi Paul,

In a normal configuration apache keeps  ~7 instances alive. When there are more concurrent users than this number, apache forks more processes. The number of concurrent users will be limited when apache fails to fork a new process i.e. no more memory is left. mod_wsgi and SymPy has nothing to do with it.

I would suggest you to use HAProxy and distribute your app over multiple instances or you can use a really high end server.

Regards
Sudhanshu Mishra

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b827770b-698e-479d-8439-5ac46ac68771%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joachim Durchholz]

Am 13.03.2015 um 15:49 schrieb Sudhanshu Mishra:
> Hi Paul,
>
> In a normal configuration apache keeps ~7 instances alive. When there are
> more concurrent users than this number, apache forks more processes.

More or less correct.
Most Apache configurations are not "normal" in this sense though; number
of processes is one of the first things admins tweak.

> The
> number of concurrent users will be limited when apache fails to fork a new
> process i.e. no more memory is left.

In practice, I wouldn't let Apache fork until it cannot fork anymore.
Except, maybe, on a machine that runs nothing but Apache processes, but
usually you want Apache to be able to start helper processes, and that
wouldn't work anymore if Apache can't start a new process.

> mod_wsgi and SymPy has nothing to do
> with it.

SymPy has nothing to do with it, true.

mod_wsgi has its own process pool though. (This is typical for any
scripting modules in Apache.)
You can configure number of processes and number of threads.

> I would suggest you to use HAProxy and distribute your app over multiple
> instances or you can use a really high end server.

That's what one would do if the machine is indeed overloaded, yes.
However, before you do that, you need to identify the bottleneck. If
Paul's server is in the standard configuration for mod_wsgi, he might be
encountering 16 concurrent requests and mod_wsgi won't handle more than
15 at a time; other potential bottlenecks are CPU load, network load,
memory pressure, or something entirely different.

Blindly throwing more hardware at the problem is not really a
replacement for finding out what the actual problem is.
Paul should really ask a competent Apache administrator about what's
going on.