| # |
Dec 13th 2017, 20:16 |
hmic |
still, make sure dns is working and can resolve all the names involved, the local hostname, with and without domain name, localhost, the clients hostname and the http header server name, at least |
| # |
Dec 13th 2017, 20:16 |
furqan |
oooh ,localhost signifies unix sockets ...okay i will use 127.0.0.1 instead..and would try to debug the information ....Unfortunately will have to wait till tommorrow ,as i said tightly coupled office envoirnment... |
| # |
Dec 13th 2017, 20:16 |
hmic |
and if that (proxy) would be a problem, the insert would not work at all, would it? |
| # |
Dec 13th 2017, 20:15 |
hmic |
if you use 127.0.0.1 instead (or any ip address), it will use tcp sockets instead |
| # |
Dec 13th 2017, 20:15 |
hmic |
if you are using "localhost", the mysql lib will be fored to use unix sockets |
| # |
Dec 13th 2017, 20:15 |
furqan |
yes sorry my bad ,its just the insert !! |
| # |
Dec 13th 2017, 20:15 |
hmic |
you can swtich from unix socket to tcp socket |
| # |
Dec 13th 2017, 20:15 |
furqan |
or shall i try communication with unix pipes instead of tcp sockets ! |
| # |
Dec 13th 2017, 20:14 |
hmic |
in the request cycle name resolution plays an even more important role - like i mentioned above |
| # |
Dec 13th 2017, 20:14 |
furqan |
so which makes me suspect ,is there a chance when the cake php orm would be trying to send packets to mysql server over tcp socket ,will it encounter something identical |
| # |
Dec 13th 2017, 20:14 |
hmic |
you have been talking about the insert taking so long, not the full request |
| # |
Dec 13th 2017, 20:13 |
hmic |
why are you talking about a proxy, where do you think it could be involved in the problem you are debugging? |
| # |
Dec 13th 2017, 20:13 |
furqan |
but if i make a curl request to an api running on the localbox through terminal ,teh request goes through the proxy always ,till i do not set the option export no_proxy=localhost,127.0.0.1 ,and then the curl works fine with that api |
| # |
Dec 13th 2017, 20:12 |
hmic |
this is being able to resovle the db server, localhost, the name used in the http header, the actual hostname of the box and so on... |
| # |
Dec 13th 2017, 20:12 |
hmic |
yes, name resolution is a problem, if its not working (correctly) |
| # |
Dec 13th 2017, 20:11 |
furqan |
that woulod be teh first thing i would do ! |
| # |
Dec 13th 2017, 20:11 |
hmic |
there cannot be a proxy involved if you run the db on localhost |
| # |
Dec 13th 2017, 20:11 |
hmic |
check the query log |
| # |
Dec 13th 2017, 20:11 |
furqan |
yes ,i |
| # |
Dec 13th 2017, 20:11 |
hmic |
use the ip address instead of localhost |
| # |
Dec 13th 2017, 20:11 |
furqan |
yes it easy ,n i am really strugelling with that |
| # |
Dec 13th 2017, 20:11 |
hmic |
i've given you the usual suspects |
| # |
Dec 13th 2017, 20:11 |
furqan |
is there a chance it has to do something with proxy !! resolution ... |
| # |
Dec 13th 2017, 20:11 |
hmic |
so its easy to compare the two environments... |
| # |
Dec 13th 2017, 20:10 |
hmic |
good |
| # |
Dec 13th 2017, 20:10 |
furqan |
exactly same data |
| # |
Dec 13th 2017, 20:10 |
hmic |
with the same data? |
| # |
Dec 13th 2017, 20:10 |
hmic |
i'd still prefer dropping a docker container and let them execute it instead :D |
| # |
Dec 13th 2017, 20:10 |
furqan |
i would chek teh query log ,but i dont thing it has to do with centos ,as i told u that i am running the same code base ,on my home box which is a centos vm...n its much much faster |
| # |
Dec 13th 2017, 20:09 |
hmic |
it can very well be the php/mysql lib version that ships with centos and you need to ask your team to upgrade |
| # |
Dec 13th 2017, 20:09 |
hmic |
if the same query run through the orm takes longer than natively, there is something very bogus. so lets hope, for centos, it's something else... you need to check the querylog anyways to be sure |
| # |
Dec 13th 2017, 20:08 |
hmic |
so its time to check the query log |
| # |
Dec 13th 2017, 20:08 |
furqan |
i have tried increasing the buffer pool size to 5gb ,no luck there also |
| # |
Dec 13th 2017, 20:07 |
furqan |
also an insert using raw sql on the same table in the same code snippet takes milliseconds where the insert on that table through orm takes 20 seconds |
| # |
Dec 13th 2017, 20:07 |
hmic |
table (*index*) to big to fit in the allocated ram? |
| # |
Dec 13th 2017, 20:07 |
hmic |
so, how comes your insert needs a second now? |
| # |
Dec 13th 2017, 20:06 |
hmic |
just put the app in a docker box and let them run this - problem solved. can stay on centos till they die :P |
| # |
Dec 13th 2017, 20:06 |
furqan |
yes an insert to an empty table is very fast |
| # |
Dec 13th 2017, 20:05 |
furqan |
I so so agree with you ,but unfortunately ,i am working in a very tightly coupled envoirnment ,where there are lots of approvals a person has to undergo for a minimal change ,apperantly their support team provides support only for centos (patching etc etc) as of which i had to start developement on centos only :( |
| # |
Dec 13th 2017, 20:05 |
hmic |
try to get there first, before checking/considering anything else |
| # |
Dec 13th 2017, 20:05 |
hmic |
an insert in an empty table on a local dbserver should be next to instant |