-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
benchmark for CASTf90 analogs process #48
Comments
Computer: 4 CPUs, system fedora |
Case1 |
you can use owslib to call the process directly (without the phoenix gui or birdy comand line). There is an example as ipython notebook: https://github.com/bird-house/flyingpigeon/blob/master/notebooks/WPS_analogs.ipynb You can call the process async (default) or synchronously. In the notebook example async took 27 secs and sync 18 secs. I have added some measuring in the analogs process: https://github.com/bird-house/flyingpigeon/blob/master/flyingpigeon/processes/wps_analogs.py In the log you can see duration for each step. Make sure you have debug log mode enabled:
See the log with the performance:
In my case it looks like this:
So ... the time goes into get_input_data preparation. |
Well, Castf90 was already writing the time when it starts (after data preparation) and the time when it ends into the log file, so the times I indicated are WITHOUT data preparation, which is an issue apart. Thanks for the notebook! |
so 14 secs is the time we should expect here. If you only measure the execution time of castf90 in the wps process ... it should be the same. I don't understand how it can be minutes ... Do we need to set some environment variables? One could check only this code part in the process ... If you run the wps service then use owslib with sync mode ... (birdy and phoenix only use async mode). Can i reproduce this use case on my laptop? Do you have the input parameters? |
execution time: Well yes I agree it should, but it isn't. That's the issue. environment variables: Since it already occupies all my 4 CPUs, for me it was not necessary to set environment variables. If it doesn't, one may set OMP_NUM_THREADS=4 (or what ever the number of threads to use...) I tried sync mode using laptop: of course you can. inputs=[("dateSt",'2013-01-01'),("refEn",'1995-12-31')], the default ones for the other parameters for case 1 and inputs=[("dateSt",'2005-01-01'),("refEn",'1995-12-31')], for case 2. What exactly do you mean by checking only the code part in the process? |
PS: the numbers are for case1 |
i have run use case 1 and wps-call took 45 secs for the castf90 call. Then i took the produced config file and the same preprocessed input data and have run the conda script on the command line ... and it took 42 secs. So ... is there something wrong with the config file or the preprocessed input data? @nilshempelmann |
i've updated the notebook with both use cases: https://github.com/bird-house/flyingpigeon/blob/master/notebooks/WPS_analogs.ipynb async mode is better in this long running case ;) |
ok, aparently I messed up something with the direct conda package call. I now have 42s as well for case 1, which means everything is ok with the wps, but the conda package is slow compared to the classic command line castf90. |
so we need to update the cast conda package ( #37 ) and find out how to improve the performance of it. As a workaround one can use the manual installation of the castf90 ... |
CASTf90 seems to be very fast. |
No description provided.
The text was updated successfully, but these errors were encountered: