IronWorker Environment & Stack Information

Table of Contents

Runtime Environments

Below you can see the pre-installed versions of languages/tools in the IronWorker environment in different stacks.

To use, add ‘stack “stack_name”’ to your .worker file. Example:

runtime "ruby"
stack "ruby-2.1"
exec "hello_worker.rb"

Stack nameLanguage/Tool VersionOperating SystemDeb packages
default*Ruby-1.9.3p194, java-1.7, scala-2.9, mono-2.10, php-5.3, node-0.8, python-2.7Ubuntu 12.10Packages
ffmpeg-2.3ffmpeg-2.3, GPAC-0.5.1, php-5.3, node-0.10, ruby-1.9.3p0, python-2.7, x264-0.142.xUbuntu 12.04.5Packages
go-1.4Go 1.4Ubuntu 14.04
java-1.7Java 1.7.0_51 OpenJDKUbuntu 12.10Packages
java-1.8Java 1.8.0_20Ubuntu 12.04.5Packages
mono-3.0Mono JIT 3.0.Ubuntu 12.10Packages
mono-3.6Mono JIT 3.6.Ubuntu 12.10Packages
mono-2.10Mono JIT 12.10Packages
node-0.10Node.js 0.10Ubuntu 12.10Packages
php-5.4PHP 5.4.26Ubuntu 12.10Packages
php-5.5PHP 5.5.10Ubuntu 12.04.5Packages
python-2.7Python 2.7.6Ubuntu 12.10Packages
python-3.2Python 3.2.5Ubuntu 12.10Packages
ruby-1.9Ruby 1.9.3p194Ubuntu 12.10Packages
ruby-2.1Ruby 2.1.0p0Ubuntu 12.10Packages
scala-2.9Scala 2.9.2Ubuntu 12.10Packages

*default stack loading when a "stack" option is not declared in .worker file

The operating system and version information is provided for completeness and transparency. We recommend, however, you avoid binding your workers to specifics of the OS as much as possible.

Note: It may be possible to update the language by adding related deb packages to your worker although you should go this route only if necessary. Use of earlier versions, especially major versions, may run into difficulties.

Installed Linux Packages

IronWorker contains several popular Linux packages as part of the standard worker environment.

PackageFull NamePurpose
ImageMagickImageMagick Image ProcessingImage processing
FreeImageThe FreeImage ProjectImage processing
SoXSound eXchange LibrarySound processing
cURLClient URL Request LibraryURL file processing

These are included because they are common binary libraries. Other binary libraries and files can be included as part of your worker code package, though you’ll first need to compile them to target Linux x64 architectures.

If you don’t see what you need here, please contact us and tell us what you’re looking for. If it’s a common/popular package, we can certainly look to include it.

Maximum Data Payload

The following is the maximum data payload that can be passed to IronWorker. A data payload that exceeds this size will generate an error response from the API.

Maximum Data Payload: 64KB

Tip: We recommend that you avoid sending large payloads with your workers. Instead use a data store to hold the data and then pass an ID or reference to the worker. The worker can grab the data and then do its processing. It’s more efficient on the API as well as better in terms of creating atomic/stateless processing.

Memory per Worker

The standard worker sandbox environment contains a certain amount of accessible memory. This amount should be sufficient for almost all workloads. We are working on a super worker environment that would allow greater memory allocations. Please contact us if you have specific needs here.

Memory per Worker: ~ 320MB

Tip: We recommend distributing workloads over multiple workers—not only for better resource management, but also to take advantage of the massive concurrency enabled by a cloud worker system.

Local Disk Space per Worker

Each worker task has local disk space available to it for use on a temporary basis while the worker is running. You have full read/write privileges to create directories and files inside this space, and can perform most ordinary file operations. This directory is used as the current working directory (“.”) when executing your workers.

Local Disk Space: 10GB

Maximum Run Time per Worker

There is a system-wide limit for the maximum length a task may run. Tasks that exceed this limit will be terminated and will have timeout as their status.

Max Worker Run Time: 3600 seconds (60 minutes)

Tip: You should design your tasks to be moderate in terms of the length of time they take to run. If operations are small in nature (seconds or milliseconds) then you’ll want to group them together so as to amortize the worker setup costs. Likewise, if they are long-running operations, you should break them up into a number of workers. Note that you can chain together workers as well as use IronMQ, scheduled jobs, and datastores to orchestrate a complex series or sequence of tasks.

Priority Queue Management

Each priority (p0, p1, p2) has a targeted maximum time limit for tasks sitting in the queue. Average queue times will typically be less than those listed on the pricing page. High numbers of tasks, however, could raise those average queue times for all users. To keep the processing time for high priority jobs down, per user capacities are in place for high priority queues. Limits are on per-queue basis and are reset hourly. High priority tasks that exceed the limit, are queued at the next highest priority. Only under high overall system load should queue times for tasks exceeding the capacity extend beyond the initial targeted time limits. Usage rates will be based on the actual priority tasks run on, not the priority initially queued.

Priority Capacity Per Hour Per User
p2 100
p1 250

Maximum Scheduled Tasks per Project

The following is the default number of scheduled tasks. It should be sufficient for even the largest projects. If you would like this number increased, however, please feel free to contact us.

Max Scheduled Tasks: 100

Tip: A common mistake is to create scheduled jobs on a per user or per item basis. Instead, use scheduled jobs as master tasks that orchestrate activities around sets of users or items. When scheduled tasks run, they can access databases to get a list of actions to perform and then queue up one or more workers to handle the set. View the page on scheduling for more information on scheduling patterns and best practices.

Scheduled Task Frequency

Tasks can be scheduled to run every N seconds or more specifying N using the run_every parameter and where N > 60. (The minimum frequency is every 60 seconds.)

Note: A task may be executed a short time after its scheduled frequency depending on the priority level. (Scheduled tasks can be given a priority; higher priorities can reduce the maximum time allowed in queue.)

Security Groups and IP Ranges

IronWorker provides an AWS security group and IP ranges in the event users want to isolate AWS EC2, RDS, or other services to these groups/ranges.

EC2 Security GroupAccount IDSecurity Group String