[Pharo-users] Microservices using Pharo

Andrei Stebakov lispercat at gmail.com
Tue Jun 26 14:32:10 EDT 2018


Thanks, guys! I really appreciate your input!

On Tue, Jun 26, 2018, 11:16 Sven Van Caekenberghe <sven at stfx.eu> wrote:

>
>
> > On 26 Jun 2018, at 15:52, Norbert Hartl <norbert at hartl.name> wrote:
> >
> >
> >
> >> Am 26.06.2018 um 15:41 schrieb Sven Van Caekenberghe <sven at stfx.eu>:
> >>
> >>
> >>
> >>> On 26 Jun 2018, at 15:24, Norbert Hartl <norbert at hartl.name> wrote:
> >>>
> >>>
> >>>
> >>>> Am 26.06.2018 um 14:52 schrieb Andrei Stebakov <lispercat at 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).
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20180626/a740147e/attachment.html>


More information about the Pharo-users mailing list