Hi, (sorry for my english) I can't use jDownloads on a clean install of Joomla online. The backend of jDownloads takes 60 seconds to load. My MYSQL version is 5.6 and I can't change it. Can it be the reason why it's so slow ? On local installation, it work like a charm on 5.7 version. (My system online info in attachements...). Thank you for your great job ! Jos
Please see
http://www.jdownloads.com/forum/index.php?topic=12172.msg46260#msg46260ColinM
I've tested on a local machine with the same versions of php (7.3.18) and Mysql (5.6.48) as they are online. But no change, it works on local, it's so slow online (Firebug say juste that it waits for server...).
As you can see on attached images there are 307 responses on the online version and the index.php?option=com_jdownloads is called two times.
Thanks for your help. Have a nice day !
Hi,
maybe should you contact your hoster and tell him your problem (and your test results). Maybe are you on a very busy (and shared) server.
When both installation are (complete) the same could be the reason only the server settings. In my opinion.
You could also activate the Joomla debug option to see how long need the DB queries. ::)
By the way, my experience is that Joomla is on the server much faster as on a local environment (like xampp or wampp).
Edit:
A very important tip is that you should never choice a very cheap hoster for a Joomla website. ;)
Thanks for you answer. Unfortunately, it's not a cheap one. It's a performance 2 by OVH
https://www.ovh.com/fr/hebergement-web/hebergement-performance.xml and Joomla is running fast on it. I will better look on DB queries... Thank you. Jos
You can the in the linked debug screenshot that the 60 sec waiting is on the "beforeRenderModule mod_jdownloads_admin_stats" line. If i disable "admin_stats" and "admin_monitoring" modules in admin, the 60 sec wainting is on the "afterRenderComponent com_jdownloads". And the DB queries seem to take only 64.20 ms... Maybe it can help... Thanks
Okay. Thanks for the data.
A few questions:
- the problem exist only when you call the jDownloads control panel?
- all other backend pages has a normal loading time?
- the jDownloads frontend pages has a normal loading time?
- how many categories and Downloads have you in the download area?
- which jDownloads version use you? And which Joomla?
- have you get any response from your hoster?
Thanks for your response.
- - Yes the problem exists only on all jDownloads admin pages
- - All other backend pages have a normal loading time
- - jDownloads frontend pages have a normal loading time
- - I tried with one jDownloads category and five downloads and after with a just clean install
- - Versions are : Joomla! : 3.9.21. jDownloads : 3.9.5
- - No response from OVH now but they will tell me that it's come from site for sure...
Thank you for your efforts
Hi Jos,
QuoteYes the problem exists only on all jDownloads admin pages
I tried with one jDownloads category and five downloads and after with a just clean install
That's strange. Nobody else has reported a problem like this.
QuoteNo response from OVH now but they will tell me that it's come from site for sure...
Normally should it be possible to see in the log files something about the reasons. I hope.
Have you any third-party extensions installed? Maybe a system plugin?
Of course I could try to optimize some jDownloads queries and could add more indexes.
But I'm not sure that this will be helpful in your case.
Google has some results with the afterRenderComponent event in some other components:
https://www.google.com/search?q=afterRenderComponent&oq=afterRenderComponent&aqs=chrome..69i57.367j0j1&sourceid=chrome&ie=UTF-8
Are you sure that you have a php version >= 7.2?
I will think about what I can do. ::)
Could you please try to deactivate for a test the jDownloads system plugin?
But you must it afterwards activate again. It is required for jDownloads.
Hi, unfortunately there is nothing in log but this
[24/Sep/2020:17:48:23 +0200] "GET /administrator/index.php?option=com_jdownloads HTTP/1.1" 200 38563 "/administrator/index.php?option=com_menus&view=items&menutype=mainmenu" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"- [24/Sep/2020:17:49:24 +0200] "GET /media/jui/css/chosen.css?66a5d27a93474db2f3e9837badaa2cd8 HTTP/1.1" 200 2407 "/administrator/index.php?option=com_jdownloads" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"
- [24/Sep/2020:18:23:17 +0200] "GET /administrator/index.php?option=com_jdownloads&view=categories HTTP/1.1" 200 34665 "/administrator/index.php?option=com_jdownloads" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"
- [24/Sep/2020:18:24:18 +0200] "GET /administrator/components/com_jdownloads/assets/css/style.css HTTP/1.1" 200 2975 "/administrator/index.php?option=com_jdownloads&view=categories" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"
See times beetween lines...
- No third-party extension but a fresh install of joomla and just after a fresh install of jDownloads
- I looked on the google's results but I didn't find solution there
- Yes, php 7.3
- I tried to deactivate and reactivate the plugin but nothing happens
- I made another same fresh install on another server (Not a "Performance 2" by OVH but a "PRO" (which has less performances but where Jommla runs fine and which has differents parameters than the other one) and on a another domain. But it's the same. Thanks
Hi,
yes I see what you mean. But it is not possible to reproduce your problem. Also not on one of our server installations.
And as I say it again: Nobody else has reported your problem until today. So what shall I do?
You can self test it here on the demo installation:
https://www.jdownloads.org/administrator/index.php
User: demo
Password: demo
It is very fast. See attached the configuration.
Alternate could you create in minutes here a Joomla Website for free and test it also there:
https://launch.joomla.org/
By the way, the free websites above are not the fastest. ;)
Edit:
I read about a similar case a few minutes ago. There the site had been hacked and a plugin tried to load malicious code. Since the source did not respond, 60 seconds passed until the timeout. That would also be your waiting time. Maybe you should scan your Joomla installations for viruses. ::)
Thank you. I don't find the origin of the problem... Maybe a wrong parameter in OVH's servers. I just can say that it works with the jdownloads 3.2.69...
Hi Jos,
thanks for the update. Unfortunately this is not a happy outcome. But I will keep watching this post and if you find anything, let me know.
Every year we have maybe two or three topics with problems that nobody can understand or reproduce. Sometimes I get later an info at some point that it had something to do with the server and is now solved. But only rarely do I get reported the real reasons.
Hello,
I have exactly the same problem. Slow backend on production site, all other components of the backend are fine. If I install a backup of my site on my local computer, everything works as expected.
The only thing I changed before the backend of jdownloads became slow was moving from PHP 7.3 to PHP 7.4.
Jdownloads is version 3.9.7.2.Any help is appreciated.
Best regards Klaus
This is the system information of my server:
| Einstellung | Wert |
|
|
| PHP erstellt für | Linux info 3.0 #1337 SMP Tue Jan 01 00:00:00 CEST 2000 all GNU/Linux |
| Database Type | mysql |
| Datenbankversion | 5.7.30-log |
| Datenbankzeichensatz | utf8_general_ci |
| Datenbankverbindungszeichensatz | utf8mb4_general_ci |
| PHP-Version | 7.4.13 |
| Webserver | Apache |
| PHP-Interface für den Webserver | cgi-fcgi |
| Joomla!-Version | Joomla! 3.9.5 Stable [ Amani ] 9-April-2019 15:00 GMT |
| Joomla!-Plattform-Version | Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT |
| Browsererkennung | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
|
I am also facing slow JDownload issue. No such issue in any of the components.
Good evening,
I have exactly the same problem. jdownload is very slow in the backend and on all links except layouts.
I also have a problem in the frontend with downloading files that are public but does not allow public downloads without being registered.
https://www.abccamips.com/download.htmlJoomla doesn't allow "self" from an unregistered user, (no link with jdownload or not) but maybe there is a common point between these problems, but it escapes me.
Joomla Version: 3.9.24
php 7.3.23
Thanks in advance for your help
And in spite of the small inconveniences nice work...
Hi,
I can also confirm a very slow response time on Jdownloads. Awfully slow ...
/Ole
Quote from: caribert2 on 18.01.2021 21:53:04
Good evening,
I have exactly the same problem. jdownload is very slow in the backend and on all links except layouts.
I also have a problem in the frontend with downloading files that are public but does not allow public downloads without being registered.
https://www.abccamips.com/download.html
Joomla doesn't allow "self" from an unregistered user, (no link with jdownload or not) but maybe there is a common point between these problems, but it escapes me.
Joomla Version: 3.9.24
php 7.3.23
Thanks in advance for your help
And in spite of the small inconveniences nice work...
Only the link field Groups is displayed quickly and not layouts.
Hi Everyone,
We are looking for commonalities. It appears as if there is an 'after render' problem, where the software is awaitig a response. There sometimes seems to be a 500 error.
As yet we have not figured it out but it could be related to the version of PHP that is running or an http/https switch
Could you advise duration of your timeout please
Colin
Are you using the force https option in Joomla Global Congig Server Settings tab?
Hi everyone,
The access time is on average 60 seconds to jdownload in administration, except field groups which is two seconds maximum.
Yes the global configuration joomla force https is valid for the entire site.
For verification I have limited to the administration and disabled but this had no influence.
Hello to all,
Some suggestions for slowing down jdownload, after observation.
A slowdown of this nature is probably caused by a search for the application of one or more elements that is not found.
I was able to see in particular by displaying the categories that the application was looking for a creative user, who no longer existed.
Also another suggestion would be to dissociate in the administration the validation, the download and see the modification of the name.
Indeed some shared hosting does not always offer extraordinary performance and does not allow a succession of instructions, it would be easier to modify some aberrations that may occur ...
I am well aware that this is a lot of work...
Hi
Thanks for update60sec is the usual php.ini time out for execution
As a test could you change it to say 30 seconds
Colin
I do not have access to php.ini, shared server.
I have artificially created a new user with corresponding id, but it did not affect the slowness and it varies between 45s and 65s.
Alain
Alain
Thanksfor update.
Because times are varying your challenge seems diferent. So initial thought in your case is that it might help if you contact your web site provider.
Just to confirm that the delays are only in the backend of Joomla, the front end is OK as far as timing goes. Also in the Front End do you have an 'active slideshow' of periodically changing images? If so could you temorarily halt that to see if itt makes a difference. Usually the images are large size terms.
Colin
Quote from: ColinM on 22.01.2021 10:43:22
I have followed the dialog on the side as I have experienced the same latency in response in the backend.
I'm quite new into JDownload. Just installed it last week.
If it has any interest, we could open a live session on my installation so a developer could have a look at the installation. If you find it informative, I could provide you with a phpinfo dump from my web host.
cheers
Ole
Hi Colin,
Quote from: ColinM on 20.01.2021 22:47:08Are you using the force https option in Joomla Global Congig Server Settings tab?
yes, I have "force https" active. I disabled it, but the slow backend behavior did not change. But of course, https is for sure a difference to the local copy of my website, there I do not have https.
I also cannot change the PHP timeout that easy, because my site is hosted on a shared server.
How can I help to fix the problem?
Best regards Klaus
Hello to all,
Colin
I have disabled the component as a front-end, knowing from experience that javavascript conflicts could cause unexpected results, but this is not the case.
The hosting capabilities are not at issue in the problems I encounter.
In frontend it is the reCaptcha plugin however deactivated which is essential. I searched in the template but found nothing. By disabling invisible reCaptcha the answer is different.
As for the backend the slowness seems caused by the stat admin module, yet disabled, enabled same result.
mod_jdownloads_admin_stats (jDownloads Stats for Administrators)
It is progressing in spite of everything...
Alain
Alain,
Thanks for input - sounds good.
Just for clarity and my understanding could you confirm:
1. Does not appear to be a Hosting issue
2. If a user has selected to use Captcha in the Front End then activating the Invisible Captcha Plugin causes a delay in backend?
3. jDownloads Stats module appears to cause the delay?
4. If it is the jDownloads Stats module it is when in position 'cpanel'.
Colin
Hi,
for me disabling mod_jdownloads_admin_stats (jDownloads Stats for Administrators) does not change anything in terms of the slow backend issue.mod_jdownloads_admin_stats is also enabled on my local site, where I do not see the issue.
Best regards Klaus
Hello to all,
Colin
The hosting of the site is not involved.
I reinstalled the plugins and modules that could be involved.
In frontend I solved the problem by disabling in view users group. view captcha. if I activate recaptcha in view users group, it does not work anymore, it resets the page.
In the backend :
jDownloads Stats module appears to cause the delay?
most probably.
We get
60197.80 ms
Application: beforeRenderModule mod_jdownloads_admin_stats (jDownloads Stats for Administrators)
I continue my research on backend.
Alain
Alain
Good Info!
jD Does not support the so called 'invisible Captcha' plugin but it does support the CAPTCHA - reCAPTCHA one ok.
Is your adminstats module using position 'jdcpanel' or position 'cpanel'?
Is your backend administrator template Isis or Hathor? Not sure if we checked out AdminStats in Hathor!!
Thanks
Colin
Hello to all
Colin
jD does not support the so-called "invisible Captcha" plugin but it does support the CAPTCHA - reCAPTCHA.
Yes.
Does your adminstats module use the "jdcpanel" position or the "cpanel" position?
cpanel
The administrator model is Isis.
The problem of slowness seems to be caused by the following request.
Duplicate queries: #33
SELECT a.*, u.name as created_by_user_name, u.email
FROM `suj_tags` AS a
LEFT JOIN suj_users AS u
ON a.created_user_id = u.id
WHERE `a`.`access` IN (1,1,2,3)
AND `a`.`parent_id` <> 0
AND `a`.`published` = 1
ORDER BY `title` ASC, a.title ASC
LIMIT 20
Originally to "save time" I had tried a global reinstallation of the old site hosted elsewhere. But the operation proved to be bad, so I preferred a "clean" installation. It is not excluded that some non-compatible data still exist, even if I can not locate them.
Alain
Alain,
Isis is where most testing has been done - so goodCould you see if switching adminstats moduleto jdcpanel makes any difference( I have tested that config but still cannot replicate!!! so your work is very helpful)
Also if you disable the adminstats module does it affect the delay?
Colin
Hello to all,
Colin
I have not given up, but I am also struggling with my own application in reconstruction, so I cannot devote much time and answer with enough seriousness to the problems we are dealing with at the moment.
This should be easier in a few days...
Anyway, as far as security adminstats is concerned, I deactivated it directly from the database, unfortunately this hasn't had any positive effect and it's strange, the problem is upstream...
I searched through the code and found that adminstats is well installed but some curious elements caught my attention.
The config.xml file makes no mention of adminstats and therefore no possible label, while the installation script seems to have been executed normally.
I don't know all the structure of the jdownload code so it's difficult to get a more precise idea of the real cause without spending a lot of time on it.
Alain
Hello to all,
Colin
Do I have good news or not?
I had disabled mod_jdownloads_admin_stats directly from the database. purge all possible caches and no visible improvement on the speed of jdownload backend execution.
By the way, I had reinstalled the jdownload component again and used the latest php version available 7.4.11 but without results.
A few days later to download a new version of a software, I discover that jdownload in backend works quite normally, fast and without display of the stats module. I reactivate the module and jdownload still works perfectly as an administrator.
A "priori" nobody else than myself has access to all the administrative functions, I can't explain this mysterious change. I will see if in a few days the behavior is still stable.
Alain
Probably the cause of this change is due to a network maintenance performed two days ago by the host.
Alain
That is indeed most interesting. We had a suspicion it is a site related challenge as despite our best efforts we have been unable to reproduce.
Could you please ask your site people what they did as an upgrade or simiar.
Best wishes
Colin
Hello to all,
Colin
Here is the host's answer;
"As we stated in our email it was network maintenance - so it had nothing to do with your Joomla! plugins.
Most likely the problem was on your designer's end.
Please let us know if you've any further questions, so we will be able to help you out with them."
This answer does not surprise me, it was not a question of finding a guilty for the anomalies encountered, but to locate the modifications made to possibly prevent, by coding a component differently.
By experience, I know the difficulties to manage this kind of network, and despite all the knowledge it is sometimes impossible to determine with certainty, why.
We won't know more... for the moment.
Alain
Alain,
Thanks for trying with web host.
Wonder if they changed php or MySQL or Apache?
Colin
Hello to all,
Colin
I would bet for a change of PHP.
Alain ;D
I have same problem on a clean local install - WS2016, PHP 7.4.11, Joomla 3.9.24
If I dissable the network card backend work fast, when I enable it backend starts working very slowly.
Meglu,
Thanks for Reply. Confirms suspicion that jD backend is waiting for a network response from somewhere and then times out.
To aid locating problem:
Do you have Akeeba tools active?
Which version of PHP?
Which of the five Security options are set to Yes:
1. 'Protect your Download Directory' - default is No
2. 'Activate Hot Linking Protection' - default is Yes. Are there any sites in 'Websites allowed to Hotlink'?
3. 'Block when no Referer' - default is No
4. 'E-Mail Address concealing' - default is Yes
5. 'Activate IP Blocking' - default is No.Thanks
Colin
In my case the problem was on the page "jdownloads.net".
When i disable it in HOST Windows file, backend starts working fast.
Hi
Good input :) Understand you have a local version with Xampp or similar.
That would fit the bill as it would be jD specific and consistent with a time out.
I will look in that direction
Colin
PS will send you a PM
Hi,
Thanks for jDownloads, it's a very useful tool.
I am facing very slow backend for jDownloads too, that is why I dig up this topic.
I am on php8.0/MySQL5.7 hosted with Gandi.
I tried several options suggested here without improvement, especially purge all possible caches and installing again jDownloads.
Does anyone succeded to solve this issue?
Hi Youp,
please try the attached (unzipped) file.
Copy it to administrator/components/com_jdownloads/helpers/ and overwrite the old file.
Please test it afterwards again and tell me your result.
@Klaus101
Could you update to 3.7.3 - this could be the accessing of the help pages causing the challenge
@all
Also which browser are you using - Google have changed some things recently!
Colin
Hi Arno,
Thanks a lot for proposing a solution. Unfortunately it does not speed up the backend for jdownloads.
----------------------------------------
See next post ColinM
Hi Arno,
It works!!
I put your file in the wrong folder. Thanks a lot!