I've go a ubuntu 14.04lts vserver with 2 vcores and 4GB ram (only 200MB used)
on this server are running 4 typo3 instances but all are test installations so they don't have lots of visits.
my problem is that they are very very slow.
cpu usage 2%
ram usage 200MB
what could be a reason for a slow typo3 in frontend as well as in backend.
its typo3 7.6.4
thanks
My solution was to increase the php memory for the server!
TYPO3 is a Complex system. and there are Many Possiblitys why the system could be slow.
here are some suggestions what might be the reason:
TYPO3 Runs in Development mode: See install tool, Development mode disables a lot of Caches and activates additional Debug output.
Extension/Plugin disables frontend cache. some badly written Extensions disable the Frontend Cache.
Database Is Slow by default typo3 uses the MySQL database for storing Caches. if you use are shared database from your hoster you might run into problems.
you are logged in into the backend. (normaly not a major performance hit) but while logged in into the Backend typo3 By Passe some caches.
Related
I like the features of Codenvy but the sever is too long to wake up and can't be used from a mobile. Yes, I code in the subway for hobbies. I had in the idea to install it on a small VPS. I will be coding a Django site roughly the same size as a small eShop. What would be the minimal requirement for the server to run it smoothly?
If you're using Minishift I suggest granting it at least 6GB of RAM.
minishift config set memory 6G
For more information, see the Eclipse Che admin guide
See Eclipse Che documentation - Single-User: Installation on Docker:
Minimum one CPU, 2GB of RAM, 3GB disk space.
Is it possible to install a mongo db version greater than 3.2 on raspberry pi with RASPBIAN JESSIE LITE installed on the pi?
I only succeed to have the version 2.1 using this tutorial.
http://www.widriksson.com/install-mongodb-raspberrypi/
I tried a lot of tutorial but impossible to find one which work for greater versions.
As it was already written in the comments, you are limited to the 32-bit version.
Which comes with severe drawbacks:
The data which can be stored is less than 2Gb (potentially a lot less), since WiredTiger is not available and MMAPv1 is limited to a maximum file size of 2Gb since it makes heavy use of memory-mapping. It simply has a very limited addressable space on 32-bit machines
The WiredTiger storage engine is not available. It allows compression and hence would be especially interesting for limited resources.
MongoDB needs RAM. The more, the better. Indexes need it, connections need it desperately, and hm, the memory mapping makes good use of it. And well, we are only on 32bits. MongoDB Inc decided against creating workarounds for a dying technology. So do not expect this to change
The biggest drawback, however, is that journaling and replication are basically No-Gos since the further limit the amount of data you can store. No journaling translates to limited durability of your data (unless you are willing to force the data to be synced to disk for each write by using an according write concern), while the lack of replication and the resulting lack of failover capabilities most likely is less of a concern on a Raspi.
MongoDB Inc strongly advises against using the 32-bit version for other than testing purposes. And they do so for a good reason. Personally, my generated test data by far exceeds the limitations of the 32-bit version.
So yes, it should be technically possible (and even with no package at hand: compiling MongoDB is no rocket science). Is it a good idea? Well, not so much, if you ask me.
I am the author of the blog http://www.clarenceho.net/2015/12/building-mongodb-30x-for-arm-armv7l.html mentioned by #user3343399
Just to add that Arch Linux ARM latest build of MongoDB 3.2.0 seems to be working fine. Except that the default storage engine was compiled as WiredTiger although there is no 32-bit support from WiredTiger. You will need to add parameter --storageEngine=mmapv1
I have a question that I haven't been able to google the answer for about memcached.
If I have enabled mencached in TYPO3
CLONE a TYPO3 installation(data and files) to a new server.
Upgrade the new cloned installation from 4.7 to 6.2.x
Keep them both running, using the same memcached server.
Will I run into collisions with the memcached keys or other problems related to memcached?
Thanks for taking some time to answer my question
Don't do this. As noted on the wiki there is no namespacing, neither by memcache nor by TYPO3 (which could e.g. just add some prefix). So when using two TYPO3 instances in the same memcache instance, it is possible (and even likely) that the identifiers (e.g. for the cached version of a certain page id) will collide and your production installation might return cached content that your development installation created (have fun debugging this ;-)).
I have Eclipse Juno + latest GWT (GPE 3.1.2+ SDK 2.5.1).
It's just unusable :
Just hang-up now and then (ten times a day), so I have to kill and restart
At best very slow, meaning waiting minutes before UI response for trivial things
After WEB investigation, i did :
increased JVM resources in eclipse.ini
periodically purge the project folder "gwt-unitCache"
For some reason i also tried GWT on Indigo (as the GWT Designer does not run properly on Juno), but it is the same.
The issues seem to be yet somewhere else.
As there as performance issues posted on Google bug list, I am not too sure where I stand.
So my questions :
Does anyone use Eclipse/GWT with fair performances [on Windows ?
(is the issue related to windows -- which I doubt)]
Can anyone provide a set of configuration instructions which can
lead to a stable config ? -- or explain the traps to avoid ?
Before going to Vaadin I wanted to properly handle GWT, but i am close to drop it. Please help.
I would add RAM. 4 gigs sounds pretty slim for a dev machine. An OS with a few apps running will take up 2 gigs. Start eclipse and that's another gig or 2 easy. Then you start running jetty within eclipse for another gig or 2 and now you're hitting your virtual memory / page file which will slow it down tremendously.
Running firefox doing nothing else then looking at a single tab to test my app is 200MB of RAM. Some of my chrome tabs are 100MB easy. Just figure each browser tab eats 3-5% of your 4 gigs.
I'd say get at least 16GB on a 64bit OS and give eclipse and jetty at least 2 gigs each if not 4 each. A solid state disk (SSD) helps a lot too since compiling does a lot of random reads and writes.
Here's a screenshot of the debug settings with 3 gigs of RAM and some extra permgen space for subsequent refreshes of the pages. Just remember, if you run out of physical RAM and it starts hitting the page file these settings won't increase performance!
We are developing our web application using JAVA GWT-P framework (Version 2.4). We are using Eclipse (Version 3.7) Indigo as a development GUI. While we are debugging the application, eclipse is getting hanged generally and surprisingly this is a random behavior.
And this is not happening in only part of the program. Anytime, while we debug, Eclipse hangs in different module.
To resolve this , we tried to use different Operating system such as Windows XP (development gui: Eclipse version 3.7 Indigo), Fedora Version 16 (with development gui: Eclipse version Helios Service Release 2), Cent OS (with development gui: Eclipse version Helios Service Release 2). But no luck.
Can anyone help me out to decide which OS, and eclipse or version should we have to use so can able to resolve the hanging issue?
Use a machine with at least 8G RAM, quad core for GWT development. Anything less than that would be catastrophic and unproductive.
Ideally 8 core, 12 GB.
Increase your eclipse jvm vm heap size max, at startup.
Default eclipse startup is either 256M or 512M. It should be at least 768M. I have tried 1024M which
made only a marginal difference above 768M. I found 900M seems to be
the most that would be used in my cases.
You may have to increase your permgen memory allocation too. I think
permgen space is used for storing class definition and are never
garbage-collected. I presume that when my eclipse hung indefinitely
was when there was no more permgen space to store new class defn.
I have never had to redefine the stackspace allocation for eclipse.
You can google around to find out the jvm startup arguments to define mem allocation. e.g. -Xmx, etc.
Initially develop only for a single browser. Decide between using FF
or Chrome as your dev browser. Then tune your entrypoint gwt.xml to
set the user-agent property for that browser. Google on gwt set
property user-agent. Compiling for only one browser, I have found,
speeds up the compilation a lot.
Don't ever store your projects, source files, resources or libs
that are accessed by the compiler, in a network or usb drive. All your
compilable/includable resources should be on your local drive.
Try to use maven or some other tool for dependency management, so that you do not need to access your jars or dependent projects over the network.
Do not, ever, let your development strategy roll down the hill by
depending on live-project dependencies. Having workspace with 50 or more
projects is disaster and signifies a development team in crisis.
The compulsive and persistent compilation, scanning of projects by
eclipse background take a huge toll on the performance of eclipse.
Try to disable as much validation as possible. e.g., disable html and
javascript validation.
If you have a huge number of server side projects ...
You need to re-architect your development strategy to cluster your 50 - 100 projects into project packages, so that each project package has no more than 20 compilable/validateable project members (ideally less than 5 projects). Each package is frozen by versions and packaged as jars. Use only the jars for development dependencies.
Your programmers need to learn not to have the impulse to work on a workspace with 200 projects. Enhancements are reserved for bugzillas of each project package. Having a 200 project workspace is bad project management. It wastes your programmers' time by having eclipse slow down now and then.
Have sufficient temp space (or for Windows sufficient slack space on
the user disk). I have experienced that insufficient disk space for
compiler buffering/caching has caused slow-downs and hang-ups. Having
a 5G slack space is the minimal - the more the merrier so as to
preclude having to clear the trash or search for files to delete or
clear the GWT compiler generated temp files. A 5G slack space is still
very inconvenient.
AFAI have experienced, neither windows 7/vista or linux made much performance difference except that eclipse seems to start up much slower on Windows.
Therefore, if you know how to tune your anti-virus, may be you should
tell the anti-virus software to skip scanning the workspace and project folders.
Unless you have an 8-core 12GB machine, you should disable most of windows
aero, trasparency. But you need to keep windows compositing
(otherwise you would destroy your eyesight looking at the bad fonts).
THE PROBLEM
I have a GWT project that worked fine on my old core2 machine. When I recently got a new core i7, 8GB ram (Dell XPS Ubuntu developer edition), I discovered that Eclipse hangs VERY OFTEN (about 90% of the startups hang) when I try to start debugging by clicking the browser link under the "Development Mode" eclipse view. There MUST be a thread synchronization bug (deadlock) that can only happen when the 'timing is different' from normal test cases. This fact that it's a timing bug deadlock is why it appears so "random" and has not yet been discovered and fixed. I have all the LATEST GWT at the time I'm writing this, and latest Eclipse etc.
THE WORKAROUND:
Luckily I discovered that if I copy that link and paste it into an already started instance of Firefox (outside eclipse) then there is never any hang. I'm 100% certain that this is not a problem in my code. I'm 95% certain it's a deadlock happening in GWT. So just don't click the "Development Mode" link and you'll be fine. Hope to have helped someone with this post.