The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2016-06-28

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:35 tchaves joined #mojo
01:16 leoj joined #mojo
02:12 noganex_ joined #mojo
02:50 ivi joined #mojo
03:03 leoj joined #mojo
03:15 vicash joined #mojo
03:42 zivester joined #mojo
04:23 leoj joined #mojo
05:38 inokenty-w joined #mojo
05:38 jkrizansky joined #mojo
05:43 prajith joined #mojo
05:44 prajith is it possible to port this  Asterisk::AMI::Common  module to a  non-blocking one
05:45 prajith like MongoDB mango
05:51 cosimo joined #mojo
06:07 prajith do I have to re-write this module for that?
06:21 jberger prajith: I have looked at that one before and if I'm remembering correctly it abuses condvars in a way that isn't really how a library should be written making it hard to use in an ioloop
06:22 prajith okay, then I think we should re-write this from scratch :(
06:24 jberger https://metacpan.org/source/GREENBEAN/Asterisk-AMI-v0.2.5/lib/Asterisk/AMI.pm#L1506
06:24 jberger https://metacpan.org/source/GREENBEAN/Asterisk-AMI-v0.2.5/lib/Asterisk/AMI.pm#L1108
06:24 dod joined #mojo
06:27 jberger we needed Asterisk at my previous job, I don't recall what we did but it might have been to leave the Asterisk stuff in a separate daemon
06:27 jberger it's been too long now though, sorry I can't remember better
06:28 prajith okay no pbm, let  melook in to this :)
06:29 dod joined #mojo
06:30 jberger somehow ->recv should be replaced by https://metacpan.org/pod/AnyEvent#cb-cv-cb-cb--cv (I think)
06:31 jberger see https://metacpan.org/pod/AnyEvent#CONDITION-VARIABLES
06:31 jberger especially the example after "And this is how you would just set a callback to be called whenever the results are available:"
06:33 dod1 joined #mojo
06:42 prajith okay <jberger>, let me check
06:59 AndrewIsh joined #mojo
07:00 Atog joined #mojo
07:18 dod joined #mojo
07:41 jkrizansky joined #mojo
07:43 jkrizansky joined #mojo
07:56 cuechan joined #mojo
08:15 jkrizansky joined #mojo
08:19 icjs joined #mojo
08:23 osfabibisi joined #mojo
08:38 trone joined #mojo
08:46 Vandal joined #mojo
09:09 coolo_ joined #mojo
09:25 leoj joined #mojo
10:06 meshl joined #mojo
10:21 kaare joined #mojo
10:22 nnms joined #mojo
10:35 arthas joined #mojo
10:52 tchaves joined #mojo
11:14 kid51 joined #mojo
11:32 icjs2 joined #mojo
11:32 dvinciguerra_ joined #mojo
11:44 Kripton joined #mojo
11:46 jkrizansky joined #mojo
11:57 mpapec second perl/docker video which uses mojo as an deployment example,
11:57 mpapec https://www.youtube.com/watch?v=nzF5Lhv-UEs
11:58 mpapec as I read more about docker it looks less and less appealing
11:58 mpapec certainly not living up to the hype!
11:59 mpapec diving into it is, IMO complete waste of time
12:15 mcsnolte joined #mojo
12:46 neilhwatson joined #mojo
12:46 dotan joined #mojo
12:49 mpapec jberger: just now saw your docker comment
12:49 mpapec that would be third video then :)
12:50 mpapec I'm under impression that it introduces complete new set of problems
12:51 mpapec which are up to developer to solve
12:52 mpapec so that operations team can relax ;)
12:57 Kripton joined #mojo
13:00 ZoffixW_ joined #mojo
13:02 ramortegui joined #mojo
13:17 gizmomathboy joined #mojo
13:19 punter joined #mojo
13:20 zivester joined #mojo
13:23 cuechan joined #mojo
13:59 nic https://metacpan.org/pod/HTTP::XSHeaders
14:06 dvinciguerra_ joined #mojo
14:18 ptolemarch joined #mojo
14:47 cuechan_ joined #mojo
14:52 user_7801 joined #mojo
14:55 user_7801 Running Mojo with Morbo on windows the API gives around 1-2 seconds response time.
14:56 user_7801 Running it on my rootserver (ping 15 ms) there is a delay of upto 10 seconds.
14:56 user_7801 I basically have only a $self->delay, that requests simultanously 15 pages with $self->get
14:57 user_7801 Is there something like a max connections variable or anything else that could slow it down ?
14:58 user_7801 $self->ua->inactivity_timeout(4); will sometimes still give results of 10 seconds delay.
15:06 kes joined #mojo
15:10 zivester joined #mojo
15:11 user_7801 Turned out that one of the sites is extremely slow when fetched from the rootserver
15:13 lluad joined #mojo
15:16 user_7801 It's the PayPal SOAP api
15:22 cfedde root server? dns?
15:24 user_7801 You mean a change of the DNS could have impact on the speed?
15:25 cfedde I was wondering what you ment when you said "Running it on my rootserver" up above.
15:26 pink_mist user_7801: "rootserver" is usually a term related to the root dns servers, so when you used that term, cfedde (and I as well) thought you were talking about DNS
15:27 pink_mist user_7801: if you meant something else, please enlighten us
15:28 cfedde user_7801: there are a few approaches to use when chasing down performance problems.  One is to watch activity on the network. wireshark and tcpdump are useful there. Another is to use the perl debugger and trace the execution.
15:28 pink_mist also, if you're running a DNS root server, I don't think I'd want anybody running perl on the same system, much less mojolicious
15:28 jkrizansky joined #mojo
15:29 user_7801 i meant a dedicated server
15:30 cfedde also windows based?
15:30 user_7801 Debian
15:31 cfedde thanks.  It looks like you have it worked out mostly.
15:31 user_7801 If you do something like $self->ua->get('http://example.com'); it takes here on my windows system around 1-2 seconds until i get a response.
15:31 user_7801 and on my dedicated server upto 10 seconds.
15:31 jnbek well, example.com has been known to be slow...
15:31 * jnbek runs
15:31 user_7801 Yeah, it was just an example :)
15:32 user_7801 I actually talk about the PayPal API
15:32 cfedde how can we help? Is there some specific question we can assist with?
15:32 user_7801 no, I guessi t's nothing we can change
15:33 cfedde ok.  you may want to check if it is paypal specific or if there is some systemic slowdown.
15:34 cfedde I tend to pick on ddg or google for plain old "is it just me" kinds of check.
15:35 user_7801 i'm just curious about $self->ua->inactivity_timeout(4);
15:36 user_7801 I set this global, but the response is sometimes still 10 seconds
15:37 cfedde it may not actually be inactive. things like retries and keepalive might be restting the timeout.
15:37 user_7801 my function is an empty $self->delay with around 10 get-requests, and a $self->render in the callback.
15:37 pink_mist if you're using the same ua all the time..
15:37 pink_mist $self->ua that is
15:37 pink_mist not any Mojo::UserAgent->new() you've created
15:38 user_7801 Yeah, printed the values with $self->app->log->debug
15:38 pink_mist however, it might be that the inactivity doesn't trigger because it gets partial data
15:38 user_7801 it's 4 seconds before each get()
15:38 cfedde "before"?
15:38 cfedde you mean the git hangs or that the system hangs before calling ->get?
15:39 cfedde s/git/get/
15:41 disputin joined #mojo
15:42 user_7801 what I mean is, that i made sure i always use the same user-agent object.
15:42 user_7801 and it's 4 seconds, but perhaps as pink_mist said, it receives partially data and doesn't close the connection
15:45 user_7801 i know it's a bit *confusing* but I'm almost sure the problem cannot be fixed at my side. it's just a slow SOAP server from paypal.
15:46 pink_mist you could have a timer delay which forcefully removes the request after 4 seconds
15:47 thowe_work joined #mojo
15:48 user_7801 true, but the function is going to fail then. i'll just accept the long respponse time
15:48 pink_mist wouldn't it fail if it timed out anyway? :P
15:49 user_7801 it will
15:56 user_7801 do you guys think it's problematic if an api takes upto 10 seconds sometimes to sent a reply?
15:56 cfedde this is always the problem with timeout failures.  It's hard to make them fast.
15:56 user_7801 it is integrated in a website and the user *may* wait then 10 seconds on a loading bar.
15:56 pink_mist user_7801: yes, I'd say it's definitely a problem if it takes that long, at least if there's not indication to the user that anything is happening
15:56 cfedde In my experience if something network wise is taking more than 500ms then it's probably not going to happen.
15:57 pink_mist s/not/no/
15:57 user_7801 this api call is just executed once upon the registration.
15:57 user_7801 it could show an ajax loading bar
15:57 pink_mist I'd say that would be a good idea
15:58 cfedde expecially something like a public API service like paypal. they want to get your request handled right now.
15:59 cfedde I'd start sitting with wireshark looking at the transacton to understand what is going wrong then recode accordingly.
16:00 cfedde chances are that a service as popular as paypal will have reasonable diagnostics.
16:01 cfedde in other words start attacking the cause rather than masking the symptom.
16:08 user_7801 in most cases the response time is < 3 seconds
16:09 pink_mist it might be something odd your debian server too
16:09 pink_mist +on
16:09 user_7801 on windows morbo, it's mostly < 1.5 seconds
16:09 user_7801 with*
16:09 user_7801 could be
16:11 pink_mist and I don't necessarily mean how it's configured, but it could be how the datacenter's links are set up, it could be paypal specifically throttling some servers, it could be a lot of things
16:11 user_7801 the company is known for bad data connectivity
16:12 user_7801 but i'll have to do further tests
16:12 pink_mist then that's a likely culprit
16:13 user_7801 i'll set up an amazon EC2 instance
16:30 leoj joined #mojo
16:31 jabberwok joined #mojo
17:31 punter joined #mojo
17:44 Kripton joined #mojo
17:47 Kripton joined #mojo
17:49 leoj joined #mojo
17:51 kes Do you forget to remove '+' sign after adding '*'?
17:51 kes https://github.com/kraih/mojo/commit/b71327d6b5264bcabcd2879556a61d99c2b1eedb
17:52 jberger kes: that is a greedy capture
17:53 jberger I tried it without and it wasn't quite right
17:53 odc joined #mojo
18:02 Grinnz possessive modifier to be precise
18:04 Grinnz quantifier* even
18:05 Grinnz https://metacpan.org/pod/perlre#Quantifiers goes over them a bit
18:25 PryMar56 joined #mojo
18:30 jberger greedy is the right word, capture was not
18:35 Grinnz_ greedy means something different in regex terms
18:35 Grinnz_ quantifiers are greedy by default, but not possessive by default
18:38 jberger "and give nothing back" ... fine I conceed
18:39 jberger but that's a pretty fine distinction :P
18:41 Grinnz_ https://metacpan.org/pod/perlre#pattern5 discusses it more actually, since that's the explicit syntax
18:41 Grinnz_ (that works in 5.8, possessive quantifiers do not)
18:47 CW Is it possible to break hypnotoad?
18:47 Grinnz_ uhm.... too vague?
18:48 CW Applications that use to run on Hypnotoad crash after starting for like 2 seconds. Also not logging
18:48 * jberger rummages around for mst's vaguecat :-P
18:48 jberger CW: does the application definitely load
18:49 jberger ?
18:49 CW For about 2 seconds, yeh
18:49 zivester joined #mojo
18:49 jberger './myapp routes' is a decent test
18:49 jberger what version?
18:50 jberger there was a bug (that presented slightly differently to what you describe) but it might be worth ensuring that it isn't a factor
18:53 CW I am not sure how to find what version. But this only started after having to kill a hypnotoad process. Am wondering if I killed something more then I ment to.
18:53 jberger ./myall version
18:53 jberger myapp
18:53 jberger and of course that is the file name of your application script file
18:59 CW I don't have permission to do that. :-S
19:01 CW Could that be my issue with Hypnotoad... lack of permissions?
19:01 jberger possibly
19:01 jberger depending on what is trying to start the application
19:02 CW The app works great in morbo
19:03 jberger are you sure the hypnotoad process that you tried to kill is really dead?
19:04 jberger generally I think you are in sysadmin land now not mojo land
19:04 jberger that's just my best guess
19:04 CW Thats what I am thinking, too. Thanks, you are always awesome...
19:08 jberger no problem, good luck
19:09 jberger do be sure that you are using 6.60+ https://github.com/kraih/mojo/blob/master/Changes#L49
19:09 jberger to avoid that bug that I mentioned earlier
19:13 CW will do thanks.
20:03 Kripton joined #mojo
20:19 itaipu joined #mojo
20:28 CW It is a permissions issue. Finally got it to create a log, and hypnotoad doesn't have permissions to create a process id. Just incase you were wondering. :-S
20:41 jberger glad you figured it out
20:53 itaipu joined #mojo
20:53 meshl joined #mojo
21:46 meshl joined #mojo
22:22 PopeF0 joined #mojo
22:23 Atog joined #mojo
22:29 itaipu joined #mojo
23:08 Atog joined #mojo
23:20 meshl joined #mojo
23:41 leoj joined #mojo

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary