Re: HTTPAPI performance problems

[Radu Botescu <rbotescu@xxxxxxxxx>]

   Hi Paul,
   thx for you ideea. I'll try.
   In the meantime I've found in one of the programs a little instruction
   which I think makes the difference.... a lock of a *dtaara just before
   calling the�"http_url_post_xml"...and the *dtaara is never unlocked.�   So if another program is running it will be in wait until the first one
   finished and unlock the *dtaara ...and so on and so on...
   I'll do a new version, remove the lock (because there is no need to
   modify this *dtaara...) and see the performances.
   Thank you again,
   Radu�
   On Tue, Sep 15, 2015 at 12:00 PM, Paul Roy <[1]paul.roy@xxxxxxx> wrote:

     � �what happens if you limit the number of parallel jobs to 3-4 ?
     � �you could try to use a jobq with max active to 3/4..
     � �Paul
     � �From:� � � � Radu Botescu <[2]rbotescu@xxxxxxxxx>
     � �To:� � � � HTTPAPI and FTPAPI Projects
     <[3]ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
     � �Date:� � � � 15/09/2015 10:10
     � �Subject:� � � � HTTPAPI performance problems
     � �Sent by:� � � � [4]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
     � �     �__________________________________________________________________

   � �Hello, I've implemented the httpapi with success but i have some
   � �performance problems when using it in many calls in parallel.
   � �Let me explain and sorry if it is long...
   � �I call an external webservice in order to get a shipping label.
   One
   � �label
   � �per parcel.
   � �Now if on a palette I have 10 parcels I need to call 10 times the
   same
   � �webservice.
   � �There are 2 ways to do it:
   � �1. In sequence. Parcel 1, parcel 2....parcel 10. If I have 3-4
   seconds
   � �per
   � �label ==> the last label will be printed after 30-40 seconds.
   � �2. In parallel. This is the current solution. I submit in batch
   one job
   � �per
   � �parcel/label. Thus I have 10 jobs running in parallel. One label
   is
   � �very
   � �fast, 2-3 seconds. The longest is 20-25 seconds. So overall it is
   � �better
   � �but I do have a big problem bc for at least one label I wait too
   � �much...20-25 seconds...After 2-3 labels the processing time is
   starting
   � �to
   � �be longer...
   � �How it works:
   � �1. I call a Program A in order to create a xml file in ifs (need
   to log
   � �the
   � �files and have a history....)
   � �2. I call a Program B in order to consume this xml file with
   � �"http_url_post_xml" . I parse the answer. I also write the label
   (ZPL
   � �code)
   � �to a IFS file.
   � �3. I write some tracking information and print the label
   � �The bottleneck is in the step 2.
   � �The debug is *ON. I prefer to have all the logs at least for
   several
   � �months.
   � �I've spoke with my client and on his side he has between 1 and 2
   � �secondes
   � �of processing time.
   � �I do not understand where is the bottleneck...too many IFS
   operations
   � �in
   � �parallel? Is somewhere something in httpapi which force several
   � �parallel
   � �jobs to be processed in sequence ? I do not thing so...
   � �Any idea will be much appreciate :)
   � �Thanks,
   � �Radu
   � �--
   � �R.

     �     �------------------------------------------------------------------
     -----
     � �This is the FTPAPI mailing list.� To unsubscribe, please go
     to:
     � �[1][5]http://www.scottklement.com/mailman/listinfo/ftpapi
     �     �------------------------------------------------------------------
     -----
     References
     � �1. [6]http://www.scottklement.com/mailman/listinfo/ftpapi
     --------------------------------------------------------------------
     ---
     This is the FTPAPI mailing list.� To unsubscribe, please go to:
     [7]http://www.scottklement.com/mailman/listinfo/ftpapi
     --------------------------------------------------------------------
     ---

   --
   R.

References

   1. mailto:paul.roy@xxxxxxx
   2. mailto:rbotescu@xxxxxxxxx
   3. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
   4. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   5. http://www.scottklement.com/mailman/listinfo/ftpapi
   6. http://www.scottklement.com/mailman/listinfo/ftpapi
   7. http://www.scottklement.com/mailman/listinfo/ftpapi

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------