Actually, let me withdraw the question for now.  If I call an unfiltered
(describe-images) on my account I'll get ~27,900 images.  It takes 70
seconds to retrieve them using the Java api
(from clojure).

If I then print (str image) for all those images to a file, that makes adds
another 153 seconds for a total of 223 seconds.  Presumably that's the
normal java toString() method invocation.

If I print out the Amazonica version of it, it takes 195 seconds,
presumably because we're sharing keyword references internally and so
abusing memory less overall (just a wild guess).

So if I do the native calls and cherry pick the information I want (like
the java EC2 CLI does), then I can get the time down significantly.
Otherwise Amazonica is probably doing a reasonable job given what I'm
asking of it.

And, in the wisdom gained department, never do unfiltered (describe-images)
requests if you can help it :-)




On Fri, Mar 28, 2014 at 12:52 PM, Michael Cohen <mcohe...@gmail.com> wrote:

> time ec2-describe-images -a > ec2-cli-images.txt
>
> real  1m26.401s
> user  0m6.551s
> sys 0m1.159s
>
> and writes a 7.5MB file to disk. Note the -a flag, to list all of the
> available public images.
>
> in a repl,
>
> (time (spit "clj-awz-images.txt" (describe-images)))
>
> "Elapsed time: 90258.47 msecs"
>
> and writes an 18MB file to disk containing all the available public
> images.
>
> Am I missing something?
>
> You can also pass a list of filters to the call to narrow the result.
>
>
>
> On Friday, March 28, 2014 7:59:48 AM UTC-7, Dave Tenny wrote:
>>
>> I'm trying to code some amazonica based solutions in a nontrivial AWS
>> environment.
>> I work with many AWS accounts and it isn't unusual to see a thousand
>> instances running on one account, and similar excesses in other types of
>> AWS resources.  So if you're going an ec2-describe-instances (or amazonica
>> equivalent), it needs not to choke in this environment.
>>
>> I like the way amazonica does all the bean marshalling for me so I can
>> express queries simply.  But the returned datasets need to be more
>> pragmatic/performant.
>>
>> The problem for me is that Amazonica doesn't seem up to the task of
>> dealing with queries that return large volumes of data.
>> It has nothing to do with reflection I suspect, and more to do with
>> unwieldy amounts of duplicate information in the result unmarshalling
>> process.
>> The "clojure all the way down" philosophy results of duplicated
>> information and just printing the result to a file takes a long time.
>> If I accidentally let the output go to an emacs cider repl buffer, then
>> things get so wedged up to the point I  may as well kill -9 emacs.
>> (Known cider repl issues here, it isn't all amazonica).
>>
>> For example:  here's how long it takes to run the java based ec2 cli to
>> describe instances on an account:
>>
>> $ time ec2-describe-images >/tmp/ec2-cli-images.out
>>
>> real    0m11.484s
>> user    0m2.564s
>> sys     0m0.129s
>>
>>
>> And here's how long it takes from a 'lein repl' to run the same query on
>> the same account:
>>
>> (time (with-output ["/tmp/clj-awz-images.out"] (println
>> (ec2/describe-images))))
>> "Elapsed time: 194685.552683 msecs"
>>
>> Now the amount of data being printed by the EC2 CLI is of course much
>> different than the output from Amazonica,
>> amazonica is returning everything in gory duplicate map detail, ec2 is
>> not, as evidenced by the relative output sizes:
>>
>> -rw-rw-r--.  1 dave dave 17201290 Mar 28 10:35 clj-awz-images.out
>> -rw-rw-r--.  1 dave dave    99342 Mar 28 10:26 ec2-cli-images.out.11.5s
>>
>> Where the amazonica output starts with:
>> {:images [{:hypervisor xen, :state available, :virtualization-type
>> paravirtual, :root-device-type instance-store,
>> ... and goes on like that with duplicate keywords all the way down.
>>
>> Anyway, my goal isn't to turn amazonica into ec2 cli.  But even the most
>> trivial operations in amazonica (especially the most trivial, i.e. those
>> lacking filters against large data sets), pretty  much whack me left and
>> right
>> with CPU wedged tools and (completely unacceptable) long waits for
>> results.
>>
>> Any suggestions on how to use amazonica in a way where the output is ...
>> different, and minimal/workable?
>>
>> Or am I left with going to another package or writing my own java sdk
>> api's directly?
>>
>> I'm pretty sure the results need to be structures whose relationship to
>> data values is implicit (and not explicit in map keys). I don't see any
>> options with amazonica to change this however.
>>
>> Thanks for suggestions, forgive me if I've missed something obvious.  I'm
>> just trying to see what's out there and at the same time move along quickly
>> enough that I can get some usable tools for work (so I can lose all my
>> python and bash scripts for various interfaces, I want clojure!).
>>
>> - Dave
>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/QCBM_el5_78/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to