Thanks, guys! I really appreciate your input! On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe <s...@stfx.eu> wrote:
> > > > On 26 Jun 2018, at 15:52, Norbert Hartl <norb...@hartl.name> wrote: > > > > > > > >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe <s...@stfx.eu>: > >> > >> > >> > >>> On 26 Jun 2018, at 15:24, Norbert Hartl <norb...@hartl.name> wrote: > >>> > >>> > >>> > >>>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov <lisper...@gmail.com>: > >>>> > >>>> Does anyone use Pharo for Miro services? I heard about Seaside and > Teapot, just was wondering if Pharo can handle multiple simultaneous > requests and if it can, where it reaches the limit. > >>> > >>> I use it extensively. I use Zinc-REST package to offer services. The > answer how much it can handle in parallel is hard to answer. For this you > need to tell what you are about to do. But a rule of thumb is not to exceed > 5 parallel tasks that are working at the same time. But a lot of tasks have > wait times while accessing another HTTP service, a database, a filesystem > etc. For this you can easily go up to 10 I guess. > >>> > >>> But these numbers are more of a gut feeling then something scientific > >>> > >>> Norbert > >> > >> A single ZnServer instance on a single image can handle thousands of > requests per seconds (local network, very small payload, low concurrency). > On a modern multi core / multi processor machine with lots of memory you > can 10s if not 100s of Pharo image under a load balancer, provided you > either do not share state or use high performance state sharing technology > - this is the whole point of REST. > >> > >> Of course, larger payloads, more complex operations, real world > networking, etc will slow you down. And it is very easy to make some > architectural or implementation error somewhere that makes everything slow. > As they say, YMMV. > >> > > > > I meant it regarding what a single image can do. And it can do thousands > of requests only if there is no I/O involved and I doubt this will be a > very useful service to build if it does not any additional I/O. Still I > would try not to have more than 5 req/s on a single image before scaling > up. The only number I can report is that 2 images serving 30 requests/s > while using mongodb are not noticable in system stats. > > > > Norbert > > That is what I meant: it is an upper limit of an empty REST call, the rest > depends on the application and the situation. If your operation takes > seconds to complete, the request rate will go way down. > > But with in memory operations and/or caching, responses can be quite fast > (sub 100 ms). > > >
