[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
-----------------------------------------------------------------------