- +38 (044) 501-55-38
- contact (at) qa-testlab.com
QATestLab Conducted Performance Research of ELGG Framework
The target audience of this research is anyone who has products to be deployed on open source social networking platform ELGG, etc apart from developing such applications.
The main goal of this performance research was to identify how well application built on ELGG performed in relation to performance objectives.
Some of other goals of this performance research were:
- Identify bottlenecks and their causes.
- Optimize and tune the platform configuration (both the hardware and software) for maximum performance.
- Verify the reliability of application under stress.
We used Mercury Loadrunner 8.0 tool for load scenarios. Load scenario development included: recording the selected transactions into virtual user scripts; parameterization of input data for the scripts, building any required verification points in the scripts, creating/configuring user groups, and assigning virtual user scripts to user groups.
After analyzing the user behavior in social networks, we created a model of user activity within a week.
User Activity Model
The main concepts of this model are:
- 100% of users are active and post content
- Each user posts 1 article to blog per week
- Each user posts 1 video per week
- Each user uploads 1 file to repository per week
- Each user posts 1 article to wiki per week
- Each user uploads 5 photos per week
- Testing will be conducted on data for the year: 2*52 articles and 7*52 of other content (videos, photos and files) for each user
- Article will consist of 1000 words on average
- Words are generated as a random sequence of letters of length 1-10 characters
- Each article will have 10 comments (length of each comment 10 characters)
- Each video/file/photo will have 2 comments (length of each comment 10 characters)
In this performance analysis we made a model of social network with content accumulated during 1 year.
We found out that different social networks have different number of active users depending on their popularity and niche audiences. So we created 3 different models: little, middle and large networks.
In this case our model – is specialized narrow network with 500 monthly active users.
We assume that total number of visitors V=A*10=500*10=5000.
We assume that this number of users will give us 25 concurrent users (C) on average.
In this case our model – is common network with 5000 monthly active users.
We assume that this number of active users will give us 250 concurrent users (C) on average.
In this case our model – is large network with 50000 monthly active users.
We assume that this number of active users will give us 2500 concurrent users (C) on average.
We expected that response time should not be greater than 7 seconds, server busy errors should not be more than 0.1% percent of the total response, transaction passed per second =>8 .