I tried to translate a big IFC file (150mb) for the veiwer and it took around 15 minutes only the translation without the uploading part. So is such translation time normal and can it be done something about it? I am currently using the free credits only for testing. Is there a performance increase with the paid credits?
The /modelderivative/v2/regions/eu/designdata/job is used with the advanced conversionMethod:modern.
No, there is no performance difference between trial and paid accounts. Forge dev account with a valid trial plan can use full Forge features as paid one as I know.
What happened after submitting a translation job?
After submitting a translation request and it returns success, it means that your translation request is sent to our service and has been put into the translation queue successfully. It doesn't mean that your model will be processed by our service immediately.
Instead, you have to line up! Since our service resources are limited and shared worldwide, you will need to wait for enqueued IFC translation jobs from other Forge users completed, and then our service will start to process yours. Therefore, waiting for 15mins is not slow from my perspective.
Related
The base url for posting a Design Automation workitem is
https://developer.api.autodesk.com/da/us-east/v3/workitems
which points to a US east coast location for the server.
Several other Forge API's have a way to specify that they should be handled by European servers (both by adding the region to the URL and by options specifying which region the request should be handled in)
This possibility seems to be missing for the Design Automation API.
Is this correct and is this API currently limited to only a single USA server?
If not, is there documentation available where I can find how to direct a workitem to a European server?
I am asking because we are running Inventor design automation jobs from a website and these typically take 45 to 55 seconds to complete from start to displaying the modified design. However, occasionally a task takes 2 to 4 minutes and I am trying to find if this could be caused by a congested server queue. If there is more than one server I can try to run the same job on different servers and at different times of day to see if there is a commonality between these occasional delays.
Currently Design Automation is only available in us-east region.
However, occasionally a task takes 2 to 4 minutes and I am trying to find if this could be caused by a congested server queue.
The [GET] workitems/:id endpoint returns various statistics. You can derive the information about how long your workitem spent in the queue by subtracting timeQueued from timeDownloadStarted.
"stats": {
"timeQueued": "2022-03-28T12:34:18.3289895Z",
"timeDownloadStarted": "2022-03-28T12:34:18.5377785Z",
"timeInstructionsStarted": "2022-03-28T12:34:19.6206329Z",
"timeInstructionsEnded": "2022-03-28T12:34:36.1960527Z",
"timeFinished": "2022-03-28T12:34:36.2611905Z",
"bytesDownloaded": 106
},
While I see some benefits in hitting the server which is closer to your geographical location (which is not possible for Design Automation at this point) those benefits would not include much of an improvement in the workitem processing time. You are today indeed reaching to "one" server in the US, but your workitems are being processed by several computers in the background.
I have a Revit file around 200MB. I am using forge SDK and below endpoint to extract manifest.
https://forge.autodesk.com/en/docs/model-derivative/v2/reference/http/urn-manifest-GET/
However, process of extracting manifest is taking a HUGE amount of time, which is longer than 30 minutes. How can I shorten this period and prevent timeout issues? Is there any configuration to extract manifest of large files?
SDK version: Assembly Autodesk.Forge, Version=1.9.0.0
Sometimes it can happen that you submit a conversion job at a moment when there are many other jobs queued, and the system hasn't auto-scaled up to the increased load yet. It could also be an issue with pathological designs which might be causing the extraction to take an unusual long time to process.
If the issue persists, please consider sharing one of your designs (confidentially - we would not share it with anyone outside of Autodesk) via forge (dot) help (at) autodesk (dot) com so that we could debug the translation on our end.
I am using Forge design automation function in the project.
I checked the cost at https://forge.autodesk.com/pricing.
It is said that 6 credits are consumed per hour.
I tested credit consumption per execution once in my project.
Two credits were consumed for one run.
In my project, the work lasts about 30 seconds, but I don't know why 2 credits are paid.
Please tell me how to calculate credit consumption.
The tooltip on the pricing page says:
Every second of processing Work Items (including file transfer time between systems) submitted through the Design Automation API is included in the number of processing hours.
Since you haven't provided any details it's hard to say, but please note that downloading of input files and uploading of output files is also included in the processing time.
What kind of task did you try and run in the Design Automation service? Was it perhaps inputting or outputting some large design file?
I run several reconstructions per day using the ReCap API and I would like to know if there is a way to identify the number of cloud credits consumed by each of them. Is there a way to check this, is it linked to the photoscene ID?
- I try looking at the Usage Analysis and it adds up all my credits consumed per day.
- The GET photoscene details end point gives me just the aws_hourly_rate.
Unfortunately not right now but we’ve got internal APIs for such purposes and they could be released for public access in the near future. Stay tuned to our Forge Blog for announcements.
I am encountering some very long response times from Exchange Online called via the EWS Managed API 2.0 in C#. I suspect I am being throttled, but I cannot find anything that lets me prove this in the Admin portal for my O365 account. I have seen in some search results that using PowerShell you can see messages indicating "micro delays" have been applied, but I'm stuck in C#/EWS, so my question is: is there anything I can look at coming back in the responses to my EWS calls that can identify if these micro delays have been applied? BTW, response times are very close to the 100 second timeout time, which is killing my code.
Thx,
Paul
100 Seconds ins't a micro delay, micro-delays are milliseconds(capped at 500 ms) and are more aimed at delaying a large volume of requests. (eg if an app is going to may 100 sequential requests a microdelay would spread the load of those request out over a greater time by punishing the app more and more and that would lower the resource load on the server). One request taking 100 seconds to fulfill is probably more to do with the request itself. Eg overuse of search filters or overcomplex search etc which my also impact throttling or if your using batching each request withing the batch could have a micro-delay applied.
EWS doesn't return metrics of throttle usage (the new REST API does give a little more information back in this regards). What you need is access to the EWS logs which has that information. Each Exchange request the EWS Managed API makes has and Client Requestid to help correlate the request to log entry there more detail in https://msdn.microsoft.com/en-us/library/office/dn720380(v=exchg.150).aspx