Okay, might sounds little like a troll but it's not. Since I started to programming with symfony, I encountered very very very weird bugs. Like 3 times in a month. That was always related to my caching files and every time, I spent hours to finally figure it out it was coming from him.
I'm working on a project with cryptography, and when my dear symfony start to forget the keys between two encryption with the same key : I've start to freaked out about the future of my web application.
(the real bug is to weird that I can't really explain it)
I am going to store sensitive data and I can't imagine some of this things append in production and all I can say is since I've cleared AND remove my cache folder, the bug disappear. What a trusting behaviour !
So, are those weird bug only related to development environment due to the large amount of file update ?
What is your context to tell you that you need to clear your cache in development environment ?
Should I deactivate all kind of cache for the production environment to guarantee that will not happen again ?
Thank you guys.
Think 3 time, before you decide to disable cache on prod. It's probably a bad idea.
On dev if you modify bundles, some config, etc, sometimes Symfony fails to refresh cache, and to be sure that errors you receive are real you should delete whole app cache and clear memcached/redis if you use it.
On production you probably will/should create new directory with clean fresh version of your app with clean cache and then you replace your old revision with new one (usually by changing the symlink). Thats why if your app works on dev with clean cache it should be ok on prod env.
I've started using Laravel 5 for a medium-complexity app, and although I was expecting a minor performance impact the framework is proving to be worryingly slow.
I've been developing in a local environment, running Wamp on a Windows 8 environment, i7 with 8GB Ram.
I've run php artisan optimize and enabled apc and I'm still not getting reasonable results.
Should I expect much higher hardware requirements compared to a app developed without any framework (No MVC, Routing, Templating)?
For testing I've setup the simplest route:
public function test(){
return 1;
}
and even this way the request takes ~250-300ms (Chrome)
This is particularly important for my API functionalities.
I'm wondering how much my app could be optimized in a production server environment to minimize response time.
Is it possible to remove unused Laravel components?
Does laravel provide other optimization mechanisms?
Are there better caching alternatives to apc?
Would an SSD be of any help?
Any help on this topic is greatly appreciated. Thanks for your time!
The results you are showing are not okayish indeed.
Do you have any Linux environment to measure performance of the same "test route application" there?
I believe results might be much better.
As simpler option to check: you can try to run Homestead and measure performance within virtual Linux-machine.
I have installed the Skeleton application of ZF2 (from official GitHub repo), and the first page I see takes 400-700ms to load (default "Welcome to Zend Framework 2" page, with no database connections and without handling anything).
In raw PHP (without frameworks) It'll take a few ms. to load.
Could You explain, what caused such a big delays?
I'm new to ZF, and now deciding, to use or not to use it.
Zend Framework is a heavy php framework which uses a lot of php files. Because php is evaluted on the spot it takes a lot of time every request to evaluate these files. You should use a Opcode cache like apc and many others or if you're using php 5.5 Opcache that is built -in. An Opcode cache makes a copy of these evaluated files and stores these in memory. This gives a huge speed bonus.
Another thing that might be the problem is that if you run this ZF2 application with apache on windows it is much slower then apache on linux
It's hard to know whether this is good or bad without any info on the server you're running this test on. You also implied that this was a stock ZF2 skeleton app, but your screenshot shows what I think is the ZF2 developer toolbar, an add-on module.
I just tested a fresh checkout of the skeleton app on my (admittedly decent spec) dev machine and it loads in 30 ms (PHP 5.5). I would expect to be able to improve that with some simple production-type optimizations (classmap, config caching, superluminal etc.).
Edit: I thought I'd see what I could get this down to with some quick tweaks. I also installed the developer toolbar just to be sure this wasn't slowing things down too much. Result:
I search a lot of magento performances articles about magento, I've tested varnish, complier and memcached ...etc. I no doubt with running those cache on Production servers. It runs like a rock, I am happy with that.
But I felt very painful on development magento modules. Whenever I edited lines of codes, I refresh the pages and see the update, it cost me 3~7 seconds on average. I am wondering if there is any order way to speed up on the development stage.
my development environment:
MBA 10.9
Vagrant 1.5 + Virtual Box + Ubuntu 12.04
Nginx + PHP-FPM + PHP5.7
disabled all caches while development <-- I known it.
Is there any tips?
A good start is to use a debugger for PHP, so you do not need to refresh the page so often, saves a lot of time :-) I really regret to have lived in pain for many years ignoring the existence of PHP debuggers.
And for magento speed itself, do not deactivate all caches but do it as you go and as you need it. So you can let the configuration cache ON for most of the time except when you adjust some config XML of your module, then clear the cache once and let it ON.
The same for translation cache. Let them on except you tuned some translation files or web service configurations, clear them if you need it once.
EAV collection cache can stay ON as well if you actually do not work on models.
Only cache you have to disable permanently is block cache for the most dev work.
Last but not least, use APC opcode cache, but ENABLE apc.stat=1
And the last one: Use the best hardware you can afford :-) and consider doing the most work on a powerfull, dedicated desktop maschine instead of virtual one which you can use as backup dev environment if you need to be mobile.
Unfortunately, I've never had a senior developper or mentor to show me some of the best practices. So I develop sites (php/mysql) on my Windows machine with WAMP, I test in hidden (password restricted) folders on the production server and finally move sites to production folder.
I would like to have a more fluid/practical/error-proof setup so that from development > test > production, there is no hiccups.
The important points/questions are (you probably can come up with a lot more):
Ease of use
Easy to dev/test modifications after site is live (to avoid tests on production site)
No server difference between local/test/prod (error reporting, apache setting, etc)
Avoid problem with DB differences (ex: if columns were added, how do you add them to prod DB.?)
Do you skip the test environment or do dev AND test on the same.?
etc...
How do you guys develop PHP/MySQL websites.?
Do you use SVN.? Do you use IDEs.? Do you use VMs.?
Thanks.
This is a kind of frequent question - this is why most seasoned devs do not reply on - and generally end up in a flame war with torrid opinions. So, be careful about that.
But you seem to be an nice guy intending to get on the right paths, seeking for some really productive paths. And I recognize a little about myself on this a few years ago.
OK, first thing to keep in mind is: do not blind follow anyone on anything. Anyone can claim to be a great master, but you can find at least 10.000 guys far way better and completely anonymous. So, for anything you hear about do the following: listen, test, and take your own conclusions. If there is just one golden rule this is it. Everything else is crappy until your own conclusions appear. You are your final judge.
That said, let me begin for the one of the most current question: IDE. What you should use? You should use the one you can produce more and makes you more comfortable. Netbeans, Eclipse, VIM, Notepad++, Notepad, gedit, kate, quanta plus.... You have many options, and each person has it's own opinion. Test what you think interesting and go ahead with the one you choose.
This is true also for any methodology, framework or tool. Use, learn, and get critic about it. Stick with the one which makes you more comfortable and productive.
Same thing for developing environment. Does not matter that much if you develop on Windows, Mac or Linux. The important is get the resources you need available. The resources you need can and generally do change from one project to another.
So the best environment to develop a certain project is one that reflects the real environment where the production will run. What if you develop with PHP 5.3 OOP resources and at the end you get on a PHP 5.1? That's the point. The final environment is who tells you what is the best environment to develop, not the inverse.
For testing, you should trace a strategy. I'm talking about that as a 5 years Test Team Lead inside IBM. This because there are a LOT of testing you can perform, but not all can be really interesting to the current project.
First decide, according to project needs, what you are going to test. Security, performance, UI display, UI effects, error handlings, load and balance, usability, accessibility...
Take notes of what you are going to test (what, when, where, success criteria), and make a report of success and failures.
As I said before, the project needs is what guides you on every step. Testing is not different. If you just need to check the display on different browsers, feel free to use different machines, or VM's.
Generally this is sufficient. But if the project requires performance or load testing, then you will need specific load testing softwares. I will not get deep in this subject as it is very extensive.
It takes some time to find a ideal process and tools match, and after achieve that, you will always discover a new tool to test or a process to make you save a little time. This is IT.
Here's my recommendations:
have a dev environment purely for development. keep a staging and/or a live environment based on the resources you have at your disposal. the staging environment is where you test and ensure there are no serious issue(s) with your application. the live environment is basically your production setup. in fact, the staging and live should ALWAYS be the same. It is useful to reproduce issue(s) on the staging and do a bit of troubleshooting without modifying the code. Bear in mind, this also holds true for any associated databases.
Use SVN or some form of version control. This way you will have the ability to fall back to any stable version of the application if someday the world falls apart!
If you are using Linux environments you can write simple scripts to synchronize the setup with your latest (STABLE) development environment. Ideally, you do your development and conduct unit tests to ensure everything works as per design. Run a script and the staging environment is updated with the latest codebase. Conduct functional tests on staging and ensure that everything works as per specs. Run another script and your latest changes are moved into live/production environment.
My development process is still a bit rough, and I am looking forward to the answers also.
What I do for large projects is setup a git repo on my linux desktop and my windows desktop. I will test locally if possible. As components as finishinged I will push my changes to the centrally hosted git repo (private git hub account usually), or pull them to dev (i setup dev as a repo and pull from ssh). All MySQL updates are stored in update files, and I use netbeans for development (although I have used eclipse and others, netbeans just works for me).
I think you hit on all the important points. Personally, I
run the same OS and server software on the production server and my development system. Same versions of PHP, Python, MySQL, Django, etc.
I don't change DB structure often. I set up the DB tables on the dev. system, then use mysqldump to produce the table creation SQL. I install it on the sever using mysql <name_of_sql.file. When I do make changes, I back up the DB and then just do it through the command line interface. For PHP, I use Doctrine just for the table structure/migration support.
I write everything in Kate (Linux), Komodo Editor(Mac), or Notepad++ (Windows). I don't like IDEs very much, I much prefer to-the-point text editors.
I upload files to a staging dir, and check them with diff before copying them to the actual location.
This isn't the most sophisticated set up, but it's worked quite well for me. I'm the only dev working on the projects I'm involved with, which probably explains a lot. The most important part, that isn't really just personal preference, is the first one - match your dev/test system as closely to the production system as possible, including the OS.