Some dynamic flexibility in selecting the type of instances would be really useful

[Emanuele Ziglioli]

Hi everyone,

have been following this group for months but can't recall reading anything related to this: currently the instance size is one big knob while it'd be useful to be able to select a different instance size at runtime. 

Our web site is perfectly served by F1 instances but it runs out of memory of some task queues when iterating over a large number of instances. For that reason only we have to run F2 instances at higher costs.

The type of work we run in task queues really suits MapReduce but the java version has been broken for us for many months now.

Would it be difficult to add a parameter when posting to a task queue to request for a larger instance?

I don't really want to use backends given their bad rep.

Similarly, giving people more choice with regards to what instances to start and when could perhaps solve a large set of problems that people have been complaining about.

If you can't modify the scheduler to suit all possible needs (I can understand it's an impossible goal), just give the ability to write our own schedulers. At the end of the day we pay for what we use and the that usage is capped by the daily budget anyway.

Does it make sense?

Emanuele

[Takashi Matsuo]

Hi Emanuele,

On Tue, Nov 27, 2012 at 3:10 PM, Emanuele Ziglioli <the...@emanueleziglioli.it> wrote:

Hi everyone,

have been following this group for months but can't recall reading anything related to this: currently the instance size is one big knob while it'd be useful to be able to select a different instance size at runtime. 

Our web site is perfectly served by F1 instances but it runs out of memory of some task queues when iterating over a large number of instances. For that reason only we have to run F2 instances at higher costs.

The type of work we run in task queues really suits MapReduce but the java version has been broken for us for many months now.

Would it be difficult to add a parameter when posting to a task queue to request for a larger instance?

I don't really want to use backends given their bad rep.

We're working on this. Please see the last part of 'Optimizing Your Google App Engine App' session in Google I/O 2012:

https://developers.google.com/events/io/sessions/gooio2012/310/

Please see App Engine Servers section of the presentation.

 

Similarly, giving people more choice with regards to what instances to start and when could perhaps solve a large set of problems that people have been complaining about.

If you can't modify the scheduler to suit all possible needs (I can understand it's an impossible goal), just give the ability to write our own schedulers. At the end of the day we pay for what we use and the that usage is capped by the daily budget anyway.

Can you star this issue?

https://code.google.com/p/googleappengine/issues/detail?id=5755

-- Takashi

 

Does it make sense?

Emanuele

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/XM1gBFX-F8sJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
Takashi Matsuo | Developers Advocate | tma...@google.com

[Emanuele Ziglioli]

On Wednesday, 28 November 2012 12:35:03 UTC+13, Takashi Matsuo (Google) wrote:

Hi Emanuele,

On Tue, Nov 27, 2012 at 3:10 PM, Emanuele Ziglioli <the...@emanueleziglioli.it> wrote:

Hi everyone,

have been following this group for months but can't recall reading anything related to this: currently the instance size is one big knob while it'd be useful to be able to select a different instance size at runtime. 

Our web site is perfectly served by F1 instances but it runs out of memory of some task queues when iterating over a large number of instances. For that reason only we have to run F2 instances at higher costs.

The type of work we run in task queues really suits MapReduce but the java version has been broken for us for many months now.

Would it be difficult to add a parameter when posting to a task queue to request for a larger instance?

I don't really want to use backends given their bad rep.

We're working on this. Please see the last part of 'Optimizing Your Google App Engine App' session in Google I/O 2012:

https://developers.google.com/events/io/sessions/gooio2012/310/

Please see App Engine Servers section of the presentation.

Thank you Takashi, so glad to hear!

 

Can you star this issue?

https://code.google.com/p/googleappengine/issues/detail?id=5755

Done :-)

[Nickolas Daskalou]

Hi Takashi,

Is there a Trusted Tester program for App Engine Servers?

Nick

[pdknsk]

If you don't want to use backends, you could use named versions, if
Google allowed to configure per version.

https://code.google.com/p/googleappengine/issues/detail?id=6547

[Andy]

Pdknsk, that's all dynamic backends are: named configurable versions.  When we do a deploy we now do it to the "new" version as well as the backend version.  

[pdknsk]

Well, not exactly, because dynamic backends don't scale and have 15m
cost penalty.

[alex]

As far as I remember min/max/whatever latency configuration options
and other auto scaling stuff works with default versions only. Am I
missing something?

On Wed, Nov 28, 2012 at 7:19 PM, pdknsk <pdk...@gmail.com> wrote:
> Well, not exactly, because dynamic backends don't scale and have 15m
> cost penalty.
>

[stevep]

Reviewed these materials. Leads to a question/input...

Background: Long-ago (cpu-cycles billing era) I committed to using TaskQueues (TQ) to minimize on-line handler latency. So, I am exposed to issues related to unpredictable TQ task start times. (Fortunately to date I have not been affected, but figure it is a matter of time.) Long ago asked that developers be given the option of configuring a high-performance TQ which would not be affected by unpredictable start times. The recent thread on this issue suggests I am not alone in these TQ architecture decisions.

Question: The video covered upcoming changes implementing Application>>Server>>Version architecture enabling developers to control performance settings beyond today's "default version only" setup. Looks great. Can I set up a Server>>Version solely to handle my "high-performance" TQ tasks in such a way that task execution will be more predictable? My hope is that if I setup a version that only received my "high performance" TQ tasks, it will not be affected by the task start variability because it will have nothing else to do but TQ tasks.

Input: If the answer is "No", please consider a App>>Server>>Version yaml setting by which the developer specify a version which will prioritize immediate handling of TQ tasks (i.e. as if the TQ task was an on-line handler call).

If I have mis-interpreted the video: My apologies and please forgive me wasting your time.

Thanks,

SteveP

[Andy]

Setting the "instances" option in the backends.yaml allows it to scale up that value.  15m penalty is well worth it because 99% of our traffic fits in an F1 but we had to run F2s previously to allow the 1% of the tasks to succeed.  As a result our costs are roughly half as much.  

[Emanuele Ziglioli]

Thank you for the suggestion,

I'm not sure if I understand, which one these two:

1. You use one backend instance to cater for larger memory/speed requirements

2. You use one backend instance to spin multiple F1 and/or F2 task queues because backends allow you to

[Andy]

You use one backend instance to cater for larger memory speed requirements.  Depending on throughput requirements you can configure the instances property to run more than one instance in that higher class.

Step 1.  Configure backends.yaml

backends:

- name: medium

  class: B2

  instances: 1

  options: dynamic

Step 2. Enqueue a task with target (using the python defer library in this example):

defer(doSomethingBigger, _queue='some-queue-for-big-stuff', _target='medium')

Step 3. Profit

[Brandon Wirtz]

Except that if you need it to go to more than 1 you stop getting profit, and get suffering.

--

You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/uGOolhR5ChYJ.