We have just upgraded Sitecore from 6.6 to 7.2, and ECM from 1.3 to 2.1. We are having issues with the Speak UI for ECM being extremely slow. Every operation that seems to fetch data takes several minutes. For example: retrieving the list of recipient lists, where an ajax post request takes minutes to the url http://[domain]/speak/EmailCampaign/TaskPages/AdHockTaskPage?type=Adhoc&id={FD1B449B-C3EA-4820-A10E-E7976A897B8F}&sc_speakcontentlang=nb-NO&ff=1
This is in all our environments (test/production), and we can't get anything from the logs even if we set debug=true on all config settings we can find.
A side note is that we previously used a module to segment the emails (https://marketplace.sitecore.net/en/Modules/Sitecore_EmailCampaign_Segment.aspx) that is deprecated for our version, so we've tried to clean up items and files for this, without anything getting better.
Has anyone had this issue?
I've had some issues in the past with performance. The general advice is to go through the performance tuning document first:
https://sdn.sitecore.net/upload/sdn5/products/ecm/200/ecm_tuning_guide_20-usletter.pdf
There are settings described in the document that can fix issues if you have high CPU usage so you should probably check if your CPU is maxing out. The document also describes some of the tools that you can use to measure performance. I found this tool quite useful to give you an idea of what's going on -
/sitecore/admin/dispatchsummary.aspx.
Failing that, you're best off contacting support.
For anyone with this problem in the future:
This was a bug with the upgrade from 1.3 -> 2.1. Sitecore support filed it as a bug and sent me a dll which partly replaced some rendering logic for a ECM Speak component. So get in touch with Sitecore support and they should be able to help you!
Related
Other than the ability to automatically generate an interactive documentation for our API using Swagger UI, are there any real advantages of using Flask-RESTplus over Flask-RESTful?
I've used both, and the only reason we switched to Flask-restplus was the desire to have auto generated Swagger documentation. In my experience, there are no other noticeable differences. Flask-RESTplus started as a fork of Flask-RESTful, so if you were so inclined, you could read the commit history and see if there are any other noticeable differences.
update When reading this accepted answer, consider that there is Flask-RESTX which is a fork of Flask-RESTPlus that is maintained, as an alternative option.
I am aware of the fact that this answer is probably too late, but it still might be helpful in the future.
According to https://github.com/noirbizarre/flask-restplus/issues/593, the Flask Restplus is most probably dead and abandoned. The last commit was on October 1, 2018. It looks like the project is not being actively maintained anymore.
Therefore, I advise that you use Flask Restful despite the auto generated Swagger docs in Restplus. Since Restplus is not maintained, it is most likely that the implementation will sooner or later go out of date. Rather than switching to Restful once Restplus goes out of date, I think starting off with Restful itself would be the better idea here.
Just my two cents... :)
update You should also consider using FastAPI which is a framework that is becoming popular (see google trends). And, differently from Flask: has built-in data validation, supports asynchronous tasks and you also get the Swagger UI.
You stablish the endpoints with decorators like in Flask and it is reportedly faster.
Check: https://fastapi.tiangolo.com/
Hope it helps.
We have noticed an interesting issue in our Sitecore install. Any auto publish or scheduled publish jobs takes a long time when compared to our other environments. Between each individual job there seems to be a lag of anywhere from 5 to 30 seconds. In our other environments we do not see any lags as difference between 2 publishing jobs in those environments is less than a second.
We have tried the following up until now -
We have already checked for differences between the problematic and
other environments and do not see any differences in configuration or
code.
The caches are pretty similar in all environments.
We tried enabling parallel publishing but that did not make much difference.
Indexing is also very quick in the problematic environment and finishes within one second for each job.
At this point, we are not sure what is causing this issue. Any suggestions would be helpful.
Thanks
As Sitecore would allow maximum one publish to be executed at once to avoid data corruption, I would assume you might add publish jobs faster than they are processed => queueing.
In order to make accurate conclusions, the publish operation needs to be profiled - that will give an answer on wallclock time spend (like ~80% on network + database operations, only 20% in Sitecore code).
You'll need to collect a few 20-second long profiles while observing publishing lag.
From there you'll see how the time is spent.
Please keep in mind that seeing obsolete content in the browser does not necessarily mean publishing is slow - there are 100500 caching layers in the middle that can influence.
Looks like I have similar issue.
Do have multiple IaaS Sitecore installations. 2 environments (hosted on onr VM) have much better performance (package installation, publish etc).
Also have 2 more Sitecore installations on other VM, and publish and package installation there is 4-5 times slower, than on first VM.
I've used the same Sitecore installation configuration, but with different prefix.
In my case i was migrating from Sitecore 8.2 to Sitecore 9.2. Used Unicorn to migrate data, and saw, that content publish (seems, writes to master) is slow right away.
So, on first 2 environments migration with unicorn, content publish and package installation was a way faster, but on 2 other this process is slower.
I am using sitecore 7.5 version with mongo analytics db and I need to override the context language based on Visitor’s Geo IP .
but whenever I call my file on httpRequestBegin Pipeline, current Sitecore.analytics.Tracker.Current is null.
Can anyone please help, I really need to find solution for this?
The tracker doesn't get built until the last processor of httpRequestBegin (ExecuteRequest).
Take a look at my blog post showing the sequence of events http://sitecoreskills.blogspot.co.uk/2015/02/a-sitecore-8-request-from-beginning-to.html
As you cans see, the CreateTracker pipeline is where the action happens. So your work either needs to occur after ExecuteRequest in httpRequestBegin, or if possible, in Createtracker
However, you should know that the Geo IP lookup doesn't necessarily happen immediately. The information might not show up until after the request has completed.
Another approach is to not use the Maxmind lookup that happens as part of DMS. Instead you could download the Maxmind database and do work yourself during the httpRequestBegin pipeline. Since you only need to identify the country, you can use the free version. That way, you don't need to involve the Tracker class.
We are using only portal part of the liferay to show data from some of our applications. It is done thro liferay-ext. Is it possible to rip out the modules unused by us like communities, forums, blogs etc that we dont use. These seem to be hogging tomcat memory.
Thanks
Rama
You can deactivate some portlets that you don't use from ext, it should be available in liferay's administration guide or developer guide on https://www.liferay.com/documentation. Depending on the amount of work you're prepared to put into this you might also want to think about dimensions of your caches and other settings. However, I consider an additional piece of memory to be a lot cheaper than investing the time (again on each update) to trim down Liferay, if it's only for memory reasons.
However, if you "easily" trim Liferay through some means, please provide your findings in the Liferay forums as well - it might be worth feeding it back.
Does anyone have any experience using django-haystack with the whoosh backend?
I'm looking to use it for a categorized live-search type tool. Is it gonna be fast/efficient enough in a production environment to avoid setting up either solr or xapian?
As a general principle, I put Whoosh in the same category as SQLite: great for getting started, wonderful for single-user or really small-scale apps, but not suitable for large-scale deployment.
Whoosh is, in my experience, about an order of magnitude slower than Solr. A typical search against a bigish Solr index I've got in production takes about a hundredth of a second ; the same search using Whoosh and the same data takes roughly a tenth of second.
You should decide what's "fast enough" for you, but I don't think Whoosh is a good idea for anything where you expect high performance.
I found xapian extremely easy to setup on my Debian.
aptitude install python-xapian
and that's all.
To use it with django there is a very good app named djapian.
I would go with either Solr or Xapian (although it's not quite officially supported by haystack yet; see this thread). Solr is easy to setup and get running if you follow the tutorial, however I've had a heck of a time getting it installed in a production environment - but that's mostly due to my lack of experience with Java server environments. Your mileage may vary.
I'd also put in another plug for djapian. It's very well documented and is under very active development.
You should use elasticsearch instead of whoosh....It is more faster and has more functionalities than solr also.