EzPublish DB : 100 mo

«

Previous topic

|

Install & configuration

|

Next topic

»

Author	Message
Nabil Alimi	Thursday 04 August 2005 4:03:02 am Hi, While performing a backup, I've noticed that the database of my site was 100 MBytes large. Is that "normal" ? The biggest part of it is the table <b>ezsearch_object_word_link</b> which is 85 MB large. Is there a way to reduce it without disturbing Ezpublish functions ? My blog : http://www.starnab.com/ezpublish / http://www.starnab.com/ / http://www.assiki-consulting.com eZ Publish Freelance developper. Feel free to contact me +33 674 367 057 nabil at assiki d0t fr
Gabriel Ambuehl	Thursday 04 August 2005 5:14:27 am ezsearch_object_word_link is only used for the search function. I think you could skip the data in that table if you're content with regenarating your search indexes after a reinstall of the backups. However, try compressing your MySQL dump. It will likely be muuuch smaller after that. SQL statements can be compressed very well. Visit http://triligon.org
Nabil Alimi	Friday 05 August 2005 3:58:56 am But I can I freely truncate this table ? Won't it damage my installation ? I'd like to just to light my database. My blog : http://www.starnab.com/ezpublish / http://www.starnab.com/ / http://www.assiki-consulting.com eZ Publish Freelance developper. Feel free to contact me +33 674 367 057 nabil at assiki d0t fr
Gabriel Ambuehl	Friday 05 August 2005 4:50:24 am Well if you truncate it, searching won't work until you regenerate search index. Visit http://triligon.org
Xavier Dutoit	Friday 05 August 2005 7:03:01 am Search indexes take a lot of space. You can disable the search feature if you want to save space or try an external search engine (ez has plugs in). However, that's likely that it's going to take space too, but into another storage than your DB. You can safely not backup this table, and in the case you have to restore, regenerate the index. This being said, don't trust anyone on backup issues and you'd be wise to pratice restore before you really need it. The last sentence is a definitive proof that I'm not wise, in case anyone wonders ;) http://www.sydesy.com

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.

eZ debug

Timing:	Jan 19 2025 11:45:43
Script start
Timing:	Jan 19 2025 11:45:43
Module start 'layout'
Timing:	Jan 19 2025 11:45:43
Module start 'content'
Timing:	Jan 19 2025 11:45:43
Module end 'content'
Timing:	Jan 19 2025 11:45:43
Script end

Main resources:

Total runtime	0.0273 sec
Peak memory usage	2,048.0000 KB
Database Queries	3

Timing points:

Checkpoint	Start (sec)	Duration (sec)	Memory at start (KB)	Memory used (KB)
Script start	0.0000	0.0079	589.1563	152.6250
Module start 'layout'	0.0080	0.0050	741.7813	39.4453
Module start 'content'	0.0130	0.0121	781.2266	93.2422
Module end 'content'	0.0251	0.0022	874.4688	38.3047
Script end	0.0272		912.7734

Time accumulators:

Accumulator	Duration (sec)	Duration (%)	Count	Average (sec)
Ini load
Load cache	0.0026	9.5251	14	0.0002
Check MTime	0.0011	4.0291	14	0.0001
Mysql Total
Database connection	0.0012	4.3666	1	0.0012
Mysqli_queries	0.0043	15.8132	3	0.0014
Looping result	0.0000	0.0988	1	0.0000
Template Total	0.0018	6.5	1	0.0018
Template load	0.0009	3.1978	1	0.0009
Template processing	0.0009	3.2450	1	0.0009
Override
Cache load	0.0006	2.3105	1	0.0006
General
dbfile	0.0003	1.1181	8	0.0000
String conversion	0.0000	0.0472	4	0.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

Usage	Requested template	Template	Template loaded	Edit	Override
1	print_pagelayout.tpl	<No override>	extension/community/design/community/templates/print_pagelayout.tpl
Number of times templates used: 1 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs