YOURLS Link Clicks take almost 45 secs to resolve

[nathanlang]

Hello everyone. I'm hoping someone might be able to help me. When my short links were originally created they were relatively quick to resolve to a page when clicked. Now, it seems that it takes almost 30-45 secs to resolve when clicked on. Could this be an SQL/DB Issue with my webhost?

Is there away I can work to get this sped up as people clicking on the links are not waiting around for them to resolve. Happy to add more info that might be helpful to speed up the links. I've searched the Plugins list and while I found the APC plugins, I was not able to get them working (as yet) with my webhost. Any help would be very much appreciated. Thanks!

[ozh]

Check here https://docs.yourls.org/guide/troubleshooting/first-steps.html#double-check-your-config-php -- enabling debug output will help first analysis and particularly seeing SQL queries and their duration, on the admin page for instance

[nathanlang]

Thanks OZH. I did that as below. The problem (and this could be other plugins) is that when the shortlink is clicked - say from an email blast, the click takes a while to finally load. Wondering how I might be able to speed up the process of someone clicking on the link and having the page load faster.

Connected to database (Left Blank) on localhost
SQL perform: SELECT option_name, option_value FROM options WHERE 1=1 (0.00114 s)
Check for new version: no
SQL perform: SELECT COUNT(keyword) as count, SUM(clicks) as sum FROM url WHERE 1=1 (0.00111 s)
SQL perform: SELECT * FROM url WHERE 1=1 ORDER BY timestamp desc LIMIT 0, 15; (0.00028 s)

[ozh]

So, it looks like it's not your SQL server that's on its knees. Is adding a new shortlink in the admin slow too ?

If the latency occurs only when clicking a short link, it's either on YOURLS site when the click is logged, or it's nothing to do with YOURLS at all. Maybe try the following : add define('YOURLS_NOSTATS', true); in your config.php, this skips the click logging entirely (obvious downside: you have no stats). If that does not speed up things, then you'll know the problem is elsewhere.

[nathanlang]

Thanks again OZH. I will try this and see how it goes.

[nathanlang]

Ok will give it a try, thanks! sent from phone +nathanlang.com

…

On Thu, May 12, 2022, 12:03 PM ྅༻ Ǭɀħ ༄༆ཉ ***@***.***> wrote: So, it looks like it's not your SQL server that's on its knees. Is adding a new shortlink in the admin slow too ? If the latency occurs only when clicking a short link, it's either on YOURLS site when the click is logged, or it's nothing to do with YOURLS at all. Maybe try the following : add define('YOURLS_NOSTATS', true); in your config.php, this skips the click logging entirely (obvious downside: you have no stats). If that does not speed up things, then you'll know the problem is elsewhere. — Reply to this email directly, view it on GitHub <#3336 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3WJ7L45BD3OQAJS73HROTVJUTWJANCNFSM5VV4L2OA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[hickstooor]

@nathanlang did you ever fix this? having similar issue, any information would be much appreciated, thanks.

[nathanlang]

@hickstooor Yes, and No. Yes, in that everything works normally when the shortlink resolves to a different domain (ie. NYT, Dropbox, etc). The problem is that my shortlinks that resolve to a subdomain that resides on the same host as my YOURLS Install is indeed slow. So maybe that has/had something to do with it. When the resolve is to ANOTHER domain, the timing is fine. Hope this helps. If it helps, this information is based on my usage with both Godaddy, and BlueHost hosting providers

[hickstooor]

Thanks for quick reply.

Hmm yea my short links resolve to same domain, interesting. Thanks again man!

[nathanlang]

Yep, no worries!

[wrtz008]

Try to test also with Traceroute on your local machine to see how tracertoute pings are working and how it gets each step of the way.
Try it on the link that goes to the subdomain.
Then try it on the link that goes to another domain.

I've personally debugged this way issues with other sites I could not access and did not know why; it could be a ISP provider, or a block on the server side on that subdomain.

You can then whitelist IPs on the server level to speed up the redirections (i.e. if you use Cloudflare or you can do it at htaccess or server level IPs)