From: Joby W. <joby@u.washington.edu> - 2004-04-20 16:35:48
|
The Demo site is back up. There were two issues with the migration: 1) cvs update of index.php was messy so manual editing was required. 2) Pear/Config needed more explicit calls to locate files 3) Bad config settings in config.ini 4) some errors are being tossed on the site -- looking into now. jbw -- Joby Walker C&C Computer Operations Software Support Group |
From: Reini U. <ru...@x-...> - 2004-04-20 17:15:29
|
Joby Walker schrieb: > The Demo site is back up. > There were two issues with the migration: > > 1) cvs update of index.php was messy so manual editing was required. > 2) Pear/Config needed more explicit calls to locate files > 3) Bad config settings in config.ini > 4) some errors are being tossed on the site -- looking into now. I've made some more fixes to the new IniConfig. WikiUserNew DB statements had to be changed from '"$variable"' to "'$variable'" And every comma in a statements has to be double-quoted: "SELECT var1,var2 blabla" The ini parser is quite slow and problematic, so we will probably have to store the parsed config setttings in the session. I'm not really convinced that the new php-script parsing is better than the old php-internal parsing. Most dba modules have a inifile handler also, which is for sure faster and easier. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Joby W. <joby@u.washington.edu> - 2004-04-20 18:39:54
|
Reini Urban wrote: > The ini parser is quite slow and problematic, so we will probably have > to store the parsed config setttings in the session. Yeah I've noticed that it is slower in my tests -- my test boxes did not have as much load as the sf.net server. And storing in the session wouldn't work because you need the config settings to access the session info. The issue seems to be the Pear_Config module. By eliminating the comments from the config.ini, the demo site is now more responsive -- this is because the Pear_Config module's parse function pays attention to every line -- not just settings, and I'm pretty sure the sf.net site isn't using an accellerator (like Turck-mmcache) so since it is php rather than C it needs to be compiled. There are some ways to resolve this: 1) Precompiled .ini: We can use the Pear_Config to generate a php file with all of the settings. 2) Split off "advanced" settings: we could move the advanced settings (that require Pear_config) to a different .ini and then use the php function parse_ini_file for the vast majority of settings. The "advanced" settings are mostly the the SQL statements. 3) Different config file format: Apache conf, xml, genaric .conf might be faster... 4) Chuck the different config file formats and go back to php files. #1 and #4 would offer the greatest speed savings since it takes parsing out of the picture. #2 Could get messy fast #3 XML is the only format that might go faster, but php would be easier than XML. I'll start looking into #1. jbw > > I'm not really convinced that the new php-script parsing is better than > the old php-internal parsing. > Most dba modules have a inifile handler also, which is for sure faster > and easier. |
From: Reini U. <ru...@x-...> - 2004-04-20 18:54:29
|
Joby Walker schrieb: > Reini Urban wrote: >> The ini parser is quite slow and problematic, so we will probably have >> to store the parsed config setttings in the session. > > > Yeah I've noticed that it is slower in my tests -- my test boxes did not > have as much load as the sf.net server. And storing in the session > wouldn't work because you need the config settings to access the session > info. > > The issue seems to be the Pear_Config module. By eliminating the > comments from the config.ini, the demo site is now more responsive -- > this is because the Pear_Config module's parse function pays attention > to every line -- not just settings, and I'm pretty sure the sf.net site > isn't using an accellerator (like Turck-mmcache) so since it is php > rather than C it needs to be compiled. > > There are some ways to resolve this: > > 1) Precompiled .ini: We can use the Pear_Config to generate a php file > with all of the settings. > 2) Split off "advanced" settings: we could move the advanced settings > (that require Pear_config) to a different .ini and then use the php > function parse_ini_file for the vast majority of settings. The > "advanced" settings are mostly the the SQL statements. > 3) Different config file format: Apache conf, xml, genaric .conf might > be faster... > 4) Chuck the different config file formats and go back to php files. > > #1 and #4 would offer the greatest speed savings since it takes parsing > out of the picture. > #2 Could get messy fast > #3 XML is the only format that might go faster, but php would be easier > than XML. > > I'll start looking into #1. ok, I'll look into the dba-inifile handler then. >> I'm not really convinced that the new php-script parsing is better >> than the old php-internal parsing. >> Most dba modules have a inifile handler also, which is for sure faster >> and easier. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Joby W. <joby@u.washington.edu> - 2004-04-20 19:59:35
|
Reini Urban wrote: > ok, I'll look into the dba-inifile handler then. Is this the inifile handler for DBA? This could work well, but does it handle special characters (e.g., " and &)? Looks like it also requires a compile time option. jbw |
From: Joby W. <joby@u.washington.edu> - 2004-04-20 21:49:27
|
Sigh... Or 5) Joby could actually pay attention and notice that Reini's updated SQL queries will allow the php function parse_ini_file to work... Joby Walker C&C Computer Operations Software Support Group Joby Walker wrote: > Reini Urban wrote: > >> The ini parser is quite slow and problematic, so we will probably have >> to store the parsed config setttings in the session. > > > Yeah I've noticed that it is slower in my tests -- my test boxes did not > have as much load as the sf.net server. And storing in the session > wouldn't work because you need the config settings to access the session > info. > > The issue seems to be the Pear_Config module. By eliminating the > comments from the config.ini, the demo site is now more responsive -- > this is because the Pear_Config module's parse function pays attention > to every line -- not just settings, and I'm pretty sure the sf.net site > isn't using an accellerator (like Turck-mmcache) so since it is php > rather than C it needs to be compiled. > > There are some ways to resolve this: > > 1) Precompiled .ini: We can use the Pear_Config to generate a php file > with all of the settings. > 2) Split off "advanced" settings: we could move the advanced settings > (that require Pear_config) to a different .ini and then use the php > function parse_ini_file for the vast majority of settings. The > "advanced" settings are mostly the the SQL statements. > 3) Different config file format: Apache conf, xml, genaric .conf might > be faster... > 4) Chuck the different config file formats and go back to php files. > > #1 and #4 would offer the greatest speed savings since it takes parsing > out of the picture. > #2 Could get messy fast > #3 XML is the only format that might go faster, but php would be easier > than XML. > > I'll start looking into #1. > > jbw > >> >> I'm not really convinced that the new php-script parsing is better >> than the old php-internal parsing. >> Most dba modules have a inifile handler also, which is for sure faster >> and easier. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk |