Chris, With only fedex ground, it takes ~4 seconds.
If i bump it up one more (add 2 day), ~7 seconds
Add one more (express), ~10.29 seconds.

I'm assuming since the standard satchmo checkout has the payment and
shipping tied together, you are using the payment/shipping form to get the
dynamic rates?  There isn't any other 'simple' form that your using that
may make it quicker?

(i created a simple form since i want to get rates anywhere on the site
with the current cart items, not just at checkout, but that still didn't
make a difference).

The biggest thing I've noticed between fedex and usps is that even if i
have verbose logs unchecked, the log file is filled with thousands of lines
of fedex request.  That can't be good for it speed.
Does this sound normal?

In regard to using the contact information, I'm about 99% sure that
fedex/usps only uses zip code & country to get rates, so having more than
that available wont be of any benefit.  I'm not sure about UPS though.

thanks!
Dave

On Tue, Nov 29, 2011 at 8:30 PM, Chris Moffitt <ch...@moffitts.net> wrote:

> Dave,
>
> Thanks for installing and checking and verifying it works fine.
>
> As far as the performance issues, I have a couple of questions:
> - How long does it take if you just have Fedex Ground enabled?
> - Look in your satchmo.log file and see if there appear to be any big time
> lags in the time stamps
>
> Regarding the contact object, I think the original thought is that you
> might want more info than just a zip code to calculate costs. Since I
> wasn't sure about all the possible API's, I used a contact object. If
> someone wanted to run a query with just a zip code, they could create a
> dummy contact and call it. I'm open to other ideas though.
>
> -Chris
>
>
> On Tue, Nov 29, 2011 at 7:14 PM, Dave Brown <wakeb0a...@gmail.com> wrote:
>
>> Chris, I installed it and it seems to work fine.
>>
>> A comment in general about the shipping methods:  It seems strange to
>> have the calculate() method depend on a contact object being passed in.
>> For example if a user wants to pop in a zip code and get back the shipping
>> rates for the current items in the cart before proceeding to checkout, it
>> can't be done without hacking the modules.  As far as i know (atleast for
>> fedex and USPS), you only need the zipcode and the country... so why
>> require there be a contact object?
>>
>>
>> Back to fedex:
>> I actually haven't been able to implement fedex on my site because I
>> haven't been able to get any Fedex module I've tried to get a descent
>> response time.
>> The one that ships with satchmo currently gives me a ~6 second response
>> time using only 2 shipping methods (express & 2 day) and one item in the
>> cart.
>> The soap method that Greg Newman built takes ~5.5 seconds
>> and the new method of yours I just tried out takes 8.5 seconds.
>>
>> I cannot figure out what in the world is going on.. Using the USPS i can
>> get 1.5 second response times without a problem.
>> The response from fedex is fine (~500ms) so I know its not an external
>> issue, any ideas??
>>
>> Dave
>>
>>
>>
>> On Sun, Nov 27, 2011 at 4:54 PM, Chris Moffitt <ch...@moffitts.net>wrote:
>>
>>> Based on the work that others have done, I was able to get the module
>>> working for me. I'd appreciate it if others would take a look at it and let
>>> me know if there's anything I'm missing.
>>>
>>> You can view the fork here -
>>> https://bitbucket.org/chris1610/satchmo-fedex/
>>>
>>> I still need to update the docs but it seems to be working well for me.
>>>
>>> -Chris
>>>
>>>
>>> On Sun, Nov 27, 2011 at 12:51 AM, ionic drive <ionicdr...@gmail.com>wrote:
>>>
>>>> @Hynekcer
>>>> Its not that I did not want to continue. But there is no nanosecond time
>>>> left for me right now.
>>>> The only thing I remember, when I was sniffing in the Fedex response one
>>>> day. I think I remember that Fedex did not respond with a "time in
>>>> transit" or similar parameter.
>>>>
>>>> Maybe "time in transit" is only for ground delivery not for aircraft
>>>> shipments.
>>>> But its hard to say as there is no Fedex API and parameter description
>>>> available. I think its a good idea to proceed to the newer Fedex API if
>>>> they provide better and more detailed information.
>>>>
>>>> ionic
>>>>
>>>>
>>>> On Sat, 2011-11-26 at 16:28 -0800, hynekcer wrote:
>>>> > I fixed international characters for legacy method in collaboration
>>>> > with user "Ionic Drive" in e-mail communication following the thread
>>>> > groups.google.com/group/satchmo-users/browse_thread/thread/
>>>> > 86ea6bfeeae3955b/ . I did not published the solution becase he found
>>>> > other bug caused by outdating Fedex code (no "time_in_transit") and he
>>>> > did not want to continue.
>>>> > I think the new interface would be better if you have time for it now.
>>>> >
>>>> > I would like if no new dependencies would be imported if Fedex is not
>>>> > used. New packages would be of course included in automatic Quick
>>>> > Start Installation but it would be possible a manual installation of
>>>> > unmodified Satchmo without them. It is not as serious as deep
>>>> > dependencies on livesettings etc. but nobody knows ahead.
>>>> > Please send a link some day before you commit it to trunk.
>>>> >
>>>> > On 26 lis, 23:56, Chris Moffitt <ch...@moffitts.net> wrote:
>>>> > > I recently had the need to go in and make some custom changes to
>>>> Fedex. In
>>>> > > the process, I learned that Satchmo's current XML implementation is
>>>> a bit
>>>> > > old and needs to be updated. The current version works with the
>>>> legacy
>>>> > > Fedex servers but won't migrate cleanly to the newer and more up to
>>>> date
>>>> > > ones.
>>>> > >
>>>> > > After fiddling around with it for a while, I think we have two
>>>> options
>>>> > > going forward.
>>>> > >
>>>> > > 1. Modify the existing XML version to use the newer syntax and keep
>>>> it
>>>> > > mostly the same as the current implementation.
>>>> > > 2. Migrate to a newer API version using SOAP. It looks like there
>>>> have been
>>>> > > a few folks that have done this so I think the implementation
>>>> effort is
>>>> > > fairly limited but it would introduce new dependencies for the Fedex
>>>> > > module, namely suds and python-fedex -
>>>> http://code.google.com/p/python-fedex/
>>>> > >
>>>> > > Under the hood there aren't that many differences between SOAP and
>>>> the XML
>>>> > > api but after trying to read the Fedex docs for a while, they are
>>>> really
>>>> > > pushing towards the SOAP approach. Having some work already in
>>>> place for
>>>> > > the Python-fedex module, I think it's good to leverage instead of
>>>> > > recreating our own.
>>>> > >
>>>> > > As you can tell, I'm leaning towards jumping to option #2 but
>>>> wanted some
>>>> > > feedback from the group. Also, some folks have already started
>>>> working on
>>>> > > this integration so I'd appreciate any updates or code contribution
>>>> to make
>>>> > > this easier.
>>>> > >
>>>> > > Interested in the group's input.
>>>> > >
>>>> > > -Chris
>>>> >
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Satchmo users" group.
>>>> To post to this group, send email to satchmo-users@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> satchmo-users+unsubscr...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/satchmo-users?hl=en.
>>>>
>>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Satchmo users" group.
>>> To post to this group, send email to satchmo-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> satchmo-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/satchmo-users?hl=en.
>>>
>>
>>
>>
>> --
>> Dave Brown
>> CEO/Founder
>> Rampframe.com - Action Sports Network
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Satchmo users" group.
>> To post to this group, send email to satchmo-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> satchmo-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/satchmo-users?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Satchmo users" group.
> To post to this group, send email to satchmo-users@googlegroups.com.
> To unsubscribe from this group, send email to
> satchmo-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/satchmo-users?hl=en.
>



-- 
Dave Brown
CEO/Founder
Rampframe.com - Action Sports Network

-- 
You received this message because you are subscribed to the Google Groups 
"Satchmo users" group.
To post to this group, send email to satchmo-users@googlegroups.com.
To unsubscribe from this group, send email to 
satchmo-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/satchmo-users?hl=en.

Reply via email to