I'm running a ruby sinatra app inside passenger within a docker container using one of the passenger-docker images(phusion/passenger-ruby26). This app is a simple web app that makes calls to a database(it does not constantly talk with the database, statements are only called when a certain button is clicked). I can start the app up fine and click around in my web app for a short amount of time but it always errors out at around 60 seconds of uptime saying:
Could not spawn process for application /home/app/my_app: A timeout occurred while starting a preloader process.
Error ID: 3b9633ef
Error details saved to: /tmp/passenger-error-aFglsc.html
Mind you this happens even when I don't click anything. Within the html file it states:
The Phusion Passenger application server tried to start the web application, but this took too much time, so Passenger put a stop to that.
It suggests that the server may be low on resources but I've given it unlimited resources(4 core 2.2GHz, 16GB ram, & 4GB swap), here are the load averages(memory used was 3%)
Here is the 'Problem Location', shows that it errored out at the 'Load Application' subprocess.
Things I've tried:
Running passenger from Nginx(same error)
Removing all stdout logging functions in my ruby app
Increasing passenger_start_timeout
Making sure folder/file privileges are set correctly
Starting passenger with a custom nginx-config-template that maxes out timeouts and resources
Gave my docker container unlimited resources
Tried a few other miscellaneous things that I can't recall but those didn't prove effective either.
Does anyone have any idea what might be going on? I'll provide more info if needed.
Versions used:
Passenger 6.0.3
Ruby 2.6.3
Sinatra 2.0.5
Docker 18.09.0
Running on MacOS 10.14.6
Resolved. Turned out to be that I was running my ruby app twice. Had two instances of the run myapp command in the main app.rb and the config.ru rackup config file. Should only have one instance of that in ruby project.
We are looking at upgrading our CouchDB on our RHEL servers from 1.6.1 to 2.1.1. Before we do that, though, we wanted to run a performance test. So we created a JMeter test that goes directly against the database. It does not use any random values, so that the test would be exactly the same, and we could compare the two results. This is just a standalone server, we are not using clustering. I ran the tests the exacts same way for both. I ran the tests for 1.6.1, and then installed 2.1.1 on the same machine. And I created the database new for each test run. [I also updated Erlang to R19.3.]
The results were very shocking:
Average response times:
1.6.1: 271.15 ms
2.1.1: 494.32 ms
POST and PUTs were really bad ...
POST:
1.6.1: 38.25 ms
2.1.1: 250.18 ms
PUT:
1.6.1: 37.33 ms
2.1.1: 358.76
We are just using the default values for all the config options, except that we changed 1.6.1 to have delayed_commits = false (that is now the default in 2.1.1). I'm wondering if there's some default that changed that would make 2.1.1 so bad.
When I ran the CouchDB setup from the Fauxton UI, it added the following to my local.ini:
[cluster]
n = 1
Is that causing CouchDB to try to use clustering, or is that the same as if there were no entries here at all? One other thing, I deleted the _global_changes database, since it seemed as if it would add extra processing that we didn't need.
Is that causing CouchDB to try to use clustering, or is that the same as if there were no entries here at all?
It's not obvious from your description. If you setup CouchDB 2.0 as clustered then that's how it will work. This is something you should know depending on the setup instructions you followed: http://docs.couchdb.org/en/2.1.1/install/setup.html
You can tell by locating the files on disk and seeing if they are in a shards directory or not.
I'm pretty sure you want at least two, so setting n = 1 doesn't seem like something you should be doing.
If you're trying to run in single node follow the instructions I linked above to do that.
One other thing, I deleted the _global_changes database, since it seemed as if it would add extra processing that we didn't need.
You probably don't want to delete random parts of your database unless there are instructions saying this is OK?
I have a relatively simple refinerycms setup ( just getting started ), but have hit a problem loading images on my web page in production environment.
see http://saigos.net:3000 for where it works fine in dev ( webrick ) If I start the server in production with webrick, it also looks ok.
see http://saigos.net for where it doesnt work in production ( apache2/passenger )
Viewing the page source for each, I see ref to the image :
/system/images/W1siZiIsIjIwMTMvMTAvMTMvMTJfMTJfMjlfNTgwX3Rva3lvdG93ZXIuanBnIl0sWyJwIiwidGh1bWIiLCI0NTB4NDUwPiJdLFsicCIsInN0cmlwIl1d/tokyotower.jpg"
A file of this name obviously doesn't exist on the server, and I figure is being created dynamically in the page source by rails/refinery, I'm wondering if this can be used to help debug, but not sure where to take it.
I had a good dig around on the net, but only find examples of a similar problem where people are using Heroku and/or S3, neither which i'm using, and doesn't seem that the knowledge there can be applied to my case.
If anyone can give me mental nudge of what to check further, that will be appreciated, i've come to a bit of a dead end with this one.. :
Running :
Refinery CMS 2.1.0
sqlite DB on both dev and prod ( yes i know one is supposed to use something 'stronger' such as postgres in production, and i'll be exploring that once i fix this issue )
Rails 3.2.13
ruby 1.9.3p194
Ubuntu 12.10
Amazon EC2 micro VM ( not using S3 )
I found the issue.. after seeing this error in /var/log/apache2/error.log
[ 2013-11-23 11:49:53.3999 3060/7f5258d00700 Pool2/Implementation.cpp:1274 ]: [App 3083 stderr] cache error: Permission denied - /opt/refinerycms/saigo/tmp/cache/ABD
I changed the permissions on the file, and hey presto, the image now loads..
Has anyone successfully got this combination working?
It seems to run correctly on the client side, but there's something about Cloud9's file system that means changes aren't detected when files are saved, so I'm having to restart the app every time.
problem is that cloud 9 gives u only one port(process.env.PORT) and you are using this port for running web server and you don't any have additional port for live-reload server.
for CSS you can use Live.js
Safareli is correct that Cloud 9 gives you only one port, but Live.js, the website Safareli linked in fact does work with refreshing everything, although I don't know how taxing it is to C9 since it is refreshing for headers pretty much all the time.
I have Symfony2 running on an Ubuntu Server 12.04 (64-bit) VM (VirtualBox). The host is a MacBook pro. For some reason I am getting really long request times in development mode (app_dev.php). I know its slower in dev mode, but I'm talking 5-7 seconds per request (sometimes even slower). On my Mac I get request times of 200ms or so in development mode.
After looking at my timeline in the Symfony2 profiler, I noticed that ~95% of the request time is "initialization time". What is this? What are some reasons it could be so slow?
This issue only applies to Symfony2 in dev mode, not any other sites I'm running on the VM, and not even to Symfony2 in production mode.
I saw this (http://stackoverflow.com/questions/11162429/whats-included-in-the-initialization-time-in-the-symfony2-web-profiler), but it doesn't seem to answer my questions.
I had 5-30 sec responses from Symfony2 by default. Now it's ~500ms in dev environment.
Then I modified the following things in php.ini:
set realpath_cache_size = 4M (or more)
disabled XDebug completely (test with phpinfo)
realpath_cache_ttl=7200
enabled and set OPcache (or APC) correctly
restarted Apache in order to have php.ini reloaded
And voilá, responses went under 2 secs in dev mode!
Before: 6779 ms
After: 1587 ms
Symfony2 reads classes from thousands of files and that's a slow process. When using a small PHP realpath cache, file paths need to be resolved one by one every time a new request is made in the dev environment if they are not in PHP's realpath cache. The realpath cache is too small by default for Symfony2. In prod this is not a problem of course.
Cache metadata:
Caching the metadata (e.g. mappings) is also very important for further performance boost:
doctrine:
orm:
entity_managers:
default:
metadata_cache_driver: apc
query_cache_driver: apc
result_cache_driver: apc
You need to enable APCu for this. It's APC without bytecode cache, as OPCache already does opcode caching. OPCache is built in since PHP 5.5.
---- After: 467 ms ----
(in prod environment the same response is ~80 ms)
Please note, this is project uses 30+ bundles and has tens of thousands of lines of code, almost hundred own services, so 0.5s is quite good on a local Windows environment using just a few simple optimizations.
I figured out the cause of the problem (and its not Symfony2). For some reason on the ubuntu VM, the modification times on certain files are incorrect (ie in the future, etc). When symfony2 checks these times using filemtime() against its registry, it determines that the cache is not longer fresh and it rebuilds the whole thing. I haven't been able to figure out why it is doing that yet.
I also needed to disable xdebug (v2.2.21) to debug apache2 max timeout loading on my macbook. It was installed using macports:
sudo port install php54-xdebug.
With xdebug enabled, every page run out max loading time, with a fatal error exceeding max timeout message dispatched. When disabled, everything just loads fine in a reasonable expected time. I came to this using MAMP, no xdebug enabled by default, and apache2 just works fast as usual. I may change for another debugger, that's a pitty, because xdebug worked fine before.
Config:
MacOSX 10.6.8
macports 2.1.3
Apache 2.2.24
php 5.4
We have the same problem.
Here we have 10 second and more for every request.
I see if I remove following lines in bootstrap.php.cache all times return in normal state (298 ms).
foreach ($meta as $resource) {
if (!$resource->isFresh($time)) {
return false;
}
}
It's possible that we have wrong modifications times, but we don't know how to fix. Somebody know a solution?
As said at https://stackoverflow.com/a/12967229/6108843 the reason of such behavior might be Ubuntu VM settings. You should to sync date and time between host and guest OS as explained at https://superuser.com/questions/463106/virtualbox-how-to-sync-host-and-guest-time.
File modification date changes to host's value when you upload file to VM via FTP. So that's why filemtime() returns wrong value.
You can move APP/var/cache в /dev/shm/YourAppName/var/cache. But it's good to have built container in local files too for IDE autocomplete and code validation. In app/AppKernel.php:
public function getCacheDir()
{
return $this->getVarOrShmDir('cache/' . $this->getEnvironment());
}
public function getLogDir()
{
return $this->getVarOrShmDir('logs');
}
private function getVarOrShmDir($dir)
{
$result = dirname(__DIR__) . '/var/' . $dir;
if (
in_array($this->environment, ['dev', 'test'], true) &&
empty($_GET['warmup']) && // to force using real directory add ?warmup=1 to URL
is_dir($result) && // first time create real directory, later use shm
file_exists('/bin/mount') && shell_exec('mount | grep vboxsf') // only for VirtualBox
) {
$result = '/dev/shm/' . 'YourAppName' . '/' . $dir . '/' . $this->getEnvironment();
}
return $result;
}
I disabled xdebug and it resulted in a decrease loading time from 17s (yea..) to 0.5s.
I had problems as well with slow page loads in development, which can extremely frustrating when you're tweaking CSS or something similar.
After a bit of digging I found that for me the problem was caused by Assetic which was recompiling all assets on every page load:
http://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files-in-the-dev-environment
By disabling the use of the Assetic controller I was able to drastically increase my page load. However, as the link above states, this comes at a cost of regenerating your assets whenever you make a change to them (or set a watch on them).
In app_dev, all the caches and auto loading is starting from scratch and what I found to be most slow in dev is the orm. I shy away from using orm and focus mainly on dbal because of it, although i probably shouldn't. Orm is used quite a bit in sf2. My guess is orm is what's slowing you down most in dev. Look at the difference between your dev config and prod config. However, some tweaks to your dev config can make development much snappier and enjoyable.. Just try and be aware of what your doing. for example, turning off the twig controller and then modifying a lot of templates will be kind of frustrating. Your need to keep clearing your cache. But like you mentioned, its dev only and when its time to go live, symfony will speed up for you.