Forums / Developer / eZ - what is ripping our resources?

eZ - what is ripping our resources?

Author Message

Gunnstein Lye

Tuesday 20 April 2004 7:06:11 am

Ok, since other eZ guys are working on your site, I will not go into specifics. Just a few comments:

You said: "Why empty all the cache blocks when the content is beeing published? Why not just empty the content for THAT page?"

Because the published object sometimes influences the appearance of the cache blocks. How can eZ publish know which cache blocks contains code that will be influenced by the change in the published object? You would need an advanced artificial intelligence to check that.

You said: "So, if I use this "ignore_content_expiry", and the editors publish their content, will the content then imediately be updated for the users?"

Cache blocks where "ignore_content_expiry" is used will NOT be updated on publishing. They will only be updated when you clear them manually, as in my previous comment. This is good when you have complex pieces of template code that are rarely influenced by content publishing, or template pieces that do not need to be continuously updated (you could clear cache blocks once per day, for instance).

K259

Tuesday 20 April 2004 7:18:04 am

Tnx for replies. I guess almost 99,9% of our daily updated content comes from editors who just edit and create pages in the most common classes, so not so much content which we can wait doing cache-clearing on. This type of content needs to be viewable immediately.

Regarding to:
"You said: "Why empty all the cache blocks when the content is beeing published? Why not just empty the content for THAT page?"". Sorry my fault..I think I have to give the same explanation as Bjørn K. did earlier this day: I'm not doing so well today, unfortunately sick, so not capable to think so much :p

Ekkehard Dörre

Monday 26 April 2004 3:02:14 pm

Hi,

You saw this post from emil?
http://ez.no/community/forum/developer/performance_mysql_add_index

But most of the time is rightmanagement and template

Greetings ekke

http://www.coolscreen.de - Over 40 years of certified eZ Publish know-how: http://www.cjw-network.com
CJW Newsletter: http://projects.ez.no/cjw_newsletter - http://cjw-network.com/en/ez-publ...w-newsletter-multi-channel-marketing

Gunnstein Lye

Tuesday 27 April 2004 12:16:50 am

Thanks Ekkehard, I've notified the db guys about this.

Bruce Morrison

Tuesday 15 June 2004 4:44:58 pm

Hi Zinistry

Did you find a solution?

Cheers
Bruce http://www.designit.com.au/

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

K259

Wednesday 16 June 2004 5:05:32 am

(security issues will not be discussed in the following)

Our eZ publish solution was implemented by eZ systems, they are also responsible for upgrades. Their recommendations have always been followed regarding compilation of mysql, different settings in php, different php accellerators and apache-settings.

One of the first problems we had from the beginning, was detected after a long period of time with server ups & downs and slow processing.

- Mysql was hanging when our visitors clicked on some spesific objects in the structure. These objects were part of the shopping-module. After a lot of problems with this, and after eZ had checked our server-configuration, but didn't find anything wrong or misconfigured, we got an advice to recompile mysql, but without any success.

It was not so easy to find out what caused the hanging of mysql, so I started to test different things, checked the logs and so on, and finally tested some objects, because I notified that something strange was happening when some objects were clicked and processed. I gave the information to the eZ crew, and they tested this also. The hanging was caused by a wrong placed sql select query in the code, and a check had to be implemented also.

This problem was solved, but we still experienced hanging and needed to restart our server every second day.

- Another problem we experienced after an upgrade(to v. 3.1 I think) was that the ezsession table was locking. The user couldn't log in, and the frontend got access denied. We tried a lot of things(change different settings in mysql). We then did a check on the tables, and run a repair tables. The problem was fixed, but only this time. This happened a few weeks. The session timeout was decreased, without no success. We then tried to use mysql with it's own compiled "modus", and it solved the session problem after a lot of testing. We have tried everything also earlier with different compilations of mysql, but at last, this worked.

Still problems:

- Bugs in the search-module: We experienced that our eZ publish site went down when there were a lot of people using search at our site. I tested this for a while to be sure what was actually happening. I gave examples to eZ Systems and showed them IRL what was happening, to let them know that this was a serious bug, and these problems made people able to take down ez sites. The eZ crew released later on some bug-fixes.

- Problems with the reindexing in v. 3.1 of ez publish (in the search-module). This resulted in some problems with speed, but is fixed in newer versions.

- Problems caused after upgrade: Our database was not completely 3.2 compatible after the upgrade to 3.2, which gave us some problems, but fixed in the next upgrade.

- A serious problem we got fixed last month was that the left-menu (developed by eZ in the beginning of the web-project) was generating over 180 sql queries every time the menu was clicked to process new pages. Even if this menu was cached, the number of sql queries was heavy. eZ Systems reduced this menu with about 80 queries after the last fix on our site. In this menu the enum-datatype was used, which makes the processing more heavy than using a selection datatype. This is today changed.

- Another problem was that our system was not optimized with cache-blocks from the beginning. This was fixed in 3.3.

- Another known problem is the indexing which is beeing proceeded when publishing content. No greater changes for our installation is done in the admin-interface for increasing the speed of publishing, so it takes up to 50 sec. to publish content in some cases.

eZ publish 3.4 will possibly solve this problem, because indexing can be put in a cron-job instead of when the users publish content. eZ Systems recommend that we upgrade this summer to 3.4 , to decrease the publishing time.

- Our last known problem is a class which in the template have a functionallity to list all child objects. It is possible to view a single chapter, but also possible to list all the chapters through "list all chapters". If there are a lot of content and pictures in the single chapters, and eZ publish is listing all these chapters in a template, the system hangs and gives error:

Fatal error: Allowed memory size of xxxx bytes exhausted (tried to allocate 32 bytes) in /../lib/ezxml/classes/ezxml.php on line 470

We need this functionality of listing all chapters, because it's necessary to list all these chapters when printing important documents. I removed this functionality from the templates a week ago, and included these problem-files in the robots.txt so that searchengines not shall index these documents, because this kills "the server".

The status today is that the speed has increased in the frontend, we have found a lot of critical bugs, which has helped eZ publish to be more stable, secure and faster, but we still got some errors in the logs, and apache crashes/hangs sometimes.

It would be nice to get more hints on what can be the problem when apache goes down, and needs to be restarted. It seems (I've checked our logfiles), that apache goes down, when different search-engines tries to index special pages/objects), but I have to test this a little bit more. Other things which hangs the system, is when a large amount of content is beeing published in the admin-interface, but I hope the delayed indexing in v. 3.4 will solve this problem.

Wünsche euch einen schönen Tag.

Z.

Bruce Morrison

Wednesday 16 June 2004 5:36:07 pm

Thanks for the reply. I don't envy you at all.

Is the site a public one? Is it possible to post the URL.

Cheers
Bruce http://www.designit.com.au/

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

K259

Tuesday 31 August 2004 2:26:27 am

Our site is now going faster, after years of frustration from our visitors and editors using eZ publish.

The problem is (which I indicated more than a year ago; earlier postings)) that the eZ publish system has to many database-queries so that the publishing process makes everything hang(both the frontend and the admin).

We gave it a last chance a week we had really huge problems:
I recommended that we closed the site for publishing, just to show the eZ Crew that the admin-part was the problem. When publishing was disabled, the site went perfect.

After a couple of years with ez publish content management system problems, eZ Systems has now reduced the number og queries, and optimized the heaviest ones.

Georg Franz

Tuesday 31 August 2004 4:48:25 am

Hi Zinistry,

I am currently using eZ 3.4.1 and I am almost happy.

Only two things are not optimal:
a) Template Compiling: If you have many sitedesigns and change many templates (or upgrade to a new version) you have to go offline for 1-2 hours because the compiled template creation process takes much power. But that is okay because that should happen only 1-2 times a year.

b) The built-in search-engine: I don't use it any more at my user sites. I use mngosearch instead (btw. that program is also used by mysql.com *g*) - http://search.mnogo.ru/

mngosearch is incredible fast and has a lot of features. The only disadvantage: I can't use it at the admin site.

Best wishes,
Georg.

--
http://www.schicksal.com Horoskop website which uses eZ Publish since 2004

K259

Tuesday 31 August 2004 12:41:23 pm

Nah, there are still some problems with our eZ publish site after changes from the eZ Crew. The stability and performance has increased, but not without concequences.

Indexing for search has been put in the cronjob instead, so the content are not immediately searchable. There are some caching-problems with the 3.4 version, and content which are fetched and some other content are not beeing displayed.

There are also a bug with the "move-function" in 3.4. When an object is moved, you have to refresh the site in the browser with f.ex. F5 on the keyboard, then you can see your new path. But when you publish, the object is available both at the old path and the new path.

Gunnstein Lye

Friday 24 September 2004 12:28:01 am

For your information: 3.4.2 is released now, and it contains several important cache related bug fixes.