By Darko on Friday, 15 August 2014
Posted in General Issues
Replies 31
Likes 0
Views 1.3K
Votes 0
Hello guys. This is not really a support request but rather our findings report and feedback. We hope Stackideas team will take it as a constructive criticism to improve this otherwise very good product.

For past two months my team and i were testing EasySocial on dedicated server with 8GB of RAM and 128GB SSD with Joomla 3.x (updated regularly). No other sites are hosted on it.
Site have something above 3500 users with 10 to 30 concurrent users online at any given moment. Site is live and in production, meaning there are real users, gee rating real content on it.
Along side EasySocial, we only use Kunena forum and JomSocial (for testing and comparison purposes). No other components or esoteric plugins are installed.
Our site template is NOT a framework bloat. We use in-house created template that relies on built in Joomla bootstrap, so basically our template css is lower than 20kb in size for minor overrides.
Native Joomla pages load blazing fast. Simple text article takes 2-3 seconds after initial (first) load.

We have tried almost everything you advised other users in various different threads all over this support forum, let alone server optimisations that we tried to do on our own because, we are also doing Joomla extensions development ourselves and server optimisation for various different scenarios is something that we did many times before. EasySocial look nicer than others but the speed is what matters. And low loading speed simply drags users away.
No matter what we do, we couldn't get under 7-8 seconds (9-10 first load) result on the default dashboard and profile page with no additional apps.
With JomSocial, default frontage and profile page with no additional apps loads in about 3-4 seconds (5-6 on first load).
That is almost double improvement on the same configuration without even touching anything.

We are seriously disappointed at this stage, but will continue using and supporting EasySocial as it is the good component that requires a bit of query rethinking on dashboard and profile page (we believe stream is the bottleneck) as other pages are quite fine.
That being said, instead adding more and more features announced for next version, we would really like to see some performance improvements for dashboard and profile pages, otherwise, even with all the new bells and whistles of 1.3 component remains unusable and will only drag users away.
Till that happens, again, sorry to inform you but after couple of months of intense testing on busy site we found that ES is not ready for prime time and being the main star of the show yet.
Hello Darko,

We have actually ran some internal benchmarks ourselves and the load time from EasySocial is definitely much faster than JomSocial I have a feeling that you have some system plugins that does some search / replace codes. This is often the case that causes hiccups on the server (Especially with the load time). Some of the noteable plugin includes:

1. JFBConnect (I have already spoken with the lead developer from JFBConnect and he agrees and ackowledges that it is indeed causing performance stress)
2. JCH Optimize (I never managed to get in touch from JCH Optimize).
3. JQuery Easy (I never managed to get in touch from JQuery Easy).

Now, why does these plugin causes load issues? The answer is really simple and it's purely because EasySocial has more HTML5 data attributes used in the extension itself. In other words, the page size might be a little larger than JomSocial. You can try to view it yourself and see that there are plenty of data-xxx tags being used in the theme files

When the page size is a little larger, these plugins above does a very heavy expression which is to use regular expressions to match the entire output of your site and does some search / replace.

Believe me, we have ran a lot of stress tests and the fastest we can get with a whole load of data is within 1s - 1.5s

By the way, out of curiosity are you running on development mode or ? Based on your behavior, I probably think that the only reason that it would take 9s to load is when the less files are being compiled to css.
·
Friday, 15 August 2014 14:48
·
0 Likes
·
0 Votes
·
0 Comments
·
Hi Mark

Thanks for response and insights.
The thing is, the site was running JomSocial before it is migrated to EasySocial, it did not build its user base over night Its not about competition here and who is better, im just using it as a comparison point.
We upgraded it just for the sake of testing the component because we maintain several other sites too. Few of them with tens of thousand registered users.
When we migrated, the first reaction of old users accustomed to JomSocial was a "jaw-dropping-wow" effect. It was a love on a first sight,
However, till this late date the number one reaction and question we get is that site looks awesome, but is tad slow. When are we going to speed it up?
Every few days we get new users complaining. For those that are, we setup shadow copy of same site on the same server, but give them a JomSocial to try.
New users say that they like "original" design better (es) but the given one (js) is much faster.
Old users are excited to see a "real original design" (js) and inevitably ask if its possible to bring it back.
Now if that happens with 3.5k users site, i am really reluctant to migrate those with more.

Coming back to your advices..
I appreciate them, but as i said, we try not to use esoteric javascript compressors and such plugins at all. In fact, we dont. EVER!
After almost a decade of "messing" with Mambo and then Joomla, if theres a one thing i learned is not do rely on them as sooner or later they will cost us a huge performance penalty but rather implement other enterprise level practices. For instance, our Joomla template to name the one, load only one css file which is less then 20Kb in size. No other javascript and css except those from JUI and third-party extensions are loaded.
Im attaching the list of all plugins installed on the site. You can see that is pretty much "vanilla".
Also, attached is the screenshot of deployed configuration

Like i said, we are going to support and use Easysocial as its good, but have a lot of place to improve.. We even plan to make ES version of some extensions that we built for JomSocial, but out of the above mentioned reasons, we are not really excited to speed that process up.
·
Friday, 15 August 2014 19:55
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello,

Thanks for taking the time to update me on this and appreciate it very much. That's an interesting benchmark you have there but to be honest with you, I really cannot tell why your users are saying this unless I can try to take a look at both your sites and try to determine what is clogging up the system. I am pretty sure that:

1. There is a system plugin that is running on the site that does search / replacing

or

2. There is some issues with the database structure which could be out of sync as we have added / removed / modified quite a number of database indexes for optimization purposes

or

3. You might be running on an older version of EasySocial prior to 1.2.20. In 1.2.20 we have added massive improvements on the stream and that itself reduced almost 80% of the bottlenecks.

or

4. Something else that I have never seen before and need to debug this on the site
·
Saturday, 16 August 2014 01:06
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Mark

Sorry for slow response, we gave up on this and had to free up the server for different projects and move this site.
The other server is still a VPS but not as powerful as the one outlined in opening post, however, we basically see absolutely no difference in site performance.

I will gladly provide you the full access to server (find in site details full WHM access and Site access) so you can try to do your magic.

Cheers
·
Saturday, 30 August 2014 13:43
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Darko,

I was just checking on the surface of your site and server and immediately noticed a couple of issues here.

1. Even without EasySocial loading, just the login page to your back end takes about 1 minute to load http://screencast.com/t/PHoB9zfv

2. Your server does not have a swap

3. I am not sure how is your current LAMP stack is being setup but it seems like the "PHP" process is spawning quite a number of processes and it does seem to be hogging the CPU quite a bit. I have never tried such a setup before but most of the time, I do run php as an apache module instead.

Also, before I start digging deeper into this, the stream on EasySocial has been optimized very heavily on 1.2.21 and 1.2.22. Can I upgrade it to the latest version? Are there any core hacks made?
·
Saturday, 30 August 2014 15:29
·
0 Likes
·
0 Votes
·
0 Comments
·
^ I can confirm that the upgrades in the last few versions have significantly improved performance. I went from 5-7 second load time to 2 second load time since upgrading to 1.3 beta and wanderers
·
Sunday, 31 August 2014 08:36
·
0 Likes
·
0 Votes
·
0 Comments
·
Thanks for sharing this Jannik
·
Sunday, 31 August 2014 14:33
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Mark

Thanks for the insights
I did some server tweaking and here's the outcome.

1. On our hosting VPS, the swap is in host server, and it is already active.
2. I reinstalled Apache/PHP through "Easy Apache" and is now running php as an apache module
3. I updated PHP to 5.4.32
4. Changed the PHP 5 handler back to suPHP (we changed handler due some permission changing our script were doing earlier)
5. Updated to the latest version of ES as of Sept. 1st

Although there are some performance benefits, the dashboard and specifically profile pages are still very slow. (around 10s)
I also had to change the WHM password. The new one is posted in site details
·
Wednesday, 03 September 2014 13:38
·
0 Likes
·
0 Votes
·
0 Comments
·
Thanks Darko! We'll continue to run some tests on the site
·
Wednesday, 03 September 2014 16:48
·
0 Likes
·
0 Votes
·
0 Comments
·
While you shouldn't need to switch, something that I recommend considering is switching to a LEMP stack, rather than a LAMP stack.... aka switch from Apache to Nginx. According to nginx.com, netflix, box, hulu, wordpress, maxcdn, facebook, yandex & dropbox use Nginx.

Personally I have had best luck with Nginx, php-fpm5, APC, Ngx_Pagespeed combo. That said, I don't have near the amount of users you do, so take my feedback with a grain of salt.

Disclaimer: I am no expert. This is just what worked best for me.
·
Wednesday, 03 September 2014 17:40
·
0 Likes
·
0 Votes
·
0 Comments
·
I never really liked Nginx to be honest, nothing against it but it's just a personal preference for me Nginx is just very unpredictable for me (bad experience) but I have to agree, with Nginx you get a speed bump but with proper apache setup (removing unnecessary modules, would lead you to a result that is almost similar to nginx)
·
Thursday, 04 September 2014 02:25
·
0 Likes
·
0 Votes
·
0 Comments
·
I have to say that with the right setup Easysocial is very fast.

Just to add, nginx rocks! Switched from apache a year ago and never had better server performance. The memory footprint is insanely small! I very much recommend nginx and it is easy to configure for joomla. You have to translate all of your htaccess rules as they are set directly in the server config. This is fine though as htaccess is really just another apache performance hog.

I have a site with 16,000 registered members and 50-60 active at any one time with around 450 visitors (this increases every week). I run Eaysocial on a dedicated server (Xeon E3-1240 v34 Cores x 3.4 GHz, 8 GB DDR3, 120 GB SSD). There are no other sites running. I am currently running a LEMP stack with a little help from memcached and a tweaked varnish 4 configuration. Postfix handles the 1000's of emails fired out each day. Must add I also use a content delivery network and run the site through a pro package from cloudfare.

I have to say the sever hardly breaks a sweat, even a peak times. We have tweaked the database over the last month and with the latest edition of Easysocial things have got even faster. In fact we estimate we could quite happily handle 300+ concurrent users without losing performance before we have to upgrade to a more powerful server.

Load times for the front page are under a second (page score 96%) and the dashboard loads in around 2 seconds flat. The rest of the site is even faster (averages 1.5s) and we are running quite a few resource heavy applications.

With each new version of Easysocial we have noticed more performance gains. So I really congratulate the team!

I am a experienced joomla developer and server admin and have run Jomsocial for years (I do this for a living). We battled to make the site perform as it should and we tried out quite a few different configurations!

I am so glad I made the switch, if you are having performance issues don't blame the software instead have a serious look at your server configuration and exactly what you are running in addition to Easysocial.
·
Thursday, 04 September 2014 03:53
·
0 Likes
·
0 Votes
·
0 Comments
·
^ and that is why I use a LEMP stack ^^
·
Thursday, 04 September 2014 09:56
·
0 Likes
·
0 Votes
·
0 Comments
·
Hi Jannik,

What PhP5 Handler are you using with nginx?

Thanks,

Jackson
·
Thursday, 04 September 2014 10:39
·
0 Likes
·
0 Votes
·
0 Comments
·
PHP-FPM
·
Thursday, 04 September 2014 10:52
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Matthew,

Wow, nice stats. I really wish I could take a look at your site and see what sort of response time you are getting on your site. Wondering if we could run some benchmark on your site?
·
Thursday, 04 September 2014 12:50
·
0 Likes
·
0 Votes
·
0 Comments
·
So, we made a test droplet on the Digital ocean testing LEMP stack to see how it goes. It seems to be much faster when only few people are using it.
Maybe, for a month we move the site to this environment and see how it behaves when there is 20-30 people online
·
Friday, 12 September 2014 15:22
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Darko,

Is the droplet that you are testing on is much faster now? Perhaps once your droplet has more users accessing it, can you share the access with us so that I can take a peek at it's usage?
·
Friday, 12 September 2014 15:38
·
0 Likes
·
0 Votes
·
0 Comments
·
Yes, im talking about droplet.. Still setting it up though
I managed to reduce the frontpage loading time from 6-7 to 2-3 sec, without even using pagespeed from google
Will let you know when i have site completely moved
·
Friday, 12 September 2014 20:15
·
0 Likes
·
0 Votes
·
0 Comments
·
Nice to hear that Darko
·
Saturday, 13 September 2014 00:55
·
0 Likes
·
0 Votes
·
0 Comments
·
Wow Mathew that sounds like amazing performance. i am not a developer like you are and i am struggling to get my EasySocial site to be fast enough that people even want to stick around. I do not believe the problem is EasySocial although my host does believe that EasySocial could be part of the problem. I am not a developer and am coming to the conclusion that I need to ask help from somebody since my time is limited and when I spend a day tweaking settings that I do not even fully understand I can't be creating content or actually running our day to day business.

So, I am looking for recommendations. Mostly the problem I have is that there is a huge time delay from the time the server receives a request to when it starts delivering content.

I am doing a few things that could be causing the problem:

Using the T3 framework with a JoomlaBamboo template
Using JCH Optimize which actually seems to improve things
Using EasySocial, EasyDiscuss and EasyBlog

My main goal for this site is StackIdeas software.

My site host is CloudAccess.net and they seem to have good service. However, they do not have any engineers that will look at the performance issues with my site even as an extra service that i would pay for. I chatted with SiteGround.com and they stated that their engineers would look, but... I have bad experiences with them about six years ago with support. That said, it appears that they have really grown into a good company.

So, i am wondering if any of you know somebody that helps with Joomla site optimization. I guess what I really need is a report to know what the problem is. Once that is understood then we would be able to fix it. Page loads are around 9 seconds with almost 6 seconds of that being a delay from the web server.

I am attaching a picture of the top of the Pingdom tools waterfall where you can see the huge delay in yellow.

Anybody here have a good performance guru like what @Matthew Pate described.
·
Thursday, 18 September 2014 10:02
·
0 Likes
·
0 Votes
·
0 Comments
·
Mine's just 4.37 - 6.62 (from frontpage to profile page with 2 streams). I still haven't added CDN there and also just using a single droplet. Will upgrade soon next week to multiple droplet (NGINX - Cassandra - CDN - Amazon s3) to see how this will improve more.
Ken
·
Thursday, 18 September 2014 10:18
·
0 Likes
·
0 Votes
·
0 Comments
·
@Sean Carney, sorry to hear about your speed issues!

I have had a quick glance at your site and ran a quick benchmark. Can you tells us what specification the server is and which web server are you using (Apache, NGINX)? How much ram is available to you and do you have root access to the server via SSH?

Your first byte time is really high at around 5.7 seconds which means the server is only responding and then rendering data 8 seconds after the initial request from the user. There are various ways to reduce this depending on your web server and specification. You should be aiming for a first byte result or around 200ms! 58% of your page load is comprised of images so you would greatly benefit from using a CDN as this would reduce your server workload and rendering times.

Your front page is jam packed with dynamic content which means tons of database calls which is going to slow things down dramatically. Maybe consider slimming down the content on the front page, this would instantly help speed issues. I am not sure which version of PHP or SQL you are using but you should be using if not already a good opcode cache to cache already compiled PHP. You can also use some memory based cache to store both sessions and database queries such as memcached. Have you tweaked the MySQL settings at all? This would need to be monitored and then adjusted. Optimizing the database can give large performance boosts.

In conclusion I would like to help but need some more information, I don't think it would be too hard to slash at least 50% off your current loading times without too much effort!
·
Thursday, 18 September 2014 17:07
·
0 Likes
·
0 Votes
·
0 Comments
·
Matthew, Thank you so much for your reply!!!
I think things have improved a tiny amount by turning on the system cache. Previously I turned that off because the EasySocial Stream module did not update correctly on my homepage. I will keep my eye on that.

Here is the system information at CloudAccess.net:

PHP Built On Linux lamp17.cloudaccess.net 2.6.32-531.1.2.lve1.2.54.el6.x86_64 #1 SMP Tue Mar 25 07:41:27 EDT 2014 x86_64
Database Version 5.5.34-cll-lve
Database Collation utf8_general_ci
PHP Version 5.3.29
Web Server Apache
WebServer to PHP Interface cgi-fcgi
Joomla! Version Joomla! 3.3.3 Stable [ Ember ] 25-July-2014 13:00 GMT
Joomla! Platform Version Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
User Agent Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36

Disk Used: 11163.22 MB
Max. Disk: 20480 MB

I do have ssh access to the server.

Each Application Receives at CloudAccess.net:

2GB Ram
2 CPU
20 GB Disk Space

These sites cost $10 per month for the first site (Their standard package) and $5 per month for every site after that. Support is the real difference.

They do offer a product they call Compute Booster which will give more resources:

12GB Ram
6 Intel Xeon Cores

http://www.cloudaccess.net/cloud-control-panel-ccp/139-ccp-features/800-adding-the-compute-booster.html

I am not opposed to adding the compute booster if it makes sense but they actually suggested that it won't help me that much until I fix the other issues with my site. They they suggested looking at Compute Booster in the future when my site gets busy.

I will look at maybe reducing a bunch from the homepage but it will be with some regret. The reason is I was trying to have some content on the homepage from each of the site sections: Social Network, discussion forum, Blog, Recipes.

I guess I will have to ask the host about a good opcode cache to cache already compiled PHP?

Right now I am not using memcache as the setting in my global configuration. I am using File. Should I be using Memcache instead?

I have not tweaked my MySQL settings. This is not something I know how to do at this point in time.

Thank you so much for entering into this discussion with me! I am grateful for your help!

Sean
·
Friday, 19 September 2014 02:03
·
0 Likes
·
0 Votes
·
0 Comments
·
One more question Sean , what Distro of Linux is the server running?
·
Friday, 19 September 2014 05:29
·
0 Likes
·
0 Votes
·
0 Comments
·
If you guys are interested, I wouldn't mind trying out a "mini" hosting project which is fine tuned by us If you guys are interested, let me know. My email is mark AT stackideas.com
·
Saturday, 20 September 2014 02:14
·
0 Likes
·
0 Votes
·
0 Comments
·
Sounds interesting, I will send you an email to get more info
·
Saturday, 20 September 2014 02:17
·
0 Likes
·
0 Votes
·
0 Comments
·
Thanks Jannik, will check my mailbox
·
Saturday, 20 September 2014 02:51
·
0 Likes
·
0 Votes
·
0 Comments
·
Excellent, I sent you a reply.

By the way, for the people who use Debian and want to use NGINX with ngx_pagespeed bundled into NIGX without having to manually compile it.... this awesome repo comes with everything optimized and integrated: http://www.dotdeb.org/

With that, you can get NGIX and Ngx_Pagespeed up and running in no time... and upgrade painlessly.
·
Saturday, 20 September 2014 03:22
·
0 Likes
·
0 Votes
·
0 Comments
·
i am trying to figure that out. Here is some information but it may not be enough:

-sh-4.1$ uname -a
Linux lamp17.cloudaccess.net 2.6.32-531.1.2.lve1.2.54.el6.x86_64 #1 SMP Tue Mar 25 07:41:27 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

-sh-4.1$ cat /proc/version
Linux version 2.6.32-531.1.2.lve1.2.54.el6.x86_64 (mockbuild@koji.cloudlinux.com) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) #1 SMP Tue Mar 25 07:41:27 EDT 2014

Actually I think that should do it. :-)
·
Saturday, 20 September 2014 03:48
·
0 Likes
·
0 Votes
·
0 Comments
·
Hello Sean,

I don't really think you can actually change the web server on cloud access if you are on a shared hosting.
·
Saturday, 20 September 2014 22:35
·
0 Likes
·
0 Votes
·
0 Comments
·
View Full Post