Hey guys I'm playing with sonata and trying to create a simple backend for a few related models. But my pages are generated in about a second for quite a simple page.
http://i.imgur.com/VPLII4B.png
Most of the time takes twig templates processing. But event on simple non-sonata pages (in this project) it takes quite a while to generate a page http://i.imgur.com/Se376oi.png
I wrote a simple twig extension to measure time in prod env and it doesn't actually differ much from dev.
I have quite powerful laptop (i7 - 8 cores with 8 gb ram, NON-SSD 7200 rpm hard) and I even tried to deploy the project on the powerful server and the time also didn't differ much (about 10-15%).
Am I doing something wrong? I use php 5.6 on local machine with opcache enabled
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=400
opcache.max_accelerated_files=10000
What is page generation time for your real projects?
Related
This question already has answers here:
AngularJS 1.4 --> Angular 9 migration vs bigbang rewrite [duplicate]
(2 answers)
Closed 2 years ago.
I have done a ton of research and haven't found anything that has helped me decide what will be the best route (vertical slicing, horizontal slicing, or just a complete rewrite). I am working on a very LARGE program that is very ugly with no comments and need to migrate it over to Angular 8 if possible or at least up to Angular 7. A lot seem to recommend https://angular.io/guide/upgrade however, they don't help too much in migrating to 1.5 first. Does anybody have experience with a large scale migration? Currently, the program is not being used so downtime is no issue.
It doesn't seem like it at first, but a re-write is usually a more cost effective solution than an upgrade. It seems like upgrade would be the fastest time to re-deployment but in my experience if you did the two side-by-side you might find the times similar, except that the migration deployment will have to be all or nothing, where as a re-write means you can deploy with reduced functionality and build up the feature.
More importantly, the on-going maintenance of an upgraded site becomes exponentially harder/time consuming. You're really applying band-aides over the top of previous patches and fixes.
There are new concepts, better native support for directives and controls that we used to use 3rd parties for or roll own own, and it's an entirely new language to understand. Take this opportunity to wipe the slate clean of your solution's technical debt.
Rewrite - Hybrid
Do you need to deploy eveything in one go? Are you interested in Re-Branding?
One thing the Microsoft have done well in the past is the hybrid roll-out of their Preview portals.
The best case study IMO is the Azure Portal.
A few years ago we had a pretty fully featured portal interface for managing Azure assets. This would later become known as the Classic Portal when they started work on an entirely new user experience.
At first release the menu system was largely complete, we could navigate most assets in the new portal but when you came to features that had not been redesigned yet the link took you back to the Classic Portal.
So you could do the same, have the two user interfaces deployed to different URLs, start by making sure the authentication and navigation is largely complete but make all links take the user back to the original interface. Then feature by feature, implement the new interface, but because you can't control everything, keep a button or link on each page that takes the user back to the original implementation until your regression testing confirms that you have reached feature parity.
That is another key take-away from the MS Hybrid approach, significant change like this WILL annoy your users. So while you are in transition, allow the user to choose when they themselves migrate over. Initially MS achieved this at login, the user could login at either of the main urls, and based on your profile you would be redirected to the portal of your choice.
The last step is to restrict access to features in the old interface, by making the navigation and links in the old portal navigate directly into the new interface.
- or less intrusive, add an 'end of life' banner in each page that you have compelted the re-write on in the old site.
Do not confuse this with the Preview Mode in Office 365, the Azure Preview Portal was a ground-up re-write and is still in progress. There are many licensing operations that I still use the Classic Portal for as I still manage some Classic Only azure assets that have not yet been re-deployed.
I would consider the following issues when choosing between Migration/Upgrade and a straight up re-write:
Migrate to AngularJS 1.5 first
This operation is only marginally easier than the upgrade to Angular2+. All of the arguments below apply equally to this process as they do the next upgrade.
One of the reasons to goto 1.5 first is to escape the legacy dependencies that do not have a simple direct upgrade to 2+.
During the upgrade to 1.5 you should consider implementing Component based architecture (if the current code does not already do so)
A key element of components is less configuration and simplifed design, so read this as less to upgrade, less that can go wrong
Components are of course more closely aligned with current Angular implementations, if you do not yet use AngularJS Components, that might be a good iterim step to understand before learning Angular 2+
No Comments
This is a bigger red flag than you think. If the code base is not documented then any sort of maintenance becomes incrementally harder as each time the code must be re-read and re-interpreted before you can affect change.
So if a migration is on the cards, where talking about every line of code at some point needed to be re-read and understood to make sure that it works correctly in the
AngularJS 1+ => Angular2+
While some of the core frameworks and 3rd party libraries can be migrated, most controller javascript files cannot be simply migrated to typescript without a fair amount of effort. It's pretty common in javascript to cut a lot of corners in terms of type definitions and locations of definitions that mean after migration you will spend a lot of time going back through most javascript files one method at a time.
Very large
This is a strong candidate for automation or migration but ultimately it means that the total surface area to test, debug and re-design is also very-large. If the initial migration does not compile, it could be a long road of tweaking before you can get the user interface up so you can start interface testing.
I've been working with Oracle PL/SQL and forms ¿for the last 20 years.
Like 8 years ago oracle people started to say their route map was that every new development should be done in Java with ADF and not in forms.
5 years ago we had to start a new project so we did it using that technology, because we had the feeling that sooner or later Oracle was going to stop suporting and publishing new versions of forms and reports.
The project was successful, but mantinance, deployment and configuring the developer's PC's is a lot hard and painful.
Starting with the fact that we have to deploy all the application every time we do an small change in any page, comparing with the fact that in forms we just have to deploy the altered form's FMX
And that is not the most unconfortable part, some times we deploy the applications EAR and we do not know why some classes are missing, so we have to compile everything again and deploy again.
In the last month we had to change our old Win 7 PC's for new ones, but I do not know why when I run the ant XML that should generate the EAR it does not find oracle.jbo.server package
Is this developing environmet always so hard and buggy ???
Although I understand this thread below is a bit old... but still a good source to refer it.
What is Oracle ADF?
html sites are fast but cms (WordPress/magento) sites are slow on my server. I cant find the reason. This is my default WordPress site without theme and any plugins. Just installed. http://www.googlecloudhost.com/. It took 90+ seconds to load but this html site http://sohamdistributors.com/. This takes less than 2 seconds to load.
Please help me to find the reason of slow cms site.
Sites using WordPress/Magento are slower than sites using static HTML because of PHP and database usage. Your site on googlecloudhost.com seems slower than it should be though, it takes 20+ seconds for the server to respond.
To make sure the problem is not caused by a plugin you are using on your website you can use the Plugin Performance Profiler plugin for WordPress.
To increase performance you can also use a caching plugin like W3 Total Cache.
If both options do not solve your problem consider consulting your hosting provider, the problem could be caused by their setup then.
I introduced Sencha grid in one of my JSPs. Locally sencha is quite fast but on an external server it is too slow.
I followed deploy instructions here
http://docs.sencha.com/ext-js/4-0/#!/guide/getting_started
using ext-debug.js and my app.js.
Then, in my JSP, I imported app-all.js (670KB) and ext.js
Where am I wrong ?
Thanks
app-all.js is 670KB, which is a very big file. You should refactor, optimize and minify the code so it will be smaller. You could even separate into multiple files per class or implementation and do a dynamic js load (but that would take more time). A good target would be as small as ext.js's.
Also if you have access to your webserver (i.e. Apache/Tomcat), you could turn on gz compression to compress files before sending to browsers. Also look out for other webserver optimizations.
(btw, your question sounds more like a webserver issue rather than a sencha related issue).
Another way to improve the load time of your application is making sure ext.js and app-all.js are cached by the browser. This way the first time your application loads it will be slow, but the following loads will be faster.
Look into the cache-control, expires and other HTTP cache controlling headers (this appears to be a nice explanation). Your server should generate this headers when sending the files you want to be cached.
The real problem, as it appears from the timeline, is the slow connection to the server (10 seconds loading 206/665 KB is slow for most connections), so you should see if there are no other server problems causing the slowness.
i'm working on drupal community site and i want to ask about this things :
1 - how to hide the drupal information from my site ?
2 - how to make the drupal site more secure ?
3 - how to make my site work as fast as possible when there is a lot of visitors and users on the site
and there is a lot of interaction with the database at the same time?
4 - how to configure drupal to work with high server load and how to configure my server's hardware to work with high load ?
thank you
1 - how to hide the drupal information
from my site ?
What information? You can show/hide anything in your theme implementation
2 - how to make the drupal site more
secure ?
Stay up to date.
3 - how to make my site work as fast
as possible when there is a lot of
visitors and users on the site and
there is a lot of interaction with the
database at the same time?
4 - how to configure drupal to work
with high server load and how to
configure my server's hardware to work
with high load ?
Start with the pantheon project use it and learn from it:
Pressflow (a performance tuned version of Drupal)
Varnish Reverse Proxy Cache for anonymous users
APC for OpCode Caching
Memcached for easing the load on the DB
Use as few modules as possible.
The first area to need help in a social setup (lotsa logged in users posting content) is likely going to be the DB and so learning how to use Memcached will go a long way to helping you scale at the start
For further reading on Drupal Performance you might want to read everything from 2bits:
http://2bits.com/contents/articles
1 - how to hide the drupal information from my site ?
Remove the credits block.
Use template files, so that the look and feel is different from default Drupal sites.
Optimise your jss and css, so that it is difficult to identify that it is from Drupal.
Remove changelog.txt file from root.
2 - how to make the drupal site more secure ?
Have the latest stable version of Drupal and keep all your modules upto date. (Regularly check for security patches if there are no updates)
Install security review module
Theme is the weakest link in Drupal security. While theming make sure that you follow all the Drupal standards. Remember to sanitize data and use Drupal functions wherever possible.
3 - how to make my site work as fast as possible when there is a lot of visitors and users on the site and there is a lot of interaction with the database at the same time?
Memcache : high-performance, distributed memory object caching system. Eases the load on DB
Intelligent use of cache API in your custom modules.
4 - how to configure drupal to work with high server load and how to configure my server's hardware to work with high load ?
CDN : Content delivery Network, use this if you are rich enough.
Press Flow : Out of box performance for your Drupal site, from Four Kitchens.
Varnish : Reverse Proxy Cache
Try using Pantheons hosting service at: http://getpantheon.com/
We are using it, and are very happy with it so far.
1: Don't bother.
2: Make sure you keep your Drupal installation (including third-party modules) up to date.
3 and 4: Caching is a good step to take. Drupal comes with some handy caching features built-in (in the Performance settings), and modules like CacheRouter and Boost take you a long way further.
1 - What information exactly do you want to hide?
3 - Use the Devel modules to see what's happening. There's a lot of tweaking invovled here, especially if your using Views.
4 - Cache modules such as boost do a lot. Then there are things such as the web server, Nginx for example is generally faster then Apache, especially serving static content (and PHP-FPM for dynamic). You should also check out Memcached, APC or another php cache and of course Varnish cache is pretty awesome.
I saw above you mentioning making Drupal working with more than one databases. If you mean replications, I think that's directly covered in Pressflow's introduction here.