Save new article (create a new ID) very slow in category with many articles #10567
Labels
Comments
|
That is a good guess, but in most cases we can avoid guessing
(If anyone knows a better way, please reply here) It would be better to do this in a duplicate website, but it should not be a problem to do in a live website if you are careful 1 . Edit file: /libraries/legacy/controller/form.php Goto to the bottom and find last lines: add before return true; (copy paste carefully, not to make syntax error) 2 . Login as "admin" or as the username that you have used above, if you want a different user then change 'admin' above 3 . Open a new browser TAB and Enable Joomla Debug in Global configuration 4 . Open a new browser TAB and Create a new article in the category with the many articles and click save (and you will get a screen with the Joomla Debug console) 5 . In the other browser TAB, disable the System Debug in Global configuration, so that your website stops displaying it The step 4 should have given you the info that is needed (like the picture you see below), e.g. click the "Database Query" slider to find slow queries, and provide them here |
|
Thanks for answer. 2 duplicate found! 24 Query Types Logged, Sorted by Occurrences. OTHER Tables: I attach two image before of the joomla debug Thanks a lot. |
Did you get an almost empty screen
If you did not get, then the queries above is after the form has been saved (it is the form reloading) and then it is of little use. I say this because it seems that the above is not the "150 seconds" that you had said previously |
|
Hello |
|
With the testing code you should get an almost empty screen ,
|
|
First of all, thanks for answer. |
|
Hello { Below the "slow query" that I see in RED: UPDATE SET WHERE AND
|
|
Hello ok, i see now, i had asked you, to add it before:
please move the code just above: |
|
So after "..($model, $validData);"? |
Yes exactly, that is what i said in my first message |
|
Sorry. as you can see here$this->postSaveHook($model, $validData); }I can't see an empty page Query Time: 35.62 ms After last query: 0.30 ms Query memory: 0.018 MB Memory before query: 10.517 MB UPDATE SET WHERE Query Time: 68.07 ms After last query: 2.21 ms Query memory: 0.024 MB Memory before query: 12.674 MB Rows returned: 1 SELECT COUNT(*) FROM sDg_content AS a LEFT JOIN LEFT JOIN sDg_users AS uc LEFT JOIN sDg_viewlevels AS ag LEFT JOIN sDg_categories AS c LEFT JOIN sDg_users AS ua WHERE (a.state = 0 OR a.state = 1) |
|
You should see this almost empty screen otherwise it means it did not work, did you login with username ?: Finally, also instead of you can also use (remember to remove it after testing to avoid effecting other users): |
|
Hello, After in general config So After save an article in the "large" subcategory the query are that I post above. did you login with username ?: What I am in wrong? |
|
Yes now it looks right now post
they should now reveal, if this is a performance issue of Joomla or of some 3rd party plugin |
|
Yes. After to save article I receiveErrore HTTP 500 Microsoft Edge non riesce a trovare questa paginaBut here are Profile information Ad here the query info in red |
Ok i see the configuration you have
will post back in a few days |
|
Hello |
|
I experience the same issue, one category with more than 5000 articles, takes about 10-15 sec to save (first time). This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/10567. |
|
Hello, I am sure I am not alone. I am a webmaster, not a php programmer or MySql programmer. I hope the developers of Joomla! fix this problem. Is this the right place to indicate the issues for them? |
|
I confirm the findings of @alikon , the issue is with checking for duplicate alias inside the given category,
The issue is fixable , just by adding the missing index to alias column, the query then runs in milliseconds ... |
|
please I have the same problem could you explain how I can fix th issue?? @ggppdk This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/10567. |
|
@ggppdk Please explain what I must do when you say: I have changed in the path ../administrator/components/com_content/models/article.phpfrom -> if ($table->load(array('alias' => $data['alias'], 'catid' => $data['catid']))) to -> if ($table->load(array('catid' => $data['catid'], 'alias' => $data['alias'])))nothing change about time. So Which is the fix that is possible to do for it? |
|
Do not hack the Joomla DB schema i am guessing that this index will be in the next release of Joomla ... or similar one In
Excute the above in phpmyadmin (or in the DB management tool that you are using)
Then test to see the effect, note that there is a chance that there is 2nd performance issue,
after testing you should remove the index, for your live site wait for next Joomla release |
|
Ok. go to the DB and putALTER TABLE
|
|
You should notice with the hack proposed by @ggppdk + debug enabled that Ok. in Nothing change in time to save article. What Am I in wrong? — |
|
@pici65 it would take, 10-30 seconds or more depending on the size and load of your website also to avoid guessing of what is happening you should apply my testing instructions above:
thus i don't have the needed information to answer you |
|
@ggppdk ALTER TABLE myprefix_content ADD INDEX JHS_alias (alias); Also I wait 120 seconds to save a new article with a very new and anomaly alias I repeat If I save this article in an empty category I obtain the perfect saving in 3 seconds. |
|
are you really typing
On 3 June 2016 at 10:46, pici65 notifications@github.com wrote:
Brian Teeman |
|
I could not test on large categories because Joomla Debug Console hits PHP memory limit:
but i did test on smaller categories (with less articles) and it does because for 8000 articles in a category: My estimation makes the total of e.g. 120 seconds that you are seeing |
|
@ggppdk Thanks. |
|
It is an old issue: There is already a suggested fix when using MySQL DB:
|
|
So.. we wait an answer-patch for this last version of Joomla! If I understand.. |
|
Just merge the damn patch as its obvious the project doesn't care to On Sunday, June 5, 2016, Georgios Papadakis notifications@github.com
|
|
You were the one demanding that pr needed applying to non mysql databases
|
|
I still stand by that; I don't think the project should penalize people running non-MySQL engines but at the same time if nobody's going to make the effort to do it then at this point who cares. |
|
Sorry I do not understand. I see here this:
But I do not understand. `--- table.php.orig 2015-10-28 17:44:49.199224888 +0100
/**
@mbabker "Just merge the damn patch". Is what I posted here? Is a portion of PHP to "patch" in specific path of a specific page? Thanks |
|
@pici65 I have the same problem anyone can explain how resolve it?? |
|
This one is the "damn patch" ;-) PR https://github.com/joomla/joomla-cms/pull/8563/files Here PR concerning index but see comment of @richard67 #10739 (comment) |
|
@bertmert thanks. Thanks |
|
There's a button "View". With it you can open a second tab with whole code and compare easier or click button "Raw". Then you can copy/paste the whole file or save it via browser. And sorry, I don't know anything here! ;-) Just wanted to help a bit... |
|
@bertmert Thanks. |
|
@pici65 do you find the lines for the patch?? |
|
@ggppdk & all are you sure that you are testing using the latest staging or at least 3.6.0 beta1 ? |
|
About the table ordering queries,
|
|
Cause #8576 which was merged on 3.6.0 have done something better for reoder() |
|
yes, you are right but the reorder method is not removed from API, and it is still problematic for any other component or any other code that uses it |
|
@alikon and @ggppdk |
|
@pici65 please before doing strange things please test with your large dB on joomla 3.6.0 beta and report back thanks |
|
@alikon update and test done. so We wait last stable version for site production. |
|
@pici65 Can you close this issue, cause we have others open for the
reoder() and for alias index , and your seems solved with 3.6.0 thanks
|
|
I prepared a code example at csthomas#6 to ask you whether this is the right way? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce the issue
Hello
in category with many articles
is very slow to save another one.
Seems the problem concern to create a new ID.
For example sub-category "World" in category "News"
Category "News" is empty
"World" has 8000 articles.
Save a new one in "World" with few text = 150 seconds.
Save again here with other text, more long (for example 3000 characters) = 5 seconds.
If I save in the category father "News" I save in 3 seconds.
After I save in "World" 3 seconds.
So the problem is to save directly in the category with 8000 articles and to create a new ID.
Assets tables do no has too much content.
The server is dedicated.
I can't find the problem and the way to solve.
Expected result
Actual result
System information (as much as possible)
php 5.6.21
database version 5.5.5-10.0.25-MariaDB
Additional comments
The text was updated successfully, but these errors were encountered: