|
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.
|
