Content
You are here:
Is this open project still active?
Added by Frank Ni almost 9 years ago
Someone recommended this open project software to me, and I was able to deploy the software (stable/5).
However, I found it is extremely slow. I did a few google search and someone told me open project is not active any more, and suggests to use projectlibre.
Is this true? I am not familiar with projectlibre. Are they similar?
Thanks!
Replies (7)
Hi Frank,
we’re highly active ;-) We’ve released our last major update (5.0.0) in November and are actively working on OpenProject 5.1. as well as lots of minor / patch release for 5.0.
Sorry to hear you found the software to be running slowly. What is your setup? It is likely a configuration issue, since we host installations with several thousands of projects and members with adequate response times.
Does the community (this site) behave similarily slow? It is running the latest nightly builds from the last day of development.
Best,
Oliver
Hi Oliver,
I follow exactly the manual installation guide @
http://www.openproject.org/open-source/manual-installation/manual-installation-guide/
except that I am using CentOS 6.7
My machine has 16G RAM.
Here is site: http://op.geomarktech.com/
I wonder how setup can be changed to make it faster…
Thanks
Frank
As OpenProject is a frontend-heavy app, we have a large number of assets for the Angular-based frontend.
It seems that your server’s upstream isn’t that big, since downloading that asset (9mb) from your server took quite long (13.5 seconds, see the screenshot).
You should first introduce asset caching to your installation. Add the following snippet to your Apache2 openproject site:
And restart your server. It will result in subsequent requests being much faster until the asset changes.
I’ll put that in the manual installation guide since we’ve missed that configuration option as default. (Our packaged installation does that automatically)
Thank you Oliver,
Done that, doesn’t seem to improve..
Here is my vhost setting
Hi Frank,
we just checked again, the response time looks okay after the initial assets are loaded? Still, the initial load time is kind of long due to the upstream.
As a next measure, you should enable gzip-encoding from the server, if the browser supports it.
You can use this gist as a starting point: https://gist.github.com/akagr/6989327
I’ll improve our manual installation guide in the meantime. It is definitely lacking these pointers. Thanks for your input!
Best,
Oliver
Oliver,
It doesn’t seem to be gzip issue.
To find out the cause for the slowness, I test it in my local machine. I reboot the machine so all session starts from scratch.
I then observe the httpd error log (/var/log/httpd/error_log) and apache access log. When I click local test site (http://localhost), it take many seconds to do things that I don’t know (showing below), the apache log show the package is small.
Apache access log:
/var/log/httpd/error_log (take a long time for the following log to slowly show up)
Now coming back to your previous question, this site is also slow.
In addition, the manual installation is missing instruction on Phusion Passenger with Apache and SELinux. Most server has enforcing SELinux policy (/usr/sbin/getenforce=Enforcing), then Passenger fails to start. I spent a lot of time finding out the solution @
http://kyrylkov.com/2012/02/26/phusion-passenger-with-apache-on-rhel-6-centos-6-sl-6-with-selinux/
Basically
fix the problem.
Hi Frank,
thanks for the mention on SELinux.
When you first start your server, Passenger by default will start and stop its instances automatically only when requests are made within a specific time frame. These start up processes are slow and may take up to half a minute.
The log output your showing is exactly this behavior, it’s booting the Rails application before it can serve your request.
In order to keep the instance running, set:
PassengerMinInstances 1
(or higher)Still, from the public site, asset loading is the definite first culprit of slowness on your server, thus I highly recommend you to add transfer encoding.
Best,
Oliver