[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HTTPAPI performance problems



   Hi Radu,
   I use the "http_url_get_raw" with 25.000 request every day and
   I tested it with 100 parallel requests. There was never a
   performance problem.
   Rainer
   Am 15.09.2015 um 12:17 schrieb Radu Botescu:

   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]<[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]<[2]rbotescu@xxxxxxxxx>
     �  � To:�  �  �  �  HTTPAPI and FTPAPI Projects
     [3]<[3]ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
     �  � Date:�  �  �  �  15/09/2015 10:10
     �  � Subject:�  �  �  �  HTTPAPI performance problems
     �  � Sent by:�  �  �  �  [[4]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][5]http://www.scottklement.com/mailman/listinfo/ftpapi
     �
     � ------------------------------------------------------------------
     -----
     References
     �  � 1. [6][6]http://www.scottklement.com/mailman/listinfo/ftpapi
     --------------------------------------------------------------------
     ---
     This is the FTPAPI mailing list.�  To unsubscribe, please go to:
     [7][7]http://www.scottklement.com/mailman/listinfo/ftpapi
     --------------------------------------------------------------------
     ---

   --
   R.

References

   1. [8]mailto:paul.roy@xxxxxxx
   2. [9]mailto:rbotescu@xxxxxxxxx
   3. [10]mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
   4. [11]mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   5. [12]http://www.scottklement.com/mailman/listinfo/ftpapi
   6. [13]http://www.scottklement.com/mailman/listinfo/ftpapi
   7. [14]http://www.scottklement.com/mailman/listinfo/ftpapi


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

References

   1. mailto:[1]paul.roy@xxxxxxx
   2. mailto:[2]rbotescu@xxxxxxxxx
   3. mailto:[3]ftpapi@xxxxxxxxxxxxxxxxxxxxxx
   4. mailto:4]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
   8. mailto:paul.roy@xxxxxxx
   9. mailto:rbotescu@xxxxxxxxx
  10. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
  11. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
  12. http://www.scottklement.com/mailman/listinfo/ftpapi
  13. http://www.scottklement.com/mailman/listinfo/ftpapi
  14. http://www.scottklement.com/mailman/listinfo/ftpapi
  15. 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
-----------------------------------------------------------------------