I have noticed the login delay after version 3 has become quite long. Some times up to 15 seconds. Typically it's 5 to 7 seconds. Doesn;t bother me much, but customers have commented. I see the redirect is 1 second, but after that it just sits there. Does anyone else notice this? I am on a lightly loaded dedicated 3Ghz Conroe w/ 1Gb RAM. My customer count is nearing 11,000. and my access log is set for 90 day retention. Alex, your site does the exact same thing. Is this just to be expected with the new version?
Hi! Well, I have about 40.000 users. Do the following: 1. Index your database especially the amember account and product tables. Go in phpmyadmin. Click on the Index field for each field of the ENTIRE TABLE of amember_users/members, amember_products, amember_acceclog, amember_errorlog. DO NOT REPEAT THE INDEXES. If a field was already indexed, you not repeate it. By this the searches becomes much faster. So all my queries that amember needs to do would also be faster. Amember gives a WONDERFUL oppurtunity to each admin _TO_CREATE_A_MYSQL_FIELD_ but fails to inform them how to handle it. Not everyone have knowledge of mysql. After indexing all the default fields _AS_WELL_AS the member_additional_fields, I could see better performance. 2. Write to Alex about it and wait for the solution. I think he may have a suggestion.... 3. Join with me in the protest of explaining Alex to REMOVE the [member][data][status] field COMPLETELY. This shity field does nothing but collecting data from existing tables and adding into this field. Why this field exists? If it did not, one needs to program more and write more functions. I think it is time now to do this by adding more work in rewriting the functions. 4. After your user database grows amember WOULD become slower and slower. This is because the entire plugin architecture. I have placed many suggestions in this regards and have been really convinced that the lugin architecture could be designed to work faster. 5. It would be helpful to report Alex about your problems as he then would add to his understanding exactly the problems from the admin side, which is the case.
draj: Thanks! I will submit this to Alex...I have asked him in previous tickets, but the answer has yet to be addressed. I suspect he knows exactly what you described and hopefully will do what is required to speed the script for those with rapidly growing customer bases.
Hi! Regardless of his help, you will still need to index your database as described above. Such an indexing speeds up sql queries, regardless of user number.
It is better to contact us via helpdesk. It must be reviewed carefully and answer depends on enabled plugins and customizations.
Alex, I belive if you worked on improving DB performance for a future release, that would save you the time of having to examine each amember installation. Respectfully speaking: I would suggest starting with your site (amember.com), since the login to your customer area is terribly slow (50+ seconds). I often get emails from customers asking why the login is so slow. Back at ver. 2.4.1Pro the login was never this slow. This only seemed to start at ver. 3.
HI! I have given a link of tuning my.conf, which you may check to modify and tune your server. This has helped to make chached queries visibily faster in cases where there were no changes n the queries. Oh yes, the DB performance needs to be overhauled.
Getting more emails from customers complaining of the login delay. It's under 15 seconds, but too long for many visitors. I'd love to see an upgrade that addresses this issue. Even adding something entertaining during the wait might help. I notice that if you add an animated gif to the redirect page, and are using IE, the gif freezes once the redirect starts. However, iIf using firefox, the gif keeps going once the redirect starts. I would think that using MySQL, the login would be instant. This is the biggest issue I see with aMember and even this site (amember.com customer area) has the very same problem. It was around 50 seconds to one minute, but now it's about 15 seconds. Still too long for many impatient users.
Anyone else having issues with login delays? My customer's have really started to complain. There was never an issue in pre 3.0 versions. Alex, I hope you can address this issue in the next release.
Hi! Man, thats terrible! Are you sure that the problem is due to aMember? I can imagine however after making the necessary updating and changes, it is possible that you may not have such a terrible problem. Regadrdless of you having a problem in this regards, aMember needs to be better and this I can certify.
draj: I guess I have impatient customers, but then again, they were used to the speedy logins at 2.3.5 pro. That was one reason I hesitated so long on doing the upgrade. Here's what one would expect: Enter login username & password, click sumbit...one thousand one, one thousand two, one thousand three BOOM and you're in! As it is now, it's one thousand 10, 11, 12, then in... I am on an managed dedicated server (rather pricey too) that is very lightly loaded, in fact you could say it's very under loaded. I am using the new_rewite method of protection and SSL. I hacked my way through MySQL, optimizing the tables as needed. It helped a bit, but still a delay. I'm quite sure this is normal, becasue the the very site we are on (Alex's site) has the same delay, and in fact it's a bit longer here. I've timed it at 50 seconds! After just a few seconds, people think something is wrong and start hitting refresh, making the problem worse. I added and animated GIF to the template file that displays the "You will be redirected..." but once the redirect starts, the GIF animation stops (except in FireFox). Maybe a Flash would work in IE. Some kind of motion would indicate it is at least working. I hate to say it, but for the first time, I am somewhat disappointed with the script. It is great in every other area, but login sure needs improvement. I'd love to see a detailed guide for those not familiar with indexing and optimizing databases. Better yet, a one click database maintenance tool that would do this on demand.
Hoi! Also work on my.conf and make sure that: 1. The key_buffers are correctly set and make them as high as possible 2. Increase the query_cache 3. Make sure that it does not create temporary tables on th disk and that they are created in the RAM. Becase Alex used Binary fields, I beleive that they cannot be cached and thats shity. Thats the reason why I am very much against seeing or having binary fields. Increase the apache processes so that there are enough spare servers. Make sure about the persistant connections... Regardless of above, I beleive that the scripts needs to be optimised. Anathor suggestion: You can also use Ajax for creating a login page that that may help users to understand it different than how it is now...
Database Needs to be Optimised! I strongly agree - the aMember code should be re-written so the 'data' field can be removed. This field is only used in 6 files - and it looks like it was only made out of laziness - having all the user's data in one place makes it easier for the programmer, but is bad database design. Here's a word of advice performance-wise for suffering users: It should be possible for you to change the Database Field Type of the 'status' field to VARCHAR(255). (in the 'members' table) I have done this myself without it causing problems. For MyISAM tables that change frequently, you should try to avoid all variable-length fields (VARCHAR, BLOB, and TEXT). The table uses a dynamic row format (much slower) if it includes even a single variable-length field (like the 'status' field). However, using VARCHAR over TEXT provides big performance gains, and makes it easier to index the field (if required). Hope this is helpful!
Hi! I am pleaed to see that there are some other people to see the same what I saw. Mind you, if the length in the data field increases more than 255, it will begin to truncate the data and the entire user record will not be loaded! The length may soon get increased if the user for instance requires a password by email, then this stupid field holds this information consuming the length. As a consequence, the moment the user orders the password, he will never be able to login if the length exceeded more than 255 characters. This is also the reason why I did not take the risk to do that, which is in many cases the first solution!!! The worst is that binary fields and not used for temporary chaching in mysql! So the binary data is always loaded on the disks, to my knowledge... Further, it should be also possible to deactivate certain extra functions like access loggin, or error logging to speed up the logins, which is NOT the case. Also, I do not see the reason why amember has to insert multiple cookies in multiple databases conneted to multiple websites. Those cookies are really garbage to other websites. For instance if a user logs in Domain A, then aMember should only insert all the plugins i.e. databases related to domain A. There is no need to bombard the entire database structure of Domain B, Domain C, Domain D, etc, which is NOW THE CASE. Those other sessions data in other websites will NEVER WORK anyway. This is anathor possibility to optimise amember and make it faster. For this aMember plugins needs to understand for which domain it has to work with and insert the sessions to only those domains. The main optimization of aMember would be in the disk writes, areas that works to create swap files as well as queries and deactivating certain functions and making it faster.
Draj & Joe... Great posts! I hope Alex is working on exactly what you describe. I also hope we don't get the "that's impossible" reply. Cheers!
Word of caution... I've been looking at ways to reduce the amount of data inserted into the 'data' field (so I can keep the field as varchar). If you remove all instances of the 'i_agree' (user agreement) functionality from the script**, it will prevent a 27 character serialized php string being added to the 'data' field like this: a:3:{s:7:"i_agree";s:1:"1"; I think I may also be able to find a way to stop the 'signup_email_sent' string being required in the 'data' field too, which is another serialized php string of an even larger number of characters. If we find all the unnecessary serialized php strings we can, we'll definitely be able to keep the field as varchar(255) until Alex and the team re-design this. Draj: Earlier you suggested indexing all the fields in the 'members' table. This is a bad idea, as indexes should only be used for fields that are used in WHERE and JOIN statements. I suggest only indexing the 'member_id', 'login' and 'email' fields ('member_id' is already indexed) - these are referenced in MySQL queries, especially for plugins. Indexes slow down write queries (but speed up read queries) - so indexing every field may actually slow down performance, and indexes increase disk usage. I have also found some of the default MySQL Field Types in the 'members' table are a poor choice, for example: 'is_male' field = smallint(6) - change to tinyint(1) 'country' field = varchar(255) - change to char(2) 'state' field = varchar(255) - change to char(2) etc... ** You can still validate a user agreeing to your user agreement by inserting code like this into your site.inc.php file: PHP: if (!$vars['i_agree']) $err[] = "You must agree to our privacy policy and user agreement to sign up"; if ($vars['i_agree'] == '0') $err[] = "You must agree to our privacy policy and user agreement to sign up"; Contact me for details...
Hi! Most of the amember database queries uses WHERE or JOIN, especially in searches. I needed to wait for hours which actually WHERE minutes! For registration it is only login and email that is checked. Here login is already indexed and member_id is primary. So email is a must. Hence will help in registeration process. Now login will not affect very much as it just checks the very minimum details of a table. Where the user needs to change the user profile or query member subscriptions, or admin needs to query things thats where indexes will help a lot! Now amember uses member_aditional field. So this always uses WHERE in the queries. Also for each product query, it has to for logical reasons use in many cases JOIN member_id from amember_member AS WELL AS amember_payment WHERE member_id = member_id. So all those payment queries will become faster in those areas. In the admin also the same things applies. WHERE and JOIN is extensively used. Thanks for your extra input. Its Helpful.
We have finally found a bug related with newsletters that caused delay on member.php. Fixed version will be released very soon. If you are experiencing this problem, you can contact us via helpdesk right now.
Joe, Draj: Thanks for your extensive knowledge on this. Just an FYI for Alex...logging into the customer area tonight took 22 seconds. That's a bit long, but I'm sure by now you are already aware of this issue. Glad to hear something will be done about it. Wish I could offer more than just a bug report.
Thats a real nightmare. Could you sleep after that? If you want and trust, I would try to look into your server environment. Then you may have to send me the login details for a short time i.e. a temporary password through SSH, mysql and server. There is a good chance that in your case, you have some extreme conditions.