Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I was asked this question once at an interview:
"Suppose you own a website where the server is at some remote location. One day, some user calls/emails you saying the site is abominably slow. How would you identify why the site is slow? Also, when you check the website yourself as any user would (using your browser), the site behaves just fine."
I could think of only one thing (which was shot down):
Check the server logs to analyse incoming traffic. Maybe a DoS attack or exceptionally high traffic. Interviewer told me to assume the server has normal traffic and no DoS.
I was kind of lost because I had never thought of this problem. I have almost no idea how running a server/website works. So if someone could highlight a few approaches, it would be nice.
While googling around, I could find only this relevant, wonderful article. That article is kind of too technical for me now, but I'm slowly breaking it down and understanding it.
Since you already said when you check the site yourself the speed is fine, this means that (at least for the pages you checked) there is nothing wrong with the server and it can serve those pages at a good speed. What you should be figuring out at this point is what the difference is between you and the user that reports your site is slow. It might be a lot of different things:
Is the user using a slow network connection (mobile for example)?
Does the user experience the same problems with other websites hosted at the same webhoster? If so, this could indicate a network problem. Normally this could also indicate a resource problem at the webserver, but in that case the site would also be slow for you.
If neither of the above leads to an answer, you could assume that the connection to the server and the server itself are fine. This means the problem must be in the users device. Find out which browser/OS he uses and try to replicate the problem. If that fails find out if he uses any antivirus or similar software that might cause problems.
This is a great tool to find the speed of web pages and tells you what makes it slow: https://developers.google.com/speed/pagespeed/insights
I think one of the important thing that is missing from above answers is the server location, which can play a vital in web performance.
When someone is saying that it is taking a longer time to open a web page that means high latency. High latency can be caused due to server location.
Let's assume as you are the owner of the web page then the server and client are co-located, so it will have a low latency.
But, now if client is across the border, then latency time will increase drastically. And hence a slow perfomance.
Another factor is caching which drastically affects the latency time.
Taking the example of facebook, they have server all over the world to reduce the latency time (and also to provide several other advantages) and they use huge caching system to cache their hot data (trending topics) whereas cold data (old data) are stored in hard disk so it takes a longer time to load an older photo or post.
So, a user might would have complained about this as they were trying load up some cold data.
I can think of these few reasons (first two are already mentioned above):
High Latency due to location of client
Server memory might need to be increased
Number of service calls from the page.
If a service could be down at the time of complaint, it could prevent page from loading.
The server load might be too high at the time of the poor experience. The server might need to increase the resources (e.g. adding another server/web server to the cluster).
Check if there was any background job running on the server at that time.
It is important to check the logs and schedules of the batch jobs to determine what all was running at that time.
Hope this help.
Normally the user takes the page loading time as a measure to find out that the site is slow. But if you really want to know that what is taking the maximum time the you can open the browser debugger by pressing f12. if your browser is chrome the click on network and see what calls your application is making and which are taking maximum time. If you are using Firefox the you need to install firebug. If you have that, then again press f12 and click on Net.
One reason could be the role of the user is different of your role. You might be having suppose an administrator privilege (some thing like super user role) and the code might be just allowing everything for such role that means it does not really do much of conditional checking to see what is allowed or not. Some times, it's a considerable over ahead to get all the privileges of the user and have the conditions checking, how course depends how how the authorization is implemented. That means, the page might be really slow for specific roles. Hence, you should find out the roles of the user and see if that is a reason.
Obviously an issue with the connection of the person connecting to your site OR it's possible it was a temporary issue and by the time you checked your site, everything was dandy. You could check your logs or ask your host if there was an issue at the time the slow down occured.
This is usually a memory issue and it can be resolved by increasing the Heap Size of the Web Server hosting the application. In case the application is running on Weblogic Server. Heap size can be increased in "setEnv" file located in Application Home.
Goodluck!
Michael Orebe
Though your question is quite clear, web site optimisation is a very extensive subject.
The majority of the popular web developing frameworks are for some reason, extremely processor inefficient.
The old fashioned way of developing n-tier web applications is still very relevant and is still considered to be best practice according the W3C. If you take a little time to read the source code structure of the most popular web developing frameworks you will see that they run much more code at the server than is necessary.
This may seem a bit of a simple answer but, the less code you run at the server and the more code you run at the client the faster your servers will work.
Sometimes contrasting framework code against the old fashioned way is the best way to get an understanding of this. Here is a link to a fully working mini web application which represents W3C best practices and runs the minimum amount of code at the server and the maximum amount of code at the client: http://developersfound.com/W3C_MVC_EX.zip this codebases is also MVC compliant.
This codebase comes with a MySQL database dump, php and client side code. To see this code in action you will need to restore the SQL dump to a MySQL instance (sql dump came from MySQL 8 Community) and add the user and schema permissions that are found in the php file (conn_include.php); setting the user to have execute permissions on the schema.
If you contrast this code base against all of the most popular web frameworks, it will really open your eyes to just how inefficient these frameworks are. The popular PHP frameworks that claim to be MVC frameworks aren’t actually MVC compliant at all. This is because they rely on embedding PHP tags inside HTML tags or visa-versa (considered very bad practice according the W3C). Also most popular node frameworks run way more code at the server than is necessary. Embedded tags also stop asynchronous calls from working properly unless the framework supports AJAX dumps such as Yii 2.
Two of the most important rules to follow with MVC compliance is: never embed server side tags (such as PHP tags) in HTML tags or visa-versa (unless there is a very good excuse such as SEO) and religiously never write code to run at the server if it can be run at the client. Also true MVC is based on tier separation, where as the MVC frameworks are based on code separation. True MVC compliance is very processor efficient. Don’t get me wrong MVC frameworks are very useful for a lot of things, but if you’re developing a site that is going to get millions of hits, they are quite useless, or at least they will drive your cloud bills so high that it will really eat into your company’s profits.
In summary frameworks don’t give much control over what code runs at the client or server and are very inefficient but you can get prototypes up and running quicker with less code.
In contrast the old fashioned way takes a bit more elbow grease but you have complete control over what runs at the server and what runs at the client.
As an additional bit of advice for optimisation avoid using pass-through queries and triggers and instead opt for stored procedures. Historically stored procedures weren’t invented at the time MVC was present as a paradigm but it definitely increases separation of concerns between the tiers and is much more processor efficient.
Hope this advice helps.
Related
Given: Each call to a BE module takes several seconds even with a SSD drive. (A well configured setup runs below 1 second for general BE tasks.)
What are likely bottlenecks?
How to check for them?
What options to speed up?
On purpose I don't give a special configuration, but ask for a general checklist, so that the answer is suitable for many people as first entry point.
General tips on performance tuning for TYPO3 can be found here: https://wiki.typo3.org/Performance_tuning
However, in my experience most general performance problems are due to one of a few reasons:
Bad/no caching. Usually this is a problem with one or more extensions (partly) disabling cache. Try disabling all third party extensions and enabling them one by one to see which causes the site to slow down the most. $GLOBALS['TSFE']->set_no_cache() will disable all cache, so you could search for that. USER_INT and COA_INT in TypoScript also disable cache for anything that's configured inside there.
A lot of data. Check the database for any tables containing a lot of data. How many constitutes "a lot", depends on a lot of factors, but generally anything below a million records shouldn't be too much of a problem unless for example you do queries with things like LIKE '%...%' on fields containing a lot of data.
Not enough resources on the server. To fix this, add more memory and/or CPU cores to the server. Or if it's a shared server, reduce the number of sites running on it.
Heavy traffic. No matter how many resources a server has, it will always have a limit to the number of requests it can process in a given time. If this is your problem you will have to look into load balancing and caching servers. If you don't (normally) have a lot of visitors, high traffic can still be caused by robots crawling your site too quickly. These are usually easy to block on IP address in your firewall or webserver configuration.
A slow backend on a server without any other traffic (you're the only one who can access it) rules out 1 (can only cause a slow backend if users are accessing the frontend and causing a high server load) and 4 (no other traffic).
one further aspect you could inspect: in the user record a lot of things are stored, for example the settings you used in the log module.
one setting which could consume a lot of memory (and time to serialize and deserialize) is the state of the pagetree (which pages are expanded/ which are not).
Cleaning the user settings could make the backend faster for this user.
If you have a large page tree and the user has to navigate through many pages the effect will stall. another draw back: you loose all settings as there still is no selective cleaning.
Cannot comment here but need to say: The TSFE-Object does absolutely nothing in the TYPO3 Backend. The Backend is always uncached. The TYPO3-Backend is a standalone module to edit and maintenance the frontend output. There are tons of Google search results that will ignore this fact.
Possible performance bottlenecks are poor written extensions that do rendering or data processing. Hooks to core functions are usually no big deal but rendering of many elements for edit forms (especially in TYPO3s Fluid Template Engine) can cause performance problems.
The Extbase-DBAL-Layer can also cause massive performance problems. The reason is the database model does not know indexes. It' simple but stupid. A SQL-Join on a big table of 2000 records+ will delay the output perceptibly, depending on the data model.
Also TYPO3 Backend does not really depend on the Typoscript-Configuration but in effect to control some output or loaded by extensions, the full parsing of the *.ts files is needed. And this parser is very slow.
If you want to speed things up you need to know what goes wrong. The only way to debug this behaviour is to inspect the runtime with a PHP profiling tool like xdebug because the TYPO3 Framework is very complex. It's using some kind of Doctrine Framework and will load tons of files, by every request. Thus a good configured OpCache is a must.
Most reason the whole thing is slow is because it is poor written. You can confirm that fact by inspecting the runtime.
In addition to what already has been said, put the runtime environment onto your checklist:
Memory:
If heavy IDE and other tools are open at the same time, available memory can become an issue. To check the memory profile, you may start a tool that monitors the memory usage of the machine.
If virtualization is used, check the memory assigned to the box. Try if assigning more memory improves behaviour.
If required and possible spend more memory to your machine. This should not be a bugfix to poorly written code. Bad code can blow up any size of memory.
File access:
TYPO3 reads and writes thousands of files. If you work with a contemporary SSD, this is surprisingly fast. I did measure this. Loading all class files of TYPO3 takes just a fraction of a second.
However this may look different if you do not work with a standard setup. Many factors may slow you down:
USB-Sticks as storage.
Memory cards as storage.
All kind of external storage may be limited due to slow drivers.
Virtualization can become an issue. Again it's a question of drivers.
In doubt test and store your files and DB on a different drive to compere the behaviour.
Routing
The database itself may be fast. A bad routing of your request may still slow you down. Think of firewalls, proxies etc. even on your local machine and specially if virtualisation is used.
Database connection:
I fast database connection is crucial. If the database access is slow TYPO3 can't be fast.
Especially due to Extbase TYPO3 often queries much more data than really required and more often than really required, because a lot of relations are resolved in the PHP layer instead of the DB layer itself. Loading data structures like the root line may cause a lot of ping-pong between the PHP and the DB layer.
I can't give advice, how to measure your DB-connection. You have to as your admin for that. What you always can do is to test and compare with another DB from a completely different environment.
The speed of the database may depend on the type of the database itself. Typically you use MySQL/Maria-DB which should be fast. It also depends on the factors mentioned above, memory, file access and routing.
Strategy:
Even without being and admin and knowing all performance tools, you can always exchange parts of your system and check if matters improve. By this approach you can localise the culprit without being an expert. Once having spotted the culprit, Google may help you to get more information.
When it comes to a clean and performant setup of routing or virtualisation it's still the best idea to ask an experienced admin.
Summary
This is all in addition to what others have already pointed to.
What would be really helpful would be a BE-Plugin, that analyses and measures the environment. May there are some out there I don't know.
I implemented oplog on our server and that time our application response time improved but after some hour response time increased and application response was very slow.
Can you let me know the
Disadvantage of Oplog
Impact of Oplog on Meteor Application
what needs to take care while implementing oplog.
Please help me I go through several video and link but not find any satisfactory answer, thanks.
As mentioned in the comments, this is a very broad question and the "correct" answer completely depends on your specific situation (e.g. app needs, use case, etc.). Nevertheless, here is my attempted answer based upon having been thru the challenges of scaling Meteor apps.
If at all possible, you will want to enable oplog tailing in your production Meteor app. If you have done any Meteor development, then you are used to using the oplog because it is enabled by default.
The symptom you describe of the application response times increasing over time and becoming very slow is likely the result of something else going on with your app or hosting environment / infrastructure. I have run multiple production Meteor apps with 100+ simultaneous users and have never experienced this occurring.
There is one specific situation where you would NOT want to use the oplog and that is if you have a complex query where the bulk of the resulting data gets updated often. This can causing CPU spikes and/or thrashing and will kill your apps performance. I have one such application that falls into this category and after extensive testing, I found that it is much better to disable oplog on the query and increase the pollingThrottleMs accordingly. Again, this is an exception case and represents about the only time that you would want to stay away from using the oplog.
These are just some very surface level thoughts on the use of oplog based on my experience. I encourage you to experiment and see what works best for your app.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have a couple of different projects running for the moment - some PHP apps and a few WordPress instances, which all currently are kept at a web hosting company. The contract period time is about to end and I would lie if I wouldn't say that I really had considered making the switch onto a VPS server in the cloud with the prices getting really great.
I am totally in love with the fact of being able to turn the performance up or down when demand increases, or goes away and thereby cut the costs.
With my background as a PHP developer, with only a little hint of Linux (ubuntu) knowledge, I am thoroughly concerned about the security if I should run my own VPS.
Sure, I am able to install and get things running with my current knowledge (and some help by Google), but is it realistic nowadays to expect that my server (LAMP, really) will stay secure by running out-of the box stuff and keeping it up-to date?
Thanks
Maintaining your server is just one more thing to worry about, and if you're a developer, your focus should probably be on development. That said, it needs to make financial sense to go the managed route. If you're just working on toy projects (I've got a $20/month VPS that I use for my personal projects and homepage, and it's pretty hands-off) or if you're just getting off the ground, VPSes have the great advantage of being cheap and giving you lots of control of your environment. You can even mitigate some of the risk by keeping aggressive backups, since it's easy to redeploy a server quickly.
But, if you get to the point where it won't affect your profitability to do so, you probably should seriously consider getting someone else to take care of infrastructure for you either by buying managed hosting services or hiring someone to do it for you. It all depends on what you can afford to lose if you get rooted and how much time you can afford to invest in server management and recovery as opposed to coding.
I wouldn't. We did the same thing because the non-managed VPS are sooo cheap, but unless you really need to install applications or libraries that are not part of standard shared host setups, in my experience, being a pure developer as well, the time spent is never worth it.
Unless, of course, it is your own tiny blog or you just want to play around.
But imagine you (or whichever automation you use) update php, and for some reasons it fails (or worse, you render your current installation unusable) - are you good enough to handle this? And if so, how long will it take you? Do you have a friend at hand who can help?
We, as a small company, are getting rid of our VPSs step-by-step and moving back to our reseller package, hosted at a good hosting provider.
Good question, though.
As for security, I have successfully used Amazon EC2 for a number of things. It's not the cheapest around, but quite comprehensible in shared data stores between instances, connection to S3, running hosts at different hosting centers etc, grouping hosts in different clusters, etc etc.
They have a firewall built in, where you can turn all things off except say, TCP traffic on port 22 for SSH and 80 for web. That combined with something like Ubuntu, where you can easily run updates without worrying much about breakage, is probably all you need from a security point of view.
You need consider cloud computing as a statement of avaibility, not cost. You can be seriously surprised about the cost at the end.
I already have optioned to use VPS hosting. Good VPS hosting is costly, these days you may find cheap dedicated host compared to VPS. Have look at hivelocity.com – I like their services.
About security, most VPS host company takes care of security for you at the infra-structure level, and some may use antivirus software on files. On dedicated host, you need to take care by yourself or contract managed support services: a tradoff.
LAMP server is cheap everywhere. You can hire a private VPS and have some security, you may count on services like DNS hosting too – this is trouble to configure. VPS can be your first step as you're doubtful and has no experience on hosting. Thereafter when you find out the advantages of having your own server, you'll migrate straight to dedicated server.
What is acceptable from a security standpoint will differ depending on the people involved, what you want to secure and requirements of the product/service.
For a development server I usually don't care so much, so I usually do some basic securing of the server and then don't pay attention to it again. My main concern is more of someone getting a session and using my cycles to run something. I don't normally care about IP so that's not a concern for me.
If I'm setting up a box that has to meet Sarbanes-Oxley, Safe Harbor, or other PII/PCI standards I must meet I would probably go managed just because I don't want the additional security work load.
Somewhere in between is a judgment based on if I want to commit the required time to secure the server to the level I want it secured at. If I don't want to do it myself I pay someone to do it.
I would be careful about assuming your getting a certain level of security just because your paying someone to manage your server. I've come across plenty of shops where security is really an afterthought.
If I understood you correctly, you are considering a move from a web host to a VPS, and wonder if you have the skills to ensure the OS remains secure now that it's under your control?
I guess it's an open-ended question. You are moving from a managed environment to an unmanaged environment, and whether you maintain your environmental security is up to you. If you're running your own server then you need to make sure that default passwords aren't in use (for the database, OS and any services on top), patches are quickly identified and applied, host firewalls are configured properly and suspicious activity alerts are immediately sent to you. Hang on, does your current web host do any of this for you? Without details about your current web host and the planned VPS, you are pretty much comparing apples to oranges.
BTW, I would be somewhat concerned about my LAMP server security, but frankly I would be much more concerned about development errors (SQL injection, XSS) and the packages running on top of my server (default passwords + dev errors).
For a lamp stack, I would probably not do it. It would be a different case if you were using a Platform-as-a-service provider like Windows Azure - by my own experience there is minimal operational overhead and you just upload the app and it runs in a vm (and yes it supports php).
But for Linux there are no such providers that I know of, which means you will have to manage the Operating system, the app frameworks, the web server and anything else that you install on the instance. I wouldn't do it myself. I would consider the options as hiring a person with the relevant experience to do this for me vs the cost of managed services from the vps provider and go with one of those two.
Rather than give you advice about what you should do, or tell you what I would do, I'm just going to address your question "is it realistic nowadays to expect that my server (LAMP, really) will stay secure by running out-of the box stuff and keeping it up-to date?" The answer to this question, in my opinion, is basically yes.
dietbuddha is right, of course: what constitutes an acceptable level of security depends on the context, but for all but the most security-sensitive purposes, if you're using a current (i.e. supported) distro, with sane defaults, and keeping up with the security updates, then you ought to be fine.
I have two VPSs, each of them currently runs Ubuntu 10.04 server. On one of them, I spend some time installing and configuring tiger, tripwire, and taking various other security measures. On the other, I simply installed fail2ban and set security updates to automatic, and left it at that. They've been running for a few years, now, and I've had no problem with either.
You should do it for fun and for learning purposes. Other than that, don't; you're wasting your own time and a lot of other people's time.
I say this because I've wasted serious time setting up an EC2 instance to host my SVN server and a few other things. I mean, I loved setting everything up and messing w/ the server; I learned a lot especially because I'd never done anything a LINUX server before. However, looking back, I wasted a ton of time and had to keep buggin #Jordan S. Jones for help.
I was inspired by Slashdot, I was heard that it uses very limited servers to support a lot of users with fast response. And there is a website named slashcode, not sure if slashdot uses its source code.
I am wondering if Perl is the best to write a high performance web page? I know using Apache or IIS will be having a lot of overhead?
Any idea, books, papers, tutorials?
I'm going to assume that by "high performance" you mean both in the real time taken to produce a page and also how many it can serve concurrently.
The programming language isn't so important as your servers and algorithms. You may want to look into The C10k Problem which is a series of new technologies and refinement of techniques with the aim to allow a single web server to concurrently handle more than 10,000 concurrent connections. Things like the Nginx and lighttpd web servers and varnish cache came out of this project.
Big wins come from using a very light, very fast, very modular web server (Apache and IIS ain't it) with a very light, very fast cache in front of it to avoid having to process the same thing twice. For a high concurrency server, even caching for a few seconds can save you hundreds or thousands of processes. By chopping up a static page into a series of AJAX requests you can cache the more static bits and pieces independently of the bits that change frequently.
Instead of using mod_blah that embeds your program into a web server, use FastCGI or similar that puts your programs into their own little application servers. This allows them to run independent of the web server, possibly on remote machines and with load balancing. This lets you easily scale your processing power.
Eventually you're going to micro-optimize really important bits of your application code to the point where the language matters, but you can focus on the really important bits rather than having to do the whole project solely according to raw performance.
Regardless of how fast your code is, at some point the bottleneck will stop being your code, and start being the web server itself.
As long as you're not using the CGI interface[1] to talk to the web server, the language isn't going to have a noticeable impact on performance in 99% of cases. The exceptions are those in which you're doing heavy back-end processing rather than simply grabbing something out of a database, lightly massaging it, and sending it off to the user - and, if you are doing that kind of thing, you're likely better off doing it asynchronously if possible and stuffing the results into a database to be lightly massaged and viewed later.
The reason is, quite simply, that network connection and data transfer times will be so much longer than your program's execution time that it's not even funny. If it's taking 2 seconds to establish a network connection to the server and do the data transmission in each direction, nobody is going to care whether the processing on the server adds 0.1s or 0.2s on top of that 2s of network activity.
[1] Note that I am talking here about the vanilla CGI "start up a new process to service each incoming request" model, not the Perl CGI module (CGI.pm/use CGI). There are ways to use CGI while also making use of a long-lived process which handles multiple requests over its lifetime.
Architecture and system design are more important than language choice for a high traffic app.
But selecting a language is not the first thing you should do, unless you are planning to write everything from the ground up.
You should be selecting a toolset.
If you want to have something soonest, look at existing web applications. What meets your needs? How customizable is it? Does it meet your performance/scalability requirements? If so, the language you use will be the language your app uses.
If you can't find a good match in existing apps, look at different frameworks, Catalyst, Rails, Squatting, Camping, Jifty, Django. There's a nice list of them on Wikipedia.
You should be able to find a framework that will do the job, many of them. Pick some contenders and choose one. The language you use will be the language your framework uses.
There's really no such thing as a "high performance page". That's like asking what the fastest car is (and if you watch enough Top Gear, you know that's not a simple answer). You have to think about what you actually want to do (i.e. the particular task), what you have to do to make that happen, and which tools would work best for that.
Are you going to have a lot of people doing a lot of small things, or fewer people doing really big things? Is it all going to happen at once (i.e. spikes), or is it going to be constant demand? Are you send back small chunks of data or serving up really large files?
Suppose that every portion were as fast as possible. It's a fantasy for sure, but consider it anyway. Now that everything is fast as possible, rank every part according to how relatively fast they are. What's the slowest part? Is it disk access? Network IO? Socket availability?
If you aren't at the point where you're already thinking about this, the language probably isn't that important beyond your skill with it.
There are a lot of books on web performance out there. :)
This post on serverfault suggestst that you could write an extension module to nginx for serving dynamic content.
Such modules need to be compiled to native machine code, so most likely are faster than running Perl.
I don't believe it would be faster than other common choices such as PHP, Python, Ruby, Java, or C#.
What makes a site good for high traffic?
Does it have more to do with the hardware/infrastructure, or with how one writes the software, using Java as the example, if it matters?
I'm wondering how the software changes just because it is expected that billions of users will be on the site, if at all.
My understanding up to this point is that the code doesn't change, but that it is deployed on multiple servers, in a cluster, and a load balancer distributes the load, so really, on any one server/deployment, the application is just as any other standard application/website.
I highly recommend reading Jeff Atwood's blog on Micro-Optimization. In previous blogs he talks somewhat about how this site was created and the hardware upgrades he has had (which quickly summarized said that better hardware performs better only the extent that it is faster/better), but the real speed of a site comes from good programming, and this article seems like it should sum up some of your site programming questions quite well.
Hardware is cheap. Programming is expensive.
There are some programming techniques to make sure your code can handle multiple simultaneous views/updates. If you're using an existing framework, much of that work is (hopefully) done for you, but otherwise you're going to find stuff that worked for a few hundred hits an hour on one server isn't going to work when you're getting hundreds of thousands of hits and you have to deploy multiple load balancing machines.
Well, it is primarily an issue of hardware scaling but there are a few things to keep in mind with respect to the software involved in scaling. For example, if you are on a server farm, you'll need to work with a session management server (either via SQL Server or via a state server - which has implications in that your session variables need to be serializable).
But, in the bigger picture, there are a variety of things that you would want to do to scale to an enterprise level. For example, it becomes particularly important that you abstract out your database calls to a DAL because you may well need to adopt the use of a middleware package for high volume environments.