Details
-
Type:
extRequest
-
Status: Closed
-
Priority:
Major
-
Resolution: Done
-
Fix Version/s: 2021
-
Component/s: FIWARE-TECH-HELP
-
Labels:None
-
Sender Email:
-
HD-Chapter:Data
-
HD-Enabler:Orion
Description
Good afternoon,
I've been using the Publish/Subscribe Context Broker - Orion Context Broker
for my master thesis, and I'm using the Fiware Lab (Global Instance -
http://orion.lab.fiware.org:1026).
I've been doing some experiments on it and recording some useful metrics .
The experiment is publishing 20000 entities in parallel (from 50 to 500
requests always active, until there are no more entities to publish) and I
also have a subscriber that receives all these entities updates.
I publish this data 9 times per day (3 times in the morning (from 9h30 to
12h30 GMT), 3 in the afternoon (from 15h30 to 18h30 GMT) and 3 in the
evening (21h30 to 00h30 GMT), and I noticed that the number of retries I
see in the application (responses with status 503 or TCP RST flag being
sent) grows steady throughout the day.
To try out some hypotheses I published the same data during 2 consecutive
days (using the same formula). I have attached some images with a box plot
for each day showing the number of retries.
The retries grow throughout the day, but in the following one they start
low again. Could you tell me if this is some kind of memory leak and the
machine is being restarted at dawn (somewhere between 00h30 and 9h30 GMT),
or is it due to something else? This would be incredibily useful to my
thesis.
I have already asked this same question once, but I got answered that I
should deploy my own Orion instance. The thing is that it is vital that I
don't have access to the broker nor can I control it in any way, because my
tool is aimed at testing the performance in an production environment
therefore the Fiware Lab Global Instance fits like a glove in my tests. So
if I could get an answer I would be incredibly thankful.
Thanks,
João Cardoso
Since January 1st, old domains won't be supported and messages sent to any domain different to @lists.fiware.org will be lost.
Please, send your messages using the new domain (Fiware-tech-help@lists.fiware.org) instead of the old one.
_______________________________________________
Fiware-tech-help mailing list
Fiware-tech-help@lists.fiware.org
https://lists.fiware.org/listinfo/fiware-tech-help
[Created via e-mail received from: Joao Cardoso <jmmesquitacardoso@gmail.com>]
Activity
Comment by jmmesquitacardoso@gmail.com :
Good morning,
Thank you very much for your answer. The tests were done on the 24th and
25th of May. I had already done some tests before and that also happened,
if it is any help.
Thanks for your attention,
João Cardoso
2016-06-07 9:43 GMT+01:00 Help-Desk <jira-help-desk@fi-ware.org>:
>
>
Hi,
PEP Proxy responds with a 503 error when it cannot establish connection with the IdM to authenticate itself or to validate a token. Are you still getting these errors?
BR
Comment by jmmesquitacardoso@gmail.com :
Good morning,
Yes, tested right now and I still get these erros.
Thanks,
João Cardoso
2016-06-07 10:35 GMT+01:00 Help-Desk <jira-help-desk@fi-ware.org>:
>
>
Dear Joao,
If you are aimed at testing the performance in an production environment, note that Orion instance at orion.lab.fiware.org is not a production environment. It is a testing environment. From http://catalogue.fiware.org/enablers/publishsubscribe-context-broker-orion-context-broker/instances:
Take into account that this is a global instance shared among all its users That means that your actions on the instance could impact to other users or viceversa. In this sense, this instance is fine to do prospective testing and to analyse the feasibility of the GEi to your purposes. However, if you are planing to use this GEi in production, please consider to deploy a dedicated instance for you in the FIWARE cloud.
Having said that, as far as I know based on the knowledge provided by the monitoring tools deployed in the FIWARE Lab infrastructure, I don't have reports of any memory leak, restart or service malfunction in the past days (I don't know when you did your tests... I mean, you describe the hours, but not the days. Is it still happening?).
Note that the 503 errors you are getting are not directly generated by Orion, but by the PEP proxy. I don't know under which circumstances PEP responses with 503, but I'll pass this issue to PEP team so they can have a look and eventually provide feedback.
If you are interested in debugging the problem, I'd recomment you to try to reproduce in a controled environment controled by you, i.e. using a private PEP + Orion setup and run your load test on that instance to see if the behaviour is the same.
Thanks!
Best regards,
------
Fermín