Hello all,
after the first embarrassing numbers of the Golang runtime that made me hurry
to fix performances :)), here I provide the updated numbers of action-loop
based runtimes compared with the current ones. Those numbers can vary slightly
from one run to another (for example I discovered it
Hi,
in the past we divided the invokers into blackbox and whitebox invokers.
This has the effect that one of these two types could be overloaded while
the other type still has free capacity.
Does anyone see issues on using every invoker for everything?
Or does anyone see any action items that nee
Dear whiskers.
I`ve just submitted the proposal for the next version of Autonomous
Container Scheduler.
https://cwiki.apache.org/confluence/display/OPENWHISK/Autonomous+Container+Scheduler+v2
We(Naver), already implemented the scheduler based on that proposal and
it's almost finished.
It's not al
I think it would be a mistake to blindly merge two container pools - docker
actions as run today are pulled as needed and can take a long time, they’re
subject to different kinds of attacks, and can affect performance of other
tenants (higher noisy neighbors).
If you want to allow more overlap
Thanks Michele for looking into this
The numbers look great !
I will review the PR soon
-- Carlos
On Wed, Nov 28, 2018 at 5:25 AM Michele Sciabarra
wrote:
> Hello all,
>
> after the first embarrassing numbers of the Golang runtime that made me
> hurry to fix performances :)), here I provide t
By configuration you can have different combinations.
Blackbox actions on blackbox invoker only, and regular actions on normal
invoker types only (ie. today)
Blackbox actions on blackbox invoker only, and regular actions on any
invoker type
Any actions on any invoker type
On Wed, Nov 28, 2018 a
Rodric Rabbah wrote on 11/28/2018 07:09:12 AM:
>
> I think it would be a mistake to blindly merge two container pools -
> docker actions as run today are pulled as needed and can take a long
> time, they’re subject to different kinds of attacks, and can affect
> performance of other tenants (highe
Hi,
I am trying to install an all-in-one OpenWhisk on an Ubuntu VM that is
connected to a pure private IPv6 network. I am using the instructions in
the below README file:
https://github.com/apache/incubator-openwhisk/blob/master/tools/ubuntu-setup/README.md
The VM has internet access and can r
Hi,
I have a PR (
https://github.com/apache/incubator-openwhisk-catalog/pull/268) ready to
review with the following list of changes:
1. Added Wskdeploy manifests for all the packages in the catalog.
2. Switched Travis builds to use wskdeploy instead of the shell scripts so
that the existing te
Hi -
We haven't heard any feedback on this, so will plan to merge this change today.
Thanks
Tyson
On 11/14/18, 6:48 PM, "Andy Steed" wrote:
Hello Whiskers!
I wanted to bring up a potentially breaking change to existing
functionality for the KindRestrictor. Given how recent
Thanks for the update - will review the PR again.
On Mon, Nov 26, 2018 at 9:26 AM Christian Bickel wrote:
> Hi Rodric,
>
> thanks a lot for your feedback. I changed my PR to use the quota instead of
> switching it off completely.
>
> Now the controller checks, how many activations have been writ
Thanks for sharing Dominic. I'll need to read this slowly to understand it.
It does look like a bit of the proposal you've discussed in the past with 1
topic per action name (per namespace). Have you seen this scale in your
production to thousands of topics?
-r
On Wed, Nov 28, 2018 at 5:59 AM Dom
Dear Rodric.
We`ve just started benchmarking of the scheduler with a variety of
scenarios.
I will come with more results.
If you ask that because of scalability of Kafka, I have considered Kafka as
a very scalable solution.
Linkedin announced that they are utilizing a huge Kafka cluster.
https:/
>
> 1100+ Kafka brokers, over 31,000 topics
am i reading this right, as this seems like an unhealthy ratio. a new
broker for every 30 topics? so i must be misinterpreting the numbers...
On Wed, Nov 28, 2018 at 10:18 PM Dominic Kim wrote:
> Dear Rodric.
>
> We`ve just started benchmarking of th
Hi Dominic,
>From various docs it appears that there are 2 aspects which are impacted by
large number of topics (or partitions) 1) #partitions/#brokers and 2)
zookeeper. With lots of topic Zookeeper may become a bottleneck.
However I like the better throughput guarantees with such an approach and
15 matches
Mail list logo
