Just installed 4.2 on my test system and noticed that page refresh appears to be much slower.
Whereas with 4.1.6, standard theme, blocks: GECOM Statistics, On This Day, Upcoming Events, etc seem to cache, with 4.2 they completely reload. IF I do a Firefox refresh, the same behavior, spinning icon until they reload. Is this a problem?
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rob
Cached for casual visitors (not logged in), but now simultaneous AJAX loading for logged in users. Page itself loads quickly (Welcome and Portal), and releases to let you navigate to a new page where previous v4.1 locked you into waiting for the previous page to completely load. For me, that was sometimes up to 2.5 minutes. Impossible - and my users abandoned the site.
Effectively, it still takes this time, but it doesn't tie up your site.
-Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have checked long running queries in my mysql log. I found the following:
# Query_time: 1.046875 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 60755
SELECT AVG(death.d_julianday2-birth.d_julianday1) AS age FROM pgv_dates AS death, pgv_dates AS birth, pgv_individuals AS indi WHERE indi.i_id=birth.d_gid AND birth.d_gid=death.d_gid AND death.d_file=4 AND birth.d_file=death.d_file AND birth.d_file=indi.i_file AND birth.d_fact IN ('BIRT', 'CHR', 'BAPM', '_BRTM') AND death.d_fact IN ('DEAT', 'BURI', 'CREM') AND birth.d_julianday1!=0 AND death.d_julianday1!=0 LIMIT 0, 1;
This query is used from statistics. In this query the table pgv_individuals is not needed and slows down the query.
# Query_time: 10.843750 Lock_time: 0.000000 Rows_sent: 174 Rows_examined: 776
SELECT DISTINCT 'INDI' AS type, i_id AS xref, i_file AS ged_id, i_gedcom AS gedrec, i_isdead, i_sex, d_type, d_day, d_month, d_year, d_fact, d_type FROM pgv_dates, pgv_individuals WHERE d_type='@#DGREGORIAN@' AND d_day=14 AND d_mon=2 AND d_year<=2009 AND d_fact NOT IN ('CHAN','BAPL','SLGC','SLGS','ENDL','CENS','RESI','NOTE','ADDR','OBJE','SOUR','PAGE','DATA','TEXT','_TODO') AND d_file=4 AND d_gid=i_id AND d_file=i_file ORDER BY d_day ASC, d_year DESC;
This seem to come from "On this day" and is faster having an index on 3 colums (d_file, d_mon, d_day).
This was tested with a database with about 150,000 persons in 4 different gedcoms.
Regards,
Veit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also have upgraded from 4.1.6 to 4.2 and am disappointed by the decrease in performance of page loads. I've went so far as to remove blocks from the index page, change themes (to a lighter one with less graphics), and used different Browsers, all to no avail.
What happened?
Another disappointment I have is with the AJAX in PGV version 4.2. As a webmaster, I need to be able to find and troubleshoot the page appearance and layout, quickly. The Ajax makes that a more difficult task on my part, if not impossible.
I feel as if I have less control over the script, as a webmaster. I'm seriously considering dumping PhpGedView and using something a bit more easier and "webmaster friendly", such as GED2WEB.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<disappointed by the decrease in performance of page loads>>
Is this just the index page, or are you refering to others? It is much easier to investigate specific issues, than general gripes....
The only real change to the index page between 4.1 and 4.2 was the use of ajax to load the blocks asynchronously. Since most browsers are configured to allow 2 or 4 parallel connections to the server, this has the effect of halving/quartering the load time for the index page.
javascript performance varies wildly on different browsers, but for the block-loading on the index page, minimal javascript is used.
Do you have any timings for page-loads on 4.1. and 4.2? The developers and testers all found it to be quicker.
Performance is an issue on pretty much *every* application. If you're having problems, the more information you can give us, the easier it is to investigate.
<<The Ajax makes that a more difficult task on my part, if not impossible.>>
TIP: the "view source" option built in to most web-browsers shows only the source as it was downloaded from the server.
If you want to see the "modified" DOM, after it has been processed by ajax/javascript, then all you need to do is use one of a thousand tools. The "web-developer" plugin for firefox is one of the most popular. Let the page load, then click on the "edit-html" option and it will show you what you are looking for.
GReg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mr Chambers
Frankly I'm shocked at your mention of slower page loads, disappointing result and Ajax on v4.2. Our welcome and portal pages were unusable under the previous version and now load promptly. Cached loads on the welcome page are less than 2 seconds and no Ajax. Users receive the page in 2-4 seconds with major blocks loading simultaneously over the next 8-20 seconds. Control over the page? Only the blocks load with Ajax and like before, you select the blocks you choose and their page locations. Nothing reaaly changed but the lock on loading other pages while waiting for the main page. Another huge improvement. If response is slow, we might suggest a DB or server issue, not a pgv problem.
Also, rather than complain, why not offer suggestions or more indepth explanations. We see nothing but remarkable improvements on our 60,000 GEDCOM.
-Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-02-15
I think some of the concerns about speed on the welcome and / or my portal pages are a matter of perception - made worse by the multitude of 'spinning wheels' displayed with each block that is being opened. They are relatively easy to suppress, and I certainly found my perception of the loading speed instantly changed. It might help if the were supressed by default.
The other key difference, which is Stephen's point, is that in 4.1.5 you had to wait for the whole page to load before you could navigate away. Now thats' not necessary.
<<I'm seriously considering dumping PhpGedView and using something a bit more easier and "webmaster friendly", such as GED2WEB.>>
Sometimes such a move is the best solution. PGV has certainly progressed a long way from the simplistic HTML-only solutions like GED2WEB. If your needs are satisfied at that level, then that is probably a sensible move. If however you are keen to not only improve the presentation of your data, but also to extend your programing skills beyond basic html, then take up the challenge of learning new languages like AJAX.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-02-15
<<They are relatively easy to suppress,>>
I should say - all that is needed is to remove their IMG tag from rows 391 and 422 in index.php.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings,
Just installed 4.2 on my test system and noticed that page refresh appears to be much slower.
Whereas with 4.1.6, standard theme, blocks: GECOM Statistics, On This Day, Upcoming Events, etc seem to cache, with 4.2 they completely reload. IF I do a Firefox refresh, the same behavior, spinning icon until they reload. Is this a problem?
Rob
Rob
Cached for casual visitors (not logged in), but now simultaneous AJAX loading for logged in users. Page itself loads quickly (Welcome and Portal), and releases to let you navigate to a new page where previous v4.1 locked you into waiting for the previous page to completely load. For me, that was sometimes up to 2.5 minutes. Impossible - and my users abandoned the site.
Effectively, it still takes this time, but it doesn't tie up your site.
-Stephen
I have checked long running queries in my mysql log. I found the following:
# Query_time: 1.046875 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 60755
SELECT AVG(death.d_julianday2-birth.d_julianday1) AS age FROM pgv_dates AS death, pgv_dates AS birth, pgv_individuals AS indi WHERE indi.i_id=birth.d_gid AND birth.d_gid=death.d_gid AND death.d_file=4 AND birth.d_file=death.d_file AND birth.d_file=indi.i_file AND birth.d_fact IN ('BIRT', 'CHR', 'BAPM', '_BRTM') AND death.d_fact IN ('DEAT', 'BURI', 'CREM') AND birth.d_julianday1!=0 AND death.d_julianday1!=0 LIMIT 0, 1;
This query is used from statistics. In this query the table pgv_individuals is not needed and slows down the query.
# Query_time: 10.843750 Lock_time: 0.000000 Rows_sent: 174 Rows_examined: 776
SELECT DISTINCT 'INDI' AS type, i_id AS xref, i_file AS ged_id, i_gedcom AS gedrec, i_isdead, i_sex, d_type, d_day, d_month, d_year, d_fact, d_type FROM pgv_dates, pgv_individuals WHERE d_type='@#DGREGORIAN@' AND d_day=14 AND d_mon=2 AND d_year<=2009 AND d_fact NOT IN ('CHAN','BAPL','SLGC','SLGS','ENDL','CENS','RESI','NOTE','ADDR','OBJE','SOUR','PAGE','DATA','TEXT','_TODO') AND d_file=4 AND d_gid=i_id AND d_file=i_file ORDER BY d_day ASC, d_year DESC;
This seem to come from "On this day" and is faster having an index on 3 colums (d_file, d_mon, d_day).
This was tested with a database with about 150,000 persons in 4 different gedcoms.
Regards,
Veit
I also have upgraded from 4.1.6 to 4.2 and am disappointed by the decrease in performance of page loads. I've went so far as to remove blocks from the index page, change themes (to a lighter one with less graphics), and used different Browsers, all to no avail.
What happened?
Another disappointment I have is with the AJAX in PGV version 4.2. As a webmaster, I need to be able to find and troubleshoot the page appearance and layout, quickly. The Ajax makes that a more difficult task on my part, if not impossible.
I feel as if I have less control over the script, as a webmaster. I'm seriously considering dumping PhpGedView and using something a bit more easier and "webmaster friendly", such as GED2WEB.
<<disappointed by the decrease in performance of page loads>>
Is this just the index page, or are you refering to others? It is much easier to investigate specific issues, than general gripes....
The only real change to the index page between 4.1 and 4.2 was the use of ajax to load the blocks asynchronously. Since most browsers are configured to allow 2 or 4 parallel connections to the server, this has the effect of halving/quartering the load time for the index page.
javascript performance varies wildly on different browsers, but for the block-loading on the index page, minimal javascript is used.
Do you have any timings for page-loads on 4.1. and 4.2? The developers and testers all found it to be quicker.
Performance is an issue on pretty much *every* application. If you're having problems, the more information you can give us, the easier it is to investigate.
<<The Ajax makes that a more difficult task on my part, if not impossible.>>
TIP: the "view source" option built in to most web-browsers shows only the source as it was downloaded from the server.
If you want to see the "modified" DOM, after it has been processed by ajax/javascript, then all you need to do is use one of a thousand tools. The "web-developer" plugin for firefox is one of the most popular. Let the page load, then click on the "edit-html" option and it will show you what you are looking for.
GReg
Mr Chambers
Frankly I'm shocked at your mention of slower page loads, disappointing result and Ajax on v4.2. Our welcome and portal pages were unusable under the previous version and now load promptly. Cached loads on the welcome page are less than 2 seconds and no Ajax. Users receive the page in 2-4 seconds with major blocks loading simultaneously over the next 8-20 seconds. Control over the page? Only the blocks load with Ajax and like before, you select the blocks you choose and their page locations. Nothing reaaly changed but the lock on loading other pages while waiting for the main page. Another huge improvement. If response is slow, we might suggest a DB or server issue, not a pgv problem.
Also, rather than complain, why not offer suggestions or more indepth explanations. We see nothing but remarkable improvements on our 60,000 GEDCOM.
-Stephen
I think some of the concerns about speed on the welcome and / or my portal pages are a matter of perception - made worse by the multitude of 'spinning wheels' displayed with each block that is being opened. They are relatively easy to suppress, and I certainly found my perception of the loading speed instantly changed. It might help if the were supressed by default.
The other key difference, which is Stephen's point, is that in 4.1.5 you had to wait for the whole page to load before you could navigate away. Now thats' not necessary.
<<I'm seriously considering dumping PhpGedView and using something a bit more easier and "webmaster friendly", such as GED2WEB.>>
Sometimes such a move is the best solution. PGV has certainly progressed a long way from the simplistic HTML-only solutions like GED2WEB. If your needs are satisfied at that level, then that is probably a sensible move. If however you are keen to not only improve the presentation of your data, but also to extend your programing skills beyond basic html, then take up the challenge of learning new languages like AJAX.
<<They are relatively easy to suppress,>>
I should say - all that is needed is to remove their IMG tag from rows 391 and 422 in index.php.
No spinning wheels gets my vote ... it "looks" faster without them, even though I "know" it makes no difference.
Mark
The Upcoming Events block is always the last to load on my site. I don't have a huge database: it's fewer than 3,000 people.
Sometimes, the Logged-in Users block and the Login block NEVER complete loading. Weird.