How can I find out what version of PHPGEDVIEW that I am currently using and is it a good idea to keep upgrading PHPGEDVIEW versions.
The issue that I am having is as follows, the site seems to be very slow. There is most definately not load issue because there is only one user connected at any given time, and there are only around 700 people entries in the database. So the site is definately not loaded and the database is definately not big.
Yet the site sometimes takes mins to load. This is not very good.
Can someone please offer some advice.
Thanks in advance
You have not provided a URL for us to examine to see if it is a server or bandwidth issue.
It's possibly a problem with not enough memory available to PHP scripts.
PGV needs at least 32 Mb memory, and if there's more available, things will speed up dramatically.
Go the the admin page (/admin.php) to find your version.
It's probably a bad idea to publish your website URL here until you upgrade. There have been widespread attacks on earlier versions.
If you're having an issue with your hosting company (for example, the memory shortage mentioned above) see this page for a list of hosts: http://wiki.phpgedview.net/en/index.php?title=Web_hosting
Thanks for all the responses, I am really sorry for the inefficient original post. The URL is www.dunnsland.com/phpgedview
In the mean time I have been trying to do some reading and asked my ISP how much memory was available per application, it was set at 32 meg, so I have had them increase that to standard 64 and burst to 128. Even with this change I am still seeing major slow responses on some requests that I do on the page.
I am also experencing an issue with the logout page, I did an update to the latest version of phpgedview and now when I logout, I get a 404 error page. Any advice.
I am still digging with what I can find.
Thanks again in advance
If this site is now running with 64mb (you have confirmed on the phpinfo page of PGV's admin page?), then either the your server's processors, server bandwidth or MySQL configuration are not optimal as the site runs a less than average speeds. Changing some of these are not within your capabilities in a shared environment, so you may be stuck at this performance level if you remain with this host. Certainly your gedcom is not causing any problem, as it is not large.
Please e-mail me with temporary login credentials - "Access" permission should be enough.
I'll have a look at the cause of the 404 error and perhaps also identify the source of the slowness you're seeing. Any hints on how to reproduce the problems would be appreciated (e-mail, of course).
email: gkroll at keldine dot ca
Thanks for the great support, I suspect that the slowness is actually caused by my provider, but I have no idea how I can prove this. I do have command-line access but not root access, so if anyone has some trick to see if I can prove that it is my provider, advice would be much appreciated.
I feel that my provider has over subscribed the shared environment.
So please help.
I have been testing the site with Lawrence's co-operation. Lawrence is in Europe.
The URL above doesn't work right. There's a server configuration problem, since the URL requires "/index.php" at the end to work. This should NOT be required. This is also why you get a 404 error after Logout.
When I access the site in the evening (EDT), it's around midnight in Europe. The site is fairly responsive, even though a Login might not succeed right away. However, the personal Welcome page (the Portal page) takes over 3 minutes to complete when the Coming Events block is present.
The database contains only 634 people and 207 families. There's no reason the Coming Events block should be so slow. It should appear almost instantly. This points to a database configuration problem.
When I access the site in the morning (EDT), it's around noon in Europe. At this time, the site is extremely slow, to the point of being unusable. There are times when the Login doesn't work at all. This points to a server problem - perhaps there are too many users competing for the limited server resources.
Please check your site configuration (Admin menu, "Configure" option). Verify that you have PGV configured to use more than the minimum 32 Mb.
thanks for the response, it is very interesting and helpful. I have already covered the minimum 32Mb requirement, I have extended that to 64Mb and a burst of 128b. So the memory should not be the issue.
I will provide your feedback to buehost support and see how they respond.
I have just been told that the problem with the site is that there are large amount of slow queries, so I have managed to get hold of the slow_query_logs. How can I get these to you to peruse through?
I will paste a few below as a taster.
Any advice appreciated.
# Mon Aug 22 12:24:28 2011
# Query_time: 1.039192 Lock_time: 0.022736 Rows_sent: 0 Rows_examined: 0
SELECT ip_address, comment FROM pgv_ip_address WHERE category='banned' AND '220.127.116.11' LIKE REPLACE(ip_address, '*', '%') LIMIT 1
# Mon Aug 22 12:24:32 2011
# Query_time: 1.624428 Lock_time: 0.589158 Rows_sent: 1 Rows_examined: 1034
SELECT COUNT(*) FROM pgv_user_setting WHERE setting_name='canadmin' AND setting_value='Y'
# Mon Aug 22 12:24:45 2011
# Query_time: 1.629975 Lock_time: 0.017614 Rows_sent: 1 Rows_examined: 5
SELECT 'INDI' AS type, i_id AS xref, i_file AS ged_id, i_gedcom AS gedrec, i_isdead, i_sex FROM pgv_individuals JOIN pgv_link ON (i_file=l_file AND i_id=l_from) LEFT JOIN pgv_name ON (i_file=n_file AND i_id=n_id AND n_num=0) WHERE i_file='1' AND l_type='OBJE' AND l_to='M9' ORDER BY n_sort
# Mon Aug 22 12:51:28 2011
# Query_time: 2.416157 Lock_time: 0.262295 Rows_sent: 0 Rows_examined: 1
SELECT DISTINCT 'FAM' AS type, f_id AS xref, f_file AS ged_id, f_gedcom AS gedrec, f_husb, f_wife, f_chil, f_numchil, d_type, d_day, d_month, d_year, d_fact, d_type FROM pgv_dates, pgv_families WHERE d_type='@#DGREGORIAN@' AND d_day=4 AND d_mon=9 AND d_year<=2011 AND d_fact NOT IN ('CHAN','BAPL','SLGC','SLGS','ENDL','CENS','RESI','NOTE','ADDR','OBJE','SOUR','PAGE','DATA','TEXT','_TODO') AND d_file=1 AND d_gid=f_id AND d_file=f_file ORDER BY d_day ASC, d_year DESC
# Mon Aug 22 12:51:31 2011
# Query_time: 3.251313 Lock_time: 0.941530 Rows_sent: 1 Rows_examined: 1
SELECT 'INDI' AS type, i_id AS xref, i_file AS ged_id, i_gedcom AS gedrec, i_isdead, i_sex FROM pgv_individuals WHERE i_id='I290' AND i_file='1'
I think you're beating a dead horse. Find another service provider. Better still, find a company that will let you install and run your own server - preferably from your own home.
Just look at the first item you sent us. How can a zero-row table result in a "slow query"?
Your hosting company has hardware problems - probably a hard drive is dying.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.