Site toooooo slow
jason342 - February 10, 2007 - 10:18
Certain aspect of the site is soooo slow such as preview, submit, add block, etc... while other aspects are normal.
I know this can't be the fault of the server because when I am working on my files and folders sin cPanel everything is super fast.
So why is drupal being so slow? It's really frustrating.
Data
Without any further data (hardware, setup, modules in use, amount of simultaneous users, "what is slow"), all we can do is guess and start another "Pulling Teeth (Tm)" Q&A session.
You can take a look at page generation times and the amount / length of queries with help from the devel module.
--
The Manual | Troubleshooting FAQ | Tips for posting | How to report a security issue.
Who is your hosting
Based on the little info given, I'd start with checking your database performance out. Devel is definitely the way to go. Out of curiosity, Who is your hosting company?
--
John Forsythe
Blamcast - Custom theme design and more...
Have you enabled caching?
Have you enabled caching?
more
These sound like aunthenticated users, so caching is immaterial.
Since you posted in the 5.x category, have you enabled the CSS compression feature? I have pages that have as many as 9 CSS's on them. The performance advisor I used recently listed most of my problems as related to that.
Nancy W.
proudly running 3½ sites on Drupal so far
Similar problem of slow SUBMIT node
I am facing similar problem on one Drupal site. The submit completes normally but takes almost 90 to 100 seconds after userclick. Every other part of the site is OK - less than 3 ~ 5 seconds after userclick. Some other submits in the site related to admin works just fine. It is when authenticated user tries to submit a node, thats where the problem happens all the time.
I activated the devel module to capture the page generation data. Everything seems normal there as shown below.
Executed 391 queries in 76.9 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 407.49 ms.When does devel start its timer? If devel says total page execution time of 407.49 ms (about half a second) and actuality is 90 ~ 100 seconds, then where is the rest of the time going? It is almost like a 90 second delay is being called before the devel clock starts.
My Config:
- Drupal 5.1 is installed on a shared host - I have access to cPanel and phpMyAdmin.
- Drupal site has 190,000 nodes (real small), 190,000 url-aliases as well.
- Site performance settings: it does not make any difference : i tried no caching or normal caching.
- The CSS aggregation (On/Off) makes no difference either.
- Apache level compression (On/Off) makes no difference either.
- Thinking that I may have made some changes to the theme thats causing this, I tried changing theme to drupal 5.1 oem themese (phptemplate or vanilla chameleon) - still makes no difference.
If the problem is not in MySQL (as shown by devel), then where is the problem? What can I do to further diagnose the problem?
Thanks in advance to all the good & helpful Drupal folks.
Look at the host
I had even worse performance than that on my previous host, even with a site with only 200 nodes. The problem was an overloaded server. After I switched hosts, the site is usually faster than my local PC.
NancyDru (formerly Nancy W. until I got married to Drupal)
There are two HTTP requests going for each SUBMIT node
I did a little more digging using Firefox + Firebug and found this:
When user clicks on SUBMIT for a node,
- the browser sends one http post request to the drupal server. Drupal server does its job of creating the node, gives a 302 moved temporarily error and gives the url of the newly created node to the browser. It also includes a full html page that does not get displayed. That html can be seen in Firefox/firebug. The html also had the devel part showing 220 queries in 25 seconds - no performance bottleneck there.
- The browser again sends http get request to obtain the temporarily moved page. This response of this http get is displayed on the browser screen. The html response has the devel part that shows only for the get node.
My questions:
- Does browser wait for sometime if it gets 302 moved temporarily?
- can the two trips (post / get) to Drupal server be avoided?
Thanks in advance for your help.
Some further hints for everybody else
I asked Rajeev for help and he gave me following hints. I put it herer for everybody who it could help in the future:
---------------------------
Yes - I solved the problem. You must be using gsitemap or xmlsitemap module? If you activate the submit sitemap on adding node, then that gsitemap takes forever (almost 60 seconds).
The modules than can do such updates are:
- gsitemap
- xmlsitemap
- ping-o-matic
- some other services i dont remember offhand
I hope this helps and you get an idea where to look. I thought it was a DB issue - but it is not a DB problem
---------------------------------------------------------------------------
Tank You very much for Your hints!
I don't have in my installation any of the modules You mentioned.
I looked also for similar modules but couldn't find first anything with similar functionality You described.
Now Im digging further in Drupal communities looking for more information to problems connected with adding a node.
-----------------------------------------------------------------------------
What did you find in devel? Devel tracks database IOs - if your database response times look all good then the issue has to be somewhere outside database and devel can not help with that.
But if some module is sending out a email or doing some tcp/ip connection when you submit a node, then that will slow. Sending emails via php is not a problem - but if it is trying to open tcp/ip socket (module called email verify does that) then the response time will depend on the network and remote server. Do you use workflows, using some notification of some kind?
Did you solve the slow submit problem?
You still have the problem or solved now? Please do post how you solved the problem.
If you are still living with the problem, please post your devel query times here. You will have to configure devel to trap redirects so you get times for two browser<->server ios - first post query followed by the get query. Also post a list of modules that you have activated.
Haven't found the solution yet.
Rajeev:
What did you find in devel? Devel tracks database IOs - if your database response times look all good then the issue has to be somewhere outside database and devel can not help with that.
But if some module is sending out a email or doing some tcp/ip connection when you submit a node, then that will slow. Sending emails via php is not a problem - but if it is trying to open tcp/ip socket (module called email verify does that) then the response time will depend on the network and remote server. Do you use workflows, using some notification of some kind?
--------------------------------------------------------------------------------------
Stefan:
Yes I think also it must be some kind of action which is bound in to “submitting” and waits for something.
Now I am looking for it. I haven’t solved it yet. I am still looking for the bug.
Here the Devel times.
As You see it’s very similar to what You had .
DB’ no problem the time is being “eaten” somewhere else.
Executed 1209 queries in 271.04 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 65758.19 ms.
Yes I'm using workflow engine. Now Im looking into it.
Similiar problem solved - Advanced cache 5.x-1.6
Hello Rajeev,
I solved the problem last night.
The problem was caused by a modul:
Advanced cache 5.x-1.6 Introduces advanced caching techniques to Drupal core
Similiar situation as You faced it, but different module.
I identified it with help of devel output.
At the end I was wondering why there are over 200 inserts into DB made by this cache module.
The inserts where quick, but then I came to the idea not the insert but computing of the inserted values took the time.
After I deactivated the module, the time for the submit sunk to 3,5 sec ( from 65 sec) J
Of course there are to many active modules and many of them are not needed.
But now I solved the major issue.
Thanks for all Your hints