As we know, the android demo of tensorflow is multi-thread. So how can I change it to the single-thread mode?
There's no way to do this from Java right now. A value for intra-op parallelism is automatically picked in local_device.cc matching the number of cores detected on your device. If you just want to test, you could overwrite the value there.
Inter-op parallelism is currently always 1 on mobile -- only one op runs at a time.
More generally in native code intra and inter op parallism can be set when creating your Session object. e.g.:
tensorflow::SessionOptions options;
tensorflow::ConfigProto& config = options.config;
config.set_intra_op_parallelism_threads(num_threads);
Session session = tensorflow::NewSession(options);
This will override the automatically picked value. See benchmark_model.cc for an example.
If you want to set this from Java, you would have to add a parameter to TensorFlowInferenceInterface.initializeTensorFlow().
We're switching to the Java API soon, though, so it will be easier to access the SessionOptions to set the value then.
Related
I am currently working on testing small API in our company and I need to randomly distribute a number of calls on all methods of that API. I am using 5.3 version of JMeter, company security politics, so we do not have newer versions if that matters.
Because number of methods is around 15 my idea right now is supply .properties file to JMeter, which will contain overall number of calls to API, then, through JSR223 sampler in SetUp Thread Group I will set properties with random amount of users in thread. However, I encountered a problem in doing so: I successfully set all properties, but I cannot access them, when calling ___property function in another Thread groups.
Is there any method to set those properties by script and access them through JMeter function?
Edit: Adding the code I am using in SetUp Thread Group to add properties
jmeter_properties.load(new FileInputStream(new File('env.properties')));
def allUsers = jmeter_properties.get('number.of.users') as Integer;
def random = new Random();
def thisUsers = random.nextInt(allUsers);
allUsers = allUsers - thisUsers;
props.put('getProjectById.users', thisUsers);```
I'm not sure whether it's expected behaviour or a bug in JMeter which should be reported via JMeter Bugzilla, but I do confirm that:
Your code is correct
The generated value cannot be referenced either by __P() or by __property() functions calls
However if you use __groovy() function the property is resolved just fine, so if you do something like:
${__groovy(props.get('getProjectById.users'),)}
in the 2nd (or whatever thread group) you will get the outcome you're looking for
Currently, I am using tensorflow estimator API to train my tf model. I am using distributed training that is almost 20-50 workers and 5-30 parameter servers based on the training data size. Since I do not have access to the session, I cannot use run metadata a=with full trace to look at the chrome trace. I see there are two other approaches :
1) tf.profiler.profile
2) tf.train.profilerhook
I am specifically using
tf.estimator.train_and_evaluate(estimator, train_spec, test_spec)
where my estimator is a prebuilt estimator.
Can someone give me some guidance (concrete code samples and code pointers will be really helpful since I am very new to tensorflow) what is the recommended way to profile estimator? Are the 2 approaches getting some different information or serve the same purpose? Also is one recommended over another?
There are two things you can try:
ProfilerContext
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/python/profiler/profile_context.py
Example usage:
with tf.contrib.tfprof.ProfileContext('/tmp/train_dir') as pctx:
train_loop()
ProfilerService
https://www.tensorflow.org/tensorboard/r2/tensorboard_profiling_keras
You can start a ProfilerServer via tf.python.eager.profiler.start_profiler_server(port) on all workers and parameter servers. And use TensorBoard to capture profile.
Note that this is a very new feature, you may want to use tf-nightly.
Tensorflow have recently added a way to sample multiple workers.
Please have a look at the API:
https://www.tensorflow.org/api_docs/python/tf/profiler/experimental/client/trace?version=nightly
The parameter of the above API which is important in this context is :
service_addr: A comma delimited string of gRPC addresses of the
workers to profile. e.g. service_addr='grpc://localhost:6009'
service_addr='grpc://10.0.0.2:8466,grpc://10.0.0.3:8466'
service_addr='grpc://localhost:12345,grpc://localhost:23456'
Also, please look at the API,
https://www.tensorflow.org/api_docs/python/tf/profiler/experimental/ProfilerOptions?version=nightly
The parameter of the above API which is important in this context is :
delay_ms: Requests for all hosts to start profiling at a timestamp
that is delay_ms away from the current time. delay_ms is in
milliseconds. If zero, each host will start profiling immediately upon
receiving the request. Default value is None, allowing the profiler
guess the best value.
My Requirement: I want to capture screen video of tests while running selenium tests.
I am currently using Monte Media Library. But it capture all the actions that is taking place in screen. I want to capture only the test browsers.
Is there a way to do that?
Please help me.
Working solution, without using any extra libraries is to implement your own Recording functionality via TakesScreenshot interface. This is really helpful for HTML5 games automation. You still can run tests in parallel and record what happen per browser/test.
Simple use:
import static openqa.selenium.OutputType.*;
File screenshotFile = ((Screenshot)driver).getScreenshotAs(file);
String screenshotBase64 = ((Screenshot)driver).getScreenshotAs(base64);
The main Thread with the test will remain the same. In second Thread you run this snippet every 5 seconds (or as frequent you want and your machine can keep up) and store the frames in a Queue. So for example you need to keep only last 12 items (last minute). This data structure provides first in, first out (FIFO) operations for add, poll, and so on.
Apache Commons collections 4 has a CircularFifoQueue<> which is what you can use out of the box.
CircularFifoQueue is a first-in first-out queue with a fixed size that
replaces its oldest element if full.
Simple use:
import java.util.Queue;
import org.apache.commons.collections4.queue.CircularFifoQueue;
Queue<Integer> fifo = new CircularFifoQueue<Integer>(12);
fifo.add(1);
fifo.add(2);
fifo.add(3);
System.out.println(fifo);
// Observe the result:
// [2, 3]
Let's say I push new code to the Worklight server for purposes of a Direct Update. Can I allow users to still use the application for a set amount time before they actually have to accept the update or is the application essentially unavailable to them until they download the new code?
If you are developing your application using Worklight 6.2, then you as a developer can take over the entire Direct Update flow and can essentially decide how to handle a received update from the server.
Note that by taking full control, you own the flow end-to-end; the default Worklight framework handling will not be available and the full responsibility is on the developer to ensure the validity of every step.
You can read more about customizing Direct Update, here:
Initial reading, starting slide #14: http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v620/05_06_Using_Direct_Update_to_quickly_update_your_application.pdf
In depth reading: http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.dev.doc/dev/c_customizing_direct_update_ui_android_wp8_ios.html
In your scenario, I think you could probably go in a less extreme way and just do some tweaks before letting the Worklight framework handle the update from the server. Meaning, you could use the example provided in the training module (slide #18 from the PDF above), where you intercept the update:
wl_directUpdateChallengeHandler.handleDirectUpdate = function(directUpdateData,
directUpdateContext) {
... // display message or counter
}
And display a message and start a counter, and when time's up just directUpdateContext.start(); the update.
Worklight 6.1 on both Windows (colleague) and Mac (me), building an a Hybrid app destined for Android device but to speed up development we do initial testing as Mobile Web App in Chrome browser on desktop.
We get a weird symptom that I'm trying to fine-down to a reproducible test case. I think I see different behaviours when stepping in debugger and just letting it run. Want to check whether a certain coding pattern could be the cause of the symptom before I go any further.
Fundamental question: should we wait for the resolution of a promise returned by a JSONSTore request for an action on a collection before issuing another request? more explanation below.
The overall intent is to load some data into the JSONStore, with some intelligent replace/merge action if a record is already present. Pseudo code:
for each record retrieved from back-end
if ( record already present in Store )
do some data merging
replace record
else
add record
The application code actually works like this, just considering the add() case, the problem manifests when the store is empty, all records need to be added
for each record to add
addPromise = store.get().add(record);
listOfPromises.insert(addPromise);
examine the list of promises recording any errors
That is there is no "wait" for add to finish before issuing the next add request. Hence in effect we've initiated a set of adds "in parallel" whatever that might mean in JavaScript in Chrome.
The code appears to run just fine, no errors reported. On android device it works reliably. In Chrome under normal running (no stepping in debugger) we end up with no reported errors but only one record inserted - indeed as though a snapshot of the initial "empty" store had been taken and each add is working on that "empty" copy.
After writing this I'm now pretty convinced that the coding pattern described above is vulnerable to a kind of race and that the better approach is build a list of documents to be added and insert them in a single operation.
A more detailed answer will be coming later, but I now know that this
the coding pattern described above is vulnerable to a kind of race and
that the better approach is build a list of documents to be added and
insert them in a single operation.
is true. In the browser the JSONStore does require that we wait for the result of one request before issuing another one. The recommended approach is
var dataToAdd = buildArrayOfDataToAdd(responseFromServer);
var dataToReplace = buildArrayOfDataToReplace(responseFromServer);
jsonstore.add( dataToAdd ).then( function() { jsonstore.replace( dataToReplace); })