joomla is the best one for big portal websites? - joomla

We want to create big portal websites for students.this site full of revenue making and students information.Joomla is the best one to create this site? and joomla is the highly security cms.please give your suggestion.this site will make hits 50,000 on one day.Tell any other cms is best one to create big portal sites.i need your help.

I think Joomla is able to handle huge traffic, but you must take care any extensions you use are really well coded and performant. I mean that there are many extensions which provide really big overhead to your site and might affect performance. My advice would be to hire a really good Joomla developer to implement most of the features of your site (i.e.: Checking any extensions you want to use are ok, or developing new ones). Besides, if your site will need to handle that traffic, you should choose carefully your hosting too ( I am currently working on a site which handles between 30k and 60k visits per day, and server configuration is as important as good coding ).
I hope it helped!
By the way, I don't know much about other CMS, but I think Drupal might be more performant than Joomla, although I prefer Joomla structure and Object-Oriented features (if it hasn't changed, Drupal is primarily based on functions. Joomla is primarily based in Objects, following MVC patterns in most cases.

Joomla is capable of handling huge traffic. I suggest you go ahead.

Related

Laravel for complex browser game website

There is a lot written about the performance of Laravel. It is not the very best framework when it comes to fast applications but it has a lot of options and a brilliant community and documentation. I would like to know if Laravel suits my situation:
I'm currently developing a browsergame that, hopefully, will be played by thousands of visitors worldwide. There could be over 3000 concurrent users at the same time. The application is a bit heavy, because it needs a lot of different modules: views, routing, session management, authentication, database connections, cronjobs and so on. It really is a dynamic game so the application will be loaded a lot of times. And: I don't have that much money to invest in a lot of dedicated servers (at least not in the very beginning).
I looked to other frameworks too. Because Lumen, Slim and some other micro frameworks don't support all of the modules my game needs, I think Laravel is a good choice. But I'm really scared for the benchmarks I see. Laravel doesn't look good there when compared to other frameworks: it's slow, consumes a lot of memory and can't handle many requests.
So my question: is Laravel a good choice for a heavy browsergame website with potential of thousands of concurrent users? Caching and Homestead will help for sure, but is Laravel a good choice at all, or is there a really better framework?
It's less about the framework, and more about how you write your code.
Follow good practices, plan for scaling, and Laravel can absolutely be a very high-performance solution for you. I've heard of some using Laravel with millions of requests per day.
We run a large production app with Laravel, load balanced across multiple web servers, separate redundant database servers, Redis caching, etc. We've had lots of scaling issues, but interestingly none of them were related to the framework. Your main bottlenecks will be elsewhere.
Folks worry way too much about performance before even beginning a project (premature optimization, and all that). Pick the best tool for the job in terms of what it does for you. Then build your app with scaling in mind.
If Laravel provides the functionality you need and you like how it works, use it!

Automation layer above a site

I'm looking into creating a website that sits on top of another site. I wish for this site to be a sort of driver/auto-mater of the original site. The original site is slow and you need to input the same data repetitively (and lots of it - which is infuriating)
What would be the best way of doing this.
I have started using watir-webdriver in ruby, and it seems to work well! Would I be able to host this? I know it launches an explorer (fire-fox in my case) and my worry is not being able to host the application?
I don't want to place all my eggs into this one basket and find out later there's a stumbling block to getting it done!
The short answer
I think there are better tools for web scraping than web testing tools (watir and others), and your end result might require a lot more work than you imagine.
The long answer
This sounds like a case of the façade pattern in which your application would act as the new frontend and the old/existing site as the backend for the improved experience of the service.
Some things to think about before jumping into programming:
If the old site requires users to register, would your users be willing to re-register to your site so that you could log them in into the old site programmatically?
How frequently is the same data required to be inputted and how would you prevent it?
The existing site may have expectations on the request headers which might cause you extra headache and require quite some work to circumvent.
Are you allowed to use the existing site's user interface material or do you need to start from scratch?
How often is the existing site changed and how would it affect your application?
In summary, there are lots of factors and issues to take into account depending on how the existing site is implemented and who are your visioned users. Suggesting a best way to do it would require a lot more knowledge of both the existing site and how you'd want to improve it.
I haven't used watir-webdriver myself but if it is like Selenium and starts a new browser instance any time you run it, then hosting it would most likely not work as you'd expect. There are better tools for what you are thinking of doing, i.e. web scraping, and you may want to take a look at the following, for example:
https://www.ruby-toolbox.com/categories/Web_Content_Scrapers
https://www.ruby-toolbox.com/categories/http_clients

Sitecore with DMS vs caching server - how do you handle it?

We're planning to introduce DMS to our customer's Sitecore installation. It's a rather popular site in our country and we have to use proxy caching server (it's Nginx in this case) to make it high-traffic-proof.
However, as far as we know, it's not possible to use all the DMS features with caching proxy enabled - for example personalization of content - if it gets cached it won't be personalized.
Is there a way to make use of all the DMS features with proxy cache turned on? If not, how do you handle this problem for high-traffic sites - is it buying more Content Delivery servers to carry the load, or extending current server with better hardware (RAM, CPU, bandwidth)?
You might try moving away from your proxy caching for some pages, or even all.
There's no reason not to use a CDN for static assets and media library assets, so stick with that
Leverage Sitecore's built-in html cache for sublayouts/renderings - there are quite a few options for caching
Use Sitecore's Debug feature to track down the slowest components on your site
Consider using indexes instead of doing "fast" or Sitecore queries
Don't do descendants query "//*" (I often see this when calculating selected state for navigation - hint: go the other way, calculate the ancestors of the current page)
#jammykam wrote an excellent answer on this over here.
John West wrote a great blog post on this also, though a bit older.
Good luck!
I've been wondering about this myself.
I have been thinking of implementing an ajax web service that:
- talks to the DMS and returns JSON
- allows you to render the personalised components client side
- allows you to trigger anlaytics events
I have been googling around and I haven't found anyone that has done it and published the information yet. The only place I have found something similar is actually in the mobile sdk, but I haven't had a chance to delve into it yet.
I have also not been able to use proxy server caching and DMS together successfully. For extremely high loads, I have recommended to clients to follow the standard optimization and scaling guidelines, especially architecting for proper Sitecore sublayout and layout caching for as much of the site as possible. With that caching done, follow it up by distributing across multiple Content Delivery nodes with load balancing to help support high volume with personalization at the same time.
I've heard that other CMS's with personalization use a javascript approach to load the personalized content on the client-side, but I would be worried about losing track of the analytics data that is gathered when personalized content is loaded and interacted with.

Do you think ASP.Net Dynamic Data is worth it?

At the risk of sounding misinformed, I'm under the belief that this is basically useful for RAD and fast sketching of an application.
It feels somewhat Ruby-esque in the sense that it scaffolds pretty much everything you need from a CRUD application. Easier work for us, right; and most people are none the wiser.
I'm fairly green in the workplace, I just start working at an actual job as a developer (cubicles and free coffee) so my opinions might be a bit on the green side, but I'd love some comments from more senior people.
Is this somewhere between MVC2(basic scaffolding) and Microsoft Lightswitch(wizard-driven development)? Is it worth ivesting in?
Personally I like to use Dynamic Data for admin pages, those pages that nobody actually gets to see but need to be there in a usable way for some admin user. In the past those used to take quite some effort on the dev team to craft together but with Dynamic Data it's an almost out of the box experience.
I suggest you take a look at Tailspin travel which is an application in MVC 2 but uses Dynamic Data, integrated in the same UI project, for the admin side.
I was skeptical at first, but now I use Dynamic Data almost as much as I do "standard" ASP.NET sites. Out of the box, it's pretty generic, but it's customizable, and you can include standard ASP.NET pages in it.
At first, I would use it as a separate Admin site when I needed a "back door" into the data from a "standard" app. Lately, however, my approach has been to do some more planning, and decide which of the tables I would like users to access via the Dynamic Data mechanisms, and which data I want more fine control over. You can scaffold only the table you want, and this works good for "lookup" tables where you want an end user to be able to add/delete. An example would be in our email coupon program, where customers can sign up to receive coupons via email. They can choose their coupon categories - hot foods, beverages, gas, produce, etc. The administrator of the overall coupon program needs to be able to add and remove categories, and Dynamic Data is WONDERFUL for this sort of thing.
Dynamic data takes care of the data validation (a huge plus for security AND usability), mapping our relationships (a HUGE time saver) and just "does it right". In the business environment, security and productivity are two very real concerns that are handled poorly by most developers, and Dynamic Data seems to handle the basics well.
So yes, I do think it's worth it. It's very powerful and an excellent tool to have in your toolbox, but one that should be wielded with skill, which takes time and practice. And it should not be the only tool in your toolbox.
One of the best uses I've heard for Dynamic Data was to quickly build up an Django-like admin section for a site. It doesn't have to be "perfect" since it isn't aimed at users, but it does give you some nice usability quickly and easily.
I know very little about it but it doesn't sounds like something I would consider. Whenever I work on a an application we tend to follow some basic architectural guidelines such as layering/reusability etc. Typically I tend to get away from shortcut tools/frameworks as this one. There are a lot of "neat" tools that are available in the .NET world that have their place in certain small business/internal app space perhaps, but are not a great idea for a well designed application. For example embedding SQL into the datasource controls that can be bound directly to GridViews, etc.

Where is MVC a bad thing?

I've been reading through a couple of questions on here and various articles on MVC and can see how it can even be applied to GUI event intensive applications like a paint app.
Can anyone cite a situation where MVC might be a bad thing and its use ill-advised?
EDIT: I'm specifically talking about GUI applications here!
I tried MVC in my network kernel driver. The patch was rejected.
I think you're looking at it kind of backwards. The point is not to see where you can apply a pattern like MVC, the point is to learn the patterns and recognize when the problem you are trying to solve can naturally be solved by applying the pattern. So if your problem space can be naturally divided into model, view and controller then it is a good candidate for MVC. If you can't easily see which parts of your design fall into the three categories, it may not be the appropriate pattern.
MVC makes sense for web applications.
In web applications, you process some data (on SA: writing questions, adding comments, changing user info), you have state (logged in user), you don't have many different pages, but a lot of different content to fit into those pages. One Question page vs. a million questions.
For making CMS, for example, MVC is useless. You don't have any models, no controllers, just a pages of text with decorations and menus. The problem is no longer processing data - the problem now is serving that text content properly.
Tho, CMS Admin would build on top of MVC just fine, it's just user part that wouldn't.
For web services, you'd better use REST which, I believe, is a distinct paradigm.
WebDAV application wouldn't benefit greatly from MVC, either.
The caveat on Ruby for Web programming is that Rails is better suited for building Web applications. I’ve seen many projects attempt to create a WebDAV server or a content management system CMS with Rails and fail miserably. While you can do a CMS in Rails, there are much more efficient technologies for the task, such as Drupal and Django. In fact, I’d say if you’re looking at a Java Portal development effort, you should evaluate Drupal and Django for the task instead.
Anything where you want to drop in 3rd party components will make it tough to work in the MVC pattern. A good example of this is a CMS.
Each component you get will have their "own" controller objects and you won't be able to share "control" of model -> ui passing.
I don't necessarily know that MVC is ever really a bad idea for a GUI app. But there are alternatives that are arguably better (and also arguably worse depending on whose opinion you're asking). The most common is MVP. See here for an explanation: Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask.
Although I suppose it might be a bad idea to use MVC if you're using a framework or otherwise interacting with software that wasn't designed with MVC in mind.
In other words, it's a lot like comparing programming languages. There's usually not many tasks that one can say that one is better than the other for. It usually boils down to programmer preference, availability of libraries, and the team's experience.
MVC shouldn't be used in applications where performance is critical. I don't know if this still applys with the increase of computing power but one example is a call center application. If you can save .5 seconds per call entering and updating information those savings add up over time. To get the last bit of performance out of your app you should use a desktop app instead of a web app and have it talk directly to the database.
When is it a bad thing? Where ever there is another code-structure that would better fit your project.
There's countless projects where MVC wouldn't "fit", but I don't see how a list of them would be of any benefit..
If MVC fits, use it, if not, use something else..
MVC and ORM are a joke....they are only appropriate when your app is not a database app, or when you want to keep the app database agnostic. If you're using an RDBMS that supports stored procedures, then that's the only way to go. Stored procs are the preferred approach for experienced application developers. MVC and ORM are only promoted by companies trying to sell products or services related to those technologies (e.g. Microsoft trying to sell VS). Stop wasting your time learning Java and C#, focus instead on what really matters, Javascript and SQL.

Resources