Subscribe by Email

Your email:

Current Articles | RSS Feed RSS Feed

10Gb networking and DAM

Posted by Rob Pelmas on Wed, Jun 03, 2009 @ 08:56 AM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

We're a bunch of performance geeks here. We've been tweaking blocksizes, stripe, and interleave settings on disk since SGI first gave you access to 'em. Tuning and re-tuning SWAP size, location, type is in our blood. A few percentage points here, double digit gains there, all without more capex. Gotta love it.

Now, anytime a paradigm shift in technology comes out there's a steep cost differential to it, right? 10Gb networking had only a tiny little blip of time when it was out of reach of the masses, which is a refreshing change. You can kit out most servers with a card, an acceptable managed switch with a 10Gb port or two, for a very reasonably cost.

Why go to 10? Our desktops have had Gb cards for what seems like forever, and very fast CPUs. With just a couple 'power' users you could swamp the networking capabilities of a server. Of course, a handful of years ago disks could only cough up 150Mb/sec or so of sustained data, so network tended to not be the gating factor in server  performance. Modern disk starts at well over 300Mb/sec, and if you stripe or otherwise use some common sense design principles you can achieve multiples of that.

 Xinet and NAPC both use the 1 to 6 rule for users and performance: with 6 retouchers (or 'power' users), you can assume 1 of them will be accessing the server at one time. 12=2, 18=3. It's a rough rule of thumb, but one that seems to stand up over time. 12 heavy hitters can thus drain 120Mb/sec out of a server, which is the better part of 2 1Gb cards bonded together. Add in the other users, doing layout, OPI printing (yep, some folks still use an OPI workflow), and Portal access, you've got a saturated pipe. 10gb gives you a good 800mb/sec of access speed, which will sate all but the most demanding organizations needs for data.

Next of course, we can talk about teaming 10Gb interfaces! (insert evil chortle of delight here).

 


2 Comments Click here to read/write comments

Xinet Automation in the Command Line

Posted by Robert Sullivan on Wed, Apr 15, 2009 @ 08:52 AM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 
Some people actually prefer to work from the command line in a terminal window.
I know! Can Ya' believe it!
There are somethings that just aren't in the GUI and there are some things you
can just do faster in a terminal window. That is assuming you can type faster
than me.

I had a client call in looking for a way to create a series of "Move Actions"
but wanted to do it as a batch somehow. I couldn't get him a 'batch create' for a
WebNative Venture action, but... command line creation fit the bill.

The idea was for remote users to have an Uploader Application and one of the
mandatory data fields was the client name. The Trigger set would do a 'Compare Action'
and then call a Move to-client-name, within the folder structure. So it's going to be
an automated filing system with Triggers for uploaded assets.

In the folder path: /usr/etc/webnative/actions/
are all of the default Venture action categories, (copy, email, move...) and any
custom action categories we can create ourselves. Within each specific category folder
are the scripts for that action and a settings folder that has a config file for each
action we create.

Here is a sample move action called: "Acme Widgets Incoming"

If I look at that setting from the command line it looks like this:
# cat "Acme Widgets Incoming"
[base]
desc=File asset in client folder Acme
[arg0]
value=/Volumes/Raid/Studio/Acme_Widgets/Incoming
[arg1]
value=O
#
It's pretty simple once you compare the GUI to the code settings.
desc is the description of the action
arg0, value, is the destination path we want to move the asset into.
arg1, value=O, is the 'Overwrite' selection.
This value could be 'A' for 'Append Unique Number' or 'F' for Fail
You just need to understand the argument options and the code translation. Now obviously
the different action categories will have other argument options, you just need to review
each one to know the 'value' to assign.

So back to my client's need to create multiple actions quickly. Consistency in the folder
structure and nomenclature is part of the key. All we do is create one 'master' move action
in the WebNative browser window. "Acme Widgets Incoming"
From the command line copy the master to the next client name and then edit the value path.
Done.

In the terminal window navigate to the action settings folder.
   cd /usr/etc/webnative/actions/move/settings
Copy paste the master setting to the new client name.
   cp "Acme Widgets Incoming" "Spacely Sprockets Incoming"
Edit the new setting "Spacely Sprockets Incoming" for the correct path-to-folder.
     value=/Volumes/Raid/Studio/Acme_Widgets/Incoming
becomes:
     value=/Volumes/Raid/Studio/Spacely_Sprockets/Incoming
 
If you need to create a lot of actions that do the same thing to unique paths, this is the
quickest way to go. The command line is not for everybody but for those that know their way
around, its another powerful way to work with the Xinet Venture database. My client now has over
300 move actions, to file uploaded assets into the correct client folder automatically.
All done by lunch time..!
So what's for dessert?

-Sully 

1 Comments Click here to read/write comments

Push the Xinet Envelope

Posted by Robert Sullivan on Mon, Mar 23, 2009 @ 09:08 PM
Share on Facebook Facebook | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 
So here I go a blogging away. I'm not too sure of how to start because usually I'm following an agenda of some kind, or a question to start with. Someone has a problem or a challenging workflow to configure. Blogging is more free flowing, I guess... We'll see.
 
I do a lot of training for new clients and there is so much information to absorb that they can easily become overwhelmed & overloaded. As they get use to the system they'll Venture further (pun intended) and start looking for cleaner ways to use their new system. But not many will make that leap and really push the limits of what they can get out of it early on. There's way more power under the hood.
 
The problem I find so often is that people have an idea of what the server can do but aren't sure how to get there. And that stops them. At that point, the thing that most often drives them is a client request, or the boss (every one has a boss...) saw a Webinar about some cool widget and wants it created. Is it done yet?
When I was in Printing, I worked for a guy that always said,
"If I wanted it tomorrow, I'd be asking for it then. I want it now!"
 
Then the calls start coming in in earnest. Which is great for me because now I have something to dig into. A new challenge. But I wonder how do we get people to push the envelope before they get the push themselves? It's training, and it's knowledge. NAPC runs Webinars' all the time on different applications, from FullPress, the Venture database, to Dalim Dialogue or the Xinet Uploader. Sharing the knowledge is driving the train here!

Do you have an idea for a Webinar you'd like to see. Tell us. Got an idea for any Trigger automations, let me know. If you can conceive of it, we can build it... well, I'm looking for the stuff we can build out-of-the-box. Custom stuff comes later.

-Sully

0 Comments Click here to read/write comments

All Posts